Difference between revisions of "SubjectAltName"
From GridPP Wiki
(→Support for alternative names) |
(Updated with bulk requests and removed obsolete information) |
||
| Line 25: | Line 25: | ||
== Support for alternative names == | == Support for alternative names == | ||
| − | [http://www.ngs.ac.uk/ukca/pecr.html PeCR] has been modified to support requesting additional subject alternative names | + | [http://www.ngs.ac.uk/ukca/pecr.html 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" | ||
| − | + | == IMPORTANT LIMITATIONS == | |
| − | + | # 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. | |
| − | + | # 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 14:37, 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"
IMPORTANT LIMITATIONS
- 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.
- 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.
