Now that you have a CA, this page will cover how to do things with it.
You'll want to adjust the
policy line (under your default
ca section) in your openssl.conf. If it's set to
policy_match then that means all certificates must match country, state, and organizationName of our CA, and must supply a locality and commonName. If you set it to
policy_anything then the only thing required is a commonName.
Of course, in reality, you probably want to define your own policy, one which requires various things to be present, but doesn't require they match your CA. Any, set the
policy line to the appropriate policy.
Additionally, you'll want to make sure that
x509_extensions (under your default
ca section) is set to whatever section of extensions you want to give people when you sign extensions. See the extensions page for details on what these are and which ones you might want.
Lastly, you'll probably want to setup the following aliases for ease-of-use:
As you'll see below, there is plenty of room for other aliases, but these will allow you to look at a certificate by typing
cert foo.crt, a request by typing
req foo.csr, and a CRL by typing
To sign a certificate request, dump it in your
certreqs directory, and then type:
openssl ca -config openssl.cnf -infiles certreqs/foo.csr
This will dump out information about the foo.csr request as well as the certificate that will result if you sign. You should verify this information carefully. If you decide you want to sign, you will need to confirm by typing "y", as well as provide the passphrase for the CA's private key.
At this point you'll have the signed certificate under the
certsdb directory named by the serial number it was given, and with a
.pem extension. You may deliver this to the original requestor. You may use plain-text means as this public cert does not need to be kept secure.
If you are signing a certificate that needs a different set of extensions, for example, a subordinate CA, you can do:
openssl ca -config openssl.cnf -extensions v3_ca -infiles certreqs/foo.csr
And by the same token, you may choose a different policy with:
openssl ca -config openssl.cnf -policy policy_match -infiles certreqs/foo.csr
And obviously, you may use both.
If a key gets compromised, is superseded, or otherwise no longer needed, the CA should revoke it. This is done via:
openssl ca -config openssl.cnf -revoke certsdb/5FE840894254A22.pem
This will ask you for the passphrase of the CA's private key and then revoke the certificate. You can also specify a
-crl_reason option where the reason is one of the following:
Technically another reason, "removeFromCRL" is valid, but unsupported in openssl. An example of using one of these would be:
openssl ca -config openssl.cnf -crl_reason superseded -revoke certsdb/5FE840894254A22.pem
-crl_CA_compromise allow you to specify times of compromise and set the crl_reason to the respective setting.
Once you've revoked a certificate be sure to update the CRL. Instructions on how to do that are below.
CRLs should be created regularly and made available to the users of your CA - and their users! CRLs can be created without having ever revoked a certificate. However, if you revoke a certificate, a new CRL should be generated immediately.
To generate a CRL, simply do:
openssl ca -config openssl.cnf -gencrl -out crl.pem
Then provide this CRL in the URL provided in your crlDistributionPoint extension.