Difference between revisions of "SubjectAltName"

From GridPP Wiki
Jump to: navigation, search
(updated with new information)
(Support for alternative names)
Line 28: Line 28:
  
 
However, 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.
 
However, 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.
  
 
== How to get host certificates with additional alternative names ==
 
== How to get host certificates with additional alternative names ==

Revision as of 10:47, 12 July 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 (through the --san switch).

However, 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.

How to get host certificates with additional alternative names

  • Currently you need to make a request or renewal request for the certificate, and ask the CA to manually add the alternative names.

However, it is intended to honour subject alternative names in the requests. Here is a minimal recipe for creating requests with OpenSSL with subject alternative names, expecting four environment variables to be set prior to generating the request:

[req]
req_extensions = req_ext
prompt = no
default_md = sha256
req_distinguished_name = req_dn

[req_dn]
countryName = UK
organizationName = eScience
organizationalUnitName = $ENV::RA1
localityName = $ENV::RA2
commonName = $ENV::HOSTNAME

[req_ext]
subjectAltName = DNS: $ENV::HOSTNAME, DNS: $ENV::ALTNAME

Notes:

  • The environment variables RA1 and RA2 should be set to the name components of your RA (e.g. RA1=CLRC, RA2=RAL).
  • The HOSTNAME variable is set twice (as described above), in the commonName and as the first alternative name.
  • In this case there is only one other alternative name, ALTNAME. If you need more than one, they should be put on the same line of the config file, each preceeded by the string "DNS: "; extending this script to do so is left as an exercise to the reader.

How to generate the request (based on an existing key, in key.pem, and the config being written to req.cnf):

openssl req -config req.cnf -new -key key.pem -out req.pem