62 lines
3 KiB
Text
62 lines
3 KiB
Text
|
1. Creating a Certificate Authority.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
To fully understand it's contents you're unfortunately going to need to read ca(1ssl),
|
||
|
|
req(1ssl), x509(1ssl), config(5ssl), and x509v3_config(5ssl). Particularly
|
||
|
|
important are the x509v3 extensions present in the certificate, which are
|
||
|
|
defined in the "stglab_x509_ca_extensions" section of the config file.
|
||
|
|
|
||
|
|
The ca-cert script configures some important files in db/, then creates a
|
||
|
|
certificate request and signs it. It also generates an initial (empty)
|
||
|
|
revocation list, then substitutes the correct fingerprints into the html
|
||
|
|
template for serving the CA certificate and CRL to the intranet.
|
||
|
|
|
||
|
|
2. Creating a certificate.
|
||
|
|
|
||
|
|
The create-cert script can generate three "types" of certificate -- server
|
||
|
|
certificates for securing a service with SSL/TLS, client certificates for
|
||
|
|
authenticating a client to these services, and user certificates for
|
||
|
|
authentication, S/MIME e-mail signing or encryption, and code signing. There
|
||
|
|
are minor but important differences in the extensions present in these
|
||
|
|
different certificate types, but these are set in the *-ext.tpl files in tpl/
|
||
|
|
and thus you shouldn't need to worry about them.
|
||
|
|
|
||
|
|
The create-cert script takes a number of arguments, of which the hostname or
|
||
|
|
username and the type are mandatory. It is also a very good idea to supply a
|
||
|
|
number of alternative DNS names when generating a server certificate, because
|
||
|
|
while the script will happily append "stglab.manchester.uk.ibm.com" to an
|
||
|
|
un-qualified host name, it won't append "transitives.com" and for the moment we
|
||
|
|
probably need that.
|
||
|
|
|
||
|
|
You should also provide a team name for the organisational unit, e.g.
|
||
|
|
"Manchester STG Lab Test", an e-mail address (preferably for the team rather
|
||
|
|
than an individual for server/client certificates), and a comment that reflects
|
||
|
|
the usage of the certificate, e.g. "Soak Infrastructure Live Server". Reasonable
|
||
|
|
defaults are provided for all of these for our team's use.
|
||
|
|
|
||
|
|
3. Renewing a certificate.
|
||
|
|
|
||
|
|
The renew-cert script does some painful certificate manipulation that is not
|
||
|
|
strictly necessary in most cases, and may in fact decrease SSL security
|
||
|
|
slightly. This is done because the normal renewal process re-generates the
|
||
|
|
certificate signing request and thus creates a new public/private keypair.
|
||
|
|
If the certificates are used for S/MIME encryption or code signing, this
|
||
|
|
renders all the encrypted e-mail unreadable and requires you to re-sign the
|
||
|
|
code with your new private key. The code in renew-cert re-signs the old
|
||
|
|
certificate request with a new expiry date and the extensions generated when
|
||
|
|
the original certificate was created, and avoids this problem.
|
||
|
|
|
||
|
|
Renewing a certificate is done by giving the hostname, username or path to
|
||
|
|
the certificate to renew-cert.sh.
|
||
|
|
|
||
|
|
4. Revoking a certificate.
|
||
|
|
|
||
|
|
Revoking a certificate is done by giving the hostname, username or path to
|
||
|
|
the certificat to revoke-cert.sh. This script also regenerates a new CRL in
|
||
|
|
both PEM and DER encodings (firefox prefers the latter while IE and other
|
||
|
|
browsers work better with the former), and re-generates the html file with the
|
||
|
|
new fingerprints.
|
||
|
|
|