[B<-sm2-id> I<string>]
[B<-sm2-hex-id> I<hex-string>]
-=for comment ifdef engine sm2-id sm2-hex-id
+=for openssl ifdef engine sm2-id sm2-hex-id
=head1 DESCRIPTION
-The B<ca> command is a minimal CA application. It can be used
+This command is a minimal CA application. It can be used
to sign certificate requests in a variety of forms and generate
CRLs it also maintains a text database of issued certificates
and their status.
The directory to output certificates to. The certificate will be
written to a filename consisting of the serial number in hex with
-".pem" appended.
+F<.pem> appended.
=item B<-cert>
The password used to encrypt the private key. Since on some
systems the command line arguments are visible (e.g. Unix with
-the 'ps' utility) this option should be used with caution.
+the L<ps(1)> utility) this option should be used with caution.
=item B<-selfsign>
=item B<-passin> I<arg>
The key password source. For more information about the format of B<arg>
-see L<openssl(1)/Pass phrase options>.
+see L<openssl(1)/Pass Phrase Options>.
=item B<-notext>
=item B<-md> I<alg>
The message digest to use.
-Any digest supported by the OpenSSL B<dgst> command can be used. For signing
+Any digest supported by the L<openssl-dgst(1)> command can be used. For signing
algorithms that do not support a digest (i.e. Ed25519 and Ed448) any message
digest that is set is ignored. This option also applies to CRLs.
=item B<-msie_hack>
-This is a deprecated option to make B<ca> work with very old versions of
-the IE certificate enrollment control "certenr3". It used UniversalStrings
+This is a deprecated option to make this command work with very old versions
+of the IE certificate enrollment control "certenr3". It used UniversalStrings
for almost everything. Since the old control has various security bugs
its use is strongly discouraged.
=item B<-engine> I<id>
-Specifying an engine (by its unique B<id> string) will cause B<ca>
+Specifying an engine (by its unique I<id> string) will cause B<ca>
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.
=item B<-subj> I<arg>
Supersedes subject name given in the request.
-The arg must be formatted as I</type0=value0/type1=value1/type2=...>.
-Keyword characters may be escaped by \ (backslash), and whitespace is retained.
+The arg must be formatted as C</type0=value0/type1=value1/type2=...>.
+Keyword characters may be escaped by C<\> (backslash), and whitespace is
+retained.
Empty values are permitted, but the corresponding type will not be included
in the resulting certificate.
This option causes the -subj argument to be interpreted with full
support for multivalued RDNs. Example:
-I</DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe>
+C</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>.
+If B<-multi-rdn> is not used then the UID value is C<123456+CN=John Doe>.
=item B<-rand> I<files>
=item B<-crl_reason> I<reason>
-Revocation reason, where B<reason> is one of: B<unspecified>, B<keyCompromise>,
+Revocation reason, where I<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
+B<certificateHold> or B<removeFromCRL>. The matching of I<reason> is case
insensitive. Setting any revocation reason will make the CRL v2.
In practice B<removeFromCRL> is not particularly useful because it is only used
=item B<-crl_hold> I<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
+instruction to I<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> I<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>.
+I<time>. I<time> should be in GeneralizedTime format that is I<YYYYMMDDHHMMSSZ>.
=item B<-crl_CA_compromise> I<time>
=head1 CONFIGURATION FILE OPTIONS
-The section of the configuration file containing options for B<ca>
+The section of the configuration file containing options for this command
is found as follows: If the B<-name> command line option is used,
then it names the section to be used. Otherwise the section to
be used must be named in the B<default_ca> option of the B<ca> section
The input to the B<-spkac> command line option is a Netscape
signed public key and challenge. This will usually come from
the B<KEYGEN> tag in an HTML form to create a new private key.
-It is however possible to create SPKACs using the B<spkac> utility.
+It is however possible to create SPKACs using L<openssl-spkac(1)>.
The file should contain the variable SPKAC set to the value of
the SPKAC and also the required DN components as name value pairs.
=head1 EXAMPLES
-Note: these examples assume that the B<ca> directory structure is
-already set up and the relevant files already exist. This usually
-involves creating a CA certificate and private key with B<req>, a
-serial number file and an empty index file and placing them in
-the relevant directories.
+Note: these examples assume that the directory structure this command
+assumes is already set up and the relevant files already exist. This
+usually involves creating a CA certificate and private key with
+L<openssl-req(1)>, a serial number file and an empty index file and
+placing them in the relevant directories.
-To use the sample configuration file below the directories demoCA,
-demoCA/private and demoCA/newcerts would be created. The CA
-certificate would be copied to demoCA/cacert.pem and its private
-key to demoCA/private/cakey.pem. A file demoCA/serial would be
+To use the sample configuration file below the directories F<demoCA>,
+F<demoCA/private> and F<demoCA/newcerts> would be created. The CA
+certificate would be copied to F<demoCA/cacert.pem> and its private
+key to F<demoCA/private/cakey.pem>. A file F<demoCA/serial> would be
created containing for example "01" and the empty index file
-demoCA/index.txt.
+F<demoCA/index.txt>.
Sign a certificate request:
0.OU=OpenSSL Group
1.OU=Another Group
-A sample configuration file with the relevant sections for B<ca>:
+A sample configuration file with the relevant sections for this command:
[ ca ]
default_ca = CA_default # The default ca section
numbers of certificates are present because, as the name implies
the database has to be kept in memory.
-The B<ca> command really needs rewriting or the required functionality
+This command really needs rewriting or the required functionality
exposed at either a command or interface level so a more friendly utility
(perl script or GUI) can handle things properly. The script
B<CA.pl> helps a little but not very much.
=head1 WARNINGS
-The B<ca> command is quirky and at times downright unfriendly.
+This 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:
+This command 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.
+This command command is effectively a single user command: no locking
+is done on the various files and attempts to run more than one B<openssl 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
projects / openssl.git / blobdiff