the same as B<-policy>. Mandatory. See the B<POLICY FORMAT> section
for more information.
+=item B<nameopt>, B<certopt>
+
+these options allow the format used to display the certificate details
+when asking the user to confirm signing. All the options supported by
+the B<x509> utilities B<-nameopt> and B<-certopt> switches can be used
+here, except the B<no_signame> and B<no_sigdump> are permanently set
+and cannot be disabled (this is because the certificate signature cannot
+be displayed because the certificate has not been signed at this point).
+
+For convenience the values B<default_ca> are accepted by both to produce
+a reasonable output.
+
+If neither option is present the format used in earlier versions of
+OpenSSL is used. Use of the old format is B<strongly> discouraged because
+it only displays fields mentioned in the B<policy> section, mishandles
+multicharacter string types and does not display extensions.
+
+=item B<copy_extensions>
+
+determines how extensions in certificate requests should be handled.
+If set to B<none> or this option is not present then extensions are
+ignored and not copied to the certificate. If set to B<copy> then any
+extensions present in the request that are not already present are copied
+to the certificate. If set to B<copyall> then all extensions in the
+request are copied to the certificate: if the extension is already present
+in the certificate it is deleted first. See the B<WARNINGS> section before
+using this option.
+
+The main use of this option is to allow a certificate request to supply
+values for certain extensions such as subjectAltName.
+
=back
=head1 POLICY FORMAT
policy = policy_any # default policy
+ nameopt = default_ca # Subject name display option
+ certopt = default_ca # Certificate display option
+ copy_extensions = none # Don't copy extensions from request
+
[ policy_any ]
countryName = supplied
stateOrProvinceName = optional
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 be be used as a full blown CA itself:
+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
numbers of certificates are present because, as the name implies
the database has to be kept in memory.
-Certificate request extensions are ignored: some kind of "policy" should
-be included to use certain static extensions and certain extensions
-from the request.
-
It is not possible to certify two certificates with the same DN: this
is a side effect of how the text database is indexed and it cannot easily
be fixed without introducing other problems. Some S/MIME clients can use
B<CA.pl> help a little but not very much.
Any fields in a request that are not present in a policy are silently
-deleted. This does not happen if the B<-preserveDN> option is used but
-the extra fields are not displayed when the user is asked to certify
-a request. The behaviour should be more friendly and configurable.
+deleted. This does not happen if the B<-preserveDN> option is used.
+The behaviour should be more friendly and configurable.
Cancelling some commands by refusing to certify a certificate can
create an empty file.
+=head1 WARNINGS
+
+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
+B<copy_extensions> value is set to B<copyall> and the user does not spot
+this when the certificate is displayed then this will hand the requestor
+a valid CA certificate.
+
+This situation can be avoided by setting B<copy_extensions> to B<copy>
+and including basicConstraints with CA:FALSE in the configuration file.
+Then if the request contains a basicConstraints extension it will be
+ignored.
+
+It is advisable to also include values for other extensions such
+as B<keyUsage> to prevent a request supplying its own values.
+
+Additional restrictions can be placed on the CA certificate itself.
+For example if the CA certificate has:
+
+ basicConstraints = CA:TRUE, pathlen:0
+
+then even if a certificate is issued with CA:TRUE it will not be valid.
+
=head1 SEE ALSO
L<req(1)|req(1)>, L<spkac(1)|spkac(1)>, L<x509(1)|x509(1)>, L<CA.pl(1)|CA.pl(1)>,
projects / oweals / openssl.git / blobdiff