=pod=head1 NAMEca - sample minimal CA application=head1 SYNOPSISB<openssl> B<ca>[B<-verbose>][B<-config filename>][B<-name section>][B<-gencrl>][B<-revoke file>][B<-crl_reason reason>][B<-crl_hold instruction>][B<-crl_compromise time>][B<-crl_CA_compromise time>][B<-crldays days>][B<-crlhours hours>][B<-crlexts section>][B<-startdate date>][B<-enddate date>][B<-days arg>][B<-md arg>][B<-policy arg>][B<-keyfile arg>][B<-key arg>][B<-passin arg>][B<-cert file>][B<-selfsign>][B<-in file>][B<-out file>][B<-notext>][B<-outdir dir>][B<-infiles>][B<-spkac file>][B<-ss_cert file>][B<-preserveDN>][B<-noemailDN>][B<-batch>][B<-msie_hack>][B<-extensions section>][B<-extfile section>][B<-engine id>][B<-subj arg>][B<-utf8>][B<-multivalue-rdn>]=head1 DESCRIPTIONThe B<ca> command is a minimal CA application. It can be usedto sign certificate requests in a variety of forms and generateCRLs it also maintains a text database of issued certificatesand their status.The options descriptions will be divided into each purpose.=head1 CA OPTIONS=over 4=item B<-config filename>specifies the configuration file to use.=item B<-name section>specifies the configuration file section to use (overridesB<default_ca> in the B<ca> section).=item B<-in filename>an input filename containing a single certificate request to besigned by the CA.=item B<-ss_cert filename>a single self signed certificate to be signed by the CA.=item B<-spkac filename>a file containing a single Netscape signed public key and challengeand additional field values to be signed by the CA. See the B<SPKAC FORMAT>section for information on the required format.=item B<-infiles>if present this should be the last option, all subsequent argumentsare assumed to the the names of files containing certificate requests. =item B<-out filename>the output file to output certificates to. The default is standardoutput. The certificate details will also be printed out to thisfile.=item B<-outdir directory>the directory to output certificates to. The certificate will bewritten to a filename consisting of the serial number in hex with".pem" appended.=item B<-cert>the CA certificate file.=item B<-keyfile filename>the private key to sign requests with.=item B<-key password>the password used to encrypt the private key. Since on somesystems the command line arguments are visible (e.g. Unix withthe 'ps' utility) this option should be used with caution.=item B<-selfsign>indicates the issued certificates are to be signed with the keythe certificate requests were signed with (given with B<-keyfile>).Cerificate requests signed with a different key are ignored.  IfB<-spkac>, B<-ss_cert> or B<-gencrl> are given, B<-selfsign> isignored.A consequence of using B<-selfsign> is that the self-signedcertificate appears among the entries in the certificate database(see the configuration option B<database>), and uses the sameserial number counter as all other certificates sign with theself-signed certificate.=item B<-passin arg>the key password source. For more information about the format of B<arg>see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.=item B<-verbose>this prints extra details about the operations being performed.=item B<-notext>don't output the text form of a certificate to the output file.=item B<-startdate date>this allows the start date to be explicitly set. The format of thedate is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).=item B<-enddate date>this allows the expiry date to be explicitly set. The format of thedate is YYMMDDHHMMSSZ (the same as an ASN1 UTCTime structure).=item B<-days arg>the number of days to certify the certificate for.=item B<-md alg>the message digest to use. Possible values include md5, sha1 and mdc2.This option also applies to CRLs.=item B<-policy arg>this option defines the CA "policy" to use. This is a section inthe configuration file which decides which fields should be mandatoryor match the CA certificate. Check out the B<POLICY FORMAT> sectionfor more information.=item B<-msie_hack>this is a legacy option to make B<ca> work with very old versions ofthe IE certificate enrollment control "certenr3". It used UniversalStringsfor almost everything. Since the old control has various security bugsits use is strongly discouraged. The newer control "Xenroll" does notneed this option.=item B<-preserveDN>Normally the DN order of a certificate is the same as the order of thefields in the relevant policy section. When this option is set the order is the same as the request. This is largely for compatibility with theolder IE enrollment control which would only accept certificates if theirDNs match the order of the request. This is not needed for Xenroll.=item B<-noemailDN>The DN of a certificate can contain the EMAIL field if present in therequest DN, however it is good policy just having the e-mail set intothe altName extension of the certificate. When this option is set theEMAIL field is removed from the certificate' subject and set only inthe, eventually present, extensions. The B<email_in_dn> keyword can beused in the configuration file to enable this behaviour.=item B<-batch>this sets the batch mode. In this mode no questions will be askedand all certificates will be certified automatically.=item B<-extensions section>the section of the configuration file containing certificate extensionsto be added when a certificate is issued (defaults to B<x509_extensions>unless the B<-extfile> option is used). If no extension section ispresent then, a V1 certificate is created. If the extension sectionis present (even if it is empty), then a V3 certificate is created.=item B<-extfile file>an additional configuration file to read certificate extensions from(using the default section unless the B<-extensions> option is alsoused).=item B<-engine id>specifying an engine (by it's unique B<id> string) will cause B<req>to attempt to obtain a functional reference to the specified engine,thus initialising it if needed. The engine will then be set as the defaultfor all available algorithms.=item B<-subj arg>supersedes subject name given in the request.The arg must be formatted as I</type0=value0/type1=value1/type2=...>,characters may be escaped by \ (backslash), no spaces are skipped.=item B<-utf8>this option causes field values to be interpreted as UTF8 strings, by default they are interpreted as ASCII. This means that the fieldvalues, whether prompted from a terminal or obtained from aconfiguration file, must be valid UTF8 strings.=item B<-multivalue-rdn>this option causes the -subj argument to be interpretedt with fullsupport for multivalued RDNs. Example:I</DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe>If -multi-rdn is not used then the UID value is I<123456+CN=John Doe>.=back=head1 CRL OPTIONS=over 4=item B<-gencrl>this option generates a CRL based on information in the index file.=item B<-crldays num>the number of days before the next CRL is due. That is the days fromnow to place in the CRL nextUpdate field.=item B<-crlhours num>the number of hours before the next CRL is due.=item B<-revoke filename>a filename containing a certificate to revoke.=item B<-crl_reason reason>revocation reason, where B<reason> is one of: B<unspecified>, B<keyCompromise>,B<CACompromise>, B<affiliationChanged>, B<superseded>, B<cessationOfOperation>,B<certificateHold> or B<removeFromCRL>. The matching of B<reason> is caseinsensitive. Setting any revocation reason will make the CRL v2.In practive B<removeFromCRL> is not particularly useful because it is only usedin delta CRLs which are not currently implemented.=item B<-crl_hold instruction>This sets the CRL revocation reason code to B<certificateHold> and the holdinstruction to B<instruction> which must be an OID. Although any OID can beused only B<holdInstructionNone> (the use of which is discouraged by RFC2459)B<holdInstructionCallIssuer> or B<holdInstructionReject> will normally be used.=item B<-crl_compromise time>This sets the revocation reason to B<keyCompromise> and the compromise time toB<time>. B<time> should be in GeneralizedTime format that is B<YYYYMMDDHHMMSSZ>.=item B<-crl_CA_compromise time>This is the same as B<crl_compromise> except the revocation reason is set toB<CACompromise>.=item B<-crlexts section>the section of the configuration file containing CRL extensions toinclude. If no CRL extension section is present then a V1 CRL iscreated, if the CRL extension section is present (even if it isempty) then a V2 CRL is created. The CRL extensions specified areCRL extensions and B<not> CRL entry extensions.  It should be notedthat some software (for example Netscape) can't handle V2 CRLs. =back=head1 CONFIGURATION FILE OPTIONSThe section of the configuration file containing options for B<ca>is found as follows: If the B<-name> command line option is used,then it names the section to be used. Otherwise the section tobe used must be named in the B<default_ca> option of the B<ca> sectionof the configuration file (or in the default section of theconfiguration file). Besides B<default_ca>, the following options areread directly from the B<ca> section: RANDFILE preserve msie_hackWith the exception of B<RANDFILE>, this is probably a bug and maychange in future releases.Many of the configuration file options are identical to command lineoptions. Where the option is present in the configuration fileand the command line the command line value is used. Where anoption is described as mandatory then it must be present inthe configuration file or the command line equivalent (ifany) used.=over 4=item B<oid_file>This specifies a file containing additional B<OBJECT IDENTIFIERS>.Each line of the file should consist of the numerical form of theobject identifier followed by white space then the short name followedby white space and finally the long name.