[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<-subj arg>]
[B<-crldays days>]
[B<-crlhours hours>]
[B<-key arg>]
[B<-passin arg>]
[B<-cert file>]
+[B<-selfsign>]
[B<-in file>]
[B<-out file>]
[B<-notext>]
[B<-msie_hack>]
[B<-extensions section>]
[B<-extfile section>]
+[B<-engine id>]
=head1 DESCRIPTION
=item B<-spkac filename>
a file containing a single Netscape signed public key and challenge
-and additional field values to be signed by the CA. See the B<NOTES>
+and additional field values to be signed by the CA. See the B<SPKAC FORMAT>
section for information on the required format.
=item B<-infiles>
systems the command line arguments are visible (e.g. Unix with
the 'ps' utility) this option should be used with caution.
+=item B<-selfsign>
+
+indicates the issued certificates are to be signed with the key
+the certificate requests were signed with (given with B<-keyfile>).
+Cerificate requests signed with a different key are ignored. If
+B<-spkac>, B<-ss_cert> or B<-gencrl> are given, B<-selfsign> is
+ignored.
+
+A consequence of using B<-selfsign> is that the self-signed
+certificate appears among the entries in the certificate database
+(see the configuration option B<database>), and uses the same
+serial number counter as all other certificates sign with the
+self-signed certificate.
+
=item B<-passin arg>
the key password source. For more information about the format of B<arg>
(using the default section unless the B<-extensions> option is also
used).
+=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 default
+for all available algorithms.
+
=back
=head1 CRL OPTIONS
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 case
+insensitive. Setting any revocation reason will make the CRL v2.
+
+In practive B<removeFromCRL> is not particularly useful because it is only used
+in delta CRLs which are not currently implemented.
+
+=item B<-crl_hold instruction>
+
+This sets the CRL revocation reason code to B<certificateHold> and the hold
+instruction to B<instruction> which must be an OID. Although any OID can be
+used 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 to
+B<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 to
+B<CACompromise>.
+
=item B<-subj arg>
supersedes subject name given in the request.
the text database file to use. Mandatory. This file must be present
though initially it will be empty.
-=item B<serialfile>
+=item B<unique_subject>
+
+if the value B<yes> is given, the valid certificate entries in the
+database must have unique subjects. if the value B<no> is given,
+several valid certificate entries may have the exact same subject.
+The default value is B<yes>, to be compatible with older (pre 0.9.8)
+versions of OpenSSL. However, to make CA certificate roll-over easier,
+it's recommended to use the value B<no>, especially if combined with
+the B<-selfsign> command line option.
+
+=item B<serial>
a text file containing the next serial number to use in hex. Mandatory.
This file must be present and contain a valid serial number.
commonName = supplied
emailAddress = optional
-=head1 WARNINGS
-
-The B<ca> command is quirky and at times downright unfriendly.
-
-The B<ca> utility was originally meant as an example of how to do things
-in a CA. It was not supposed to be used as a full blown CA itself:
-nevertheless some people are using it for this purpose.
-
-The B<ca> command is effectively a single user command: no locking is
-done on the various files and attempts to run more than one B<ca> command
-on the same database can have unpredictable results.
-
=head1 FILES
Note: the location of all files can change either by compile time options,
to rebuild the index file from all the issued certificates and a current
CRL: however there is no option to do this.
-CRL entry extensions cannot currently be created: only CRL extensions
-can be added.
-
V2 CRL features like delta CRL support and CRL numbers are not currently
supported.
=head1 WARNINGS
+The B<ca> command is quirky and at times downright unfriendly.
+
+The B<ca> utility was originally meant as an example of how to do things
+in a CA. It was not supposed to be used as a full blown CA itself:
+nevertheless some people are using it for this purpose.
+
+The B<ca> command is effectively a single user command: no locking is
+done on the various files and attempts to run more than one B<ca> command
+on the same database can have unpredictable results.
+
The B<copy_extensions> option should be used with caution. If care is
not taken then it can be a security risk. For example if a certificate
request contains a basicConstraints extension with CA:TRUE and the
projects / openssl.git / blobdiff