Difference between revisions of "SubjectAltName"

Revision as of 16:05, 30 August 2017

What?

Certificates always contain alternative names (i.e. alternative to the distinguished name), but they are still intended to be names for the entity to which the certificate was issued.

Thus, for personal certificates, the alternative name is an email address. This is automatically created by the CA and the user need not do anything.

For host certificates, the FQDN of the host must be included. Often, certificates are issued to the CNAME of the host, with the name present in the commonName field and also as an alternative name. Again, this is done automatically by the CA.

However, in DNS, the host may have other names, and it may be necessary to request that these be present in the certificate as well.

Why?

Globus switched to complying with RFC 2818 (section 3.1), requiring that the hostname that is accessed by the client be present in the certificate. For example, when a client connects securely to xyz.gridpp.ac.uk, the following happens:

• The client open a (secure) socket to xyz.gridpp.rl.ac.uk
• As a part of the security handshake, the server will send its own certificate, plus (optionally) a list of methods the client may use to authenticate itself.
• The client MUST now check whether the name in the certificate is xyz.gridpp.ac.uk.
  • It goes through the list of alternative names in the certificate, looking for one that says DNS:xyz.gridpp.ac.uk (or, failing that, a wildcard)
  • Only if there are no alternative names does it check the hostname against the commonName in the Distinguished Name.
  • In particular there is not DNS lookup. Previous Globus code would check alternative names through DNS and allow for matching those against the name in the commonName.
• Obviously the client also checks the validity of the certificate, that it is signed by a trusted CA, has not been revoked, has not expired, and has the extensions that allows it to be a server certificate.

Alternative names are used to allow clients to use an alias for the connection (e.g. connect to srm-hone.gridpp.rl.ac.uk which is an alias for (say) lcgsrm01.gridpp.rl.ac.uk and lcgsrm02.gridpp.rl.ac.uk). A host can have multiple aliases, and different hosts can have the same alias (but different CNAMEs and different certificates).

Support for alternative names

PeCR has been modified to support requesting additional subject alternative names:

• If you are using the "cli request" mode, the extra alternative names are added with the --san switch, one for each alternative name.
  • E.g. ./bin/cli request -c PeCR.cfg --cn cname.gridpp.ac.uk --pin veggiesausage --keyout cname.gridpp.ac.uk.key --san www.gridpp.ac.uk --san wiki.gridpp.ac.uk --san '*.web.gridpp.ac.uk'
• If you are using the bulkRequest mode of the script, the extra alternative names are placed comma separated (and no spaces!) in the 'cnfile' parameter:
  • E.g. the first line in your 'cnfile' would be "cname.gridpp.ac.uk,www.gridpp.ac.uk,wiki.gridpp.ac.uk,*.web.gridpp.ac.uk"

Renewal and Change Requests

One of the current limitations is that RENEWAL IS NOT SUPPORTED through the script (nor by any other means); you will have to request a new certificate. This is because the alternative names are permitted to a person, and renewals do not preserve the identity of the person requesting the certificate; they are done only with the certificate itself. The same is true for change requests where you need to add or remove an extension (or change something else) in a certificate.

• Request (but do not approve) revocation of your current certificate. This will warn the CA that it is about to change, and it will not complain about your requesting a certificate with the same name as an existing certificate.
• Now request a new certificate using PeCR as described above.
• Get it approved by the RA.
  • It is RECOMMENDED to check that the RA has authorised you to request the alternative names that you have requested.
• Wait for it to get signed by the CA.
• Deploy it, replacing the old one.
• Approve the revocation request. At the next signing, the revocation request will then revoke the old certificate.

If your approved revocation request is processed along with your certificate request, the old certificate will be revoked at the same time: this gives you only a very short time window to replace your old certificate with the new one.

IMPORTANT LIMITATIONS

1. Because RAs do not necessarily see the alternative names when they approve the certificate request, you need to be AUTHORISED BEFOREHAND for the alternative names. This must be done by the RA sending a (signed) mail to the CA to authorise the requester (by DN) to get a particular set of names. A given person can have more than one set of authorisations.
2. Support is currently for NEW CERTIFICATES ONLY - NOT RENEWALS. If you need to renew your host certificates, please get new certificates instead. The reason for this is that permissions for alternative names are associated with the requester's DN, and it is not (easily) available at renewal.
3. The need to revoke to get a renewal (see above) is also a limitation.