Hi,

Apologies in advance for a slightly long and unslightly technical email.
It is not that complicated once you get used to it.

1. If you attended hepsysman you would have seen my presentation [1] on
subject alternative names for host certificates (ie aliases, typically),
sometimes needed to comply with Globus (finally) honouring the
requirements of RFC 2818 [2] section 3.1.

We now have better support for this in the UK e-Science CA. It's not
perfect - none of the CA stuff is - but it works (probably).

2. The desired alternative names are submitted with the request.

RA operators still have to approve the request.  However, since the RA
ops currently have poor visibility of the extra added additional
additions, you have to be pre-authorised to request extra SANs (if you
just want the single hostname, that in the CN, you do NOT need
pre-authorisation, it is the old process). This means that for anyone
requesting an alternative name, beyond the single hostname in the CN,
your permission is granted to your personal DN to request a FQDN or to a
domain as an alternative name.  Permissions are granted separately to
wildcard names.

E.g. Joe Bloggs with DN /C=UK/O=eScience/OU=uni/L=phys/CN=joe bloggs
requests a host certificate for foobar123.phys.uni.ac.uk, and wishes to
obtain an alternative name. If he has permission for www.gridpp.ac.uk
then he can get only that name; if the permission is to .gridpp.ac.uk,
Joe can get www.gridpp.ac.uk and planet.gridpp.ac.uk as alternative
names, etc. Separately Joe may have permissions for wildcards for
phys.uni.ac.uk, meaning he can get *.cloud.phys.uni.ac.uk but not
*.uni.ac.uk (which would not be a good idea.)

Wildcards currently have to be the first character, see [5], section
3.4.8. So *.cloud.phys.uni.ac.uk, not host*.cloud.phys.uni.ac.uk, much
less host.*.phys.uni.ac.uk or host*.*.uni.ac.uk.

3. How do you get authorisation? Since your RA operator needs to approve
your host requests, they should requests permission on your behalf
BEFORE your request is submitted (or at least before it is signed); by
sending an ideally signed (with their certificate) email with the
request to the helpdesk. Currently myself and Suleman can add
permissions to the system; once added, they stay on the system until
they are revoked.

Note also that permissions are granted to the /group/ of alternative
names /together/; so our friend Joe may have a group for the cloud hosts
and a group for the web hosts, but cannot mix the two; if he tries, it
will be denied. It is permissible to request a proper subset of the group.

However, you might say the group permission needs to exclude the CN;
otherwise you would need a permissions line for each one of your CNAMEs,
such as foobar123.phys.uni.ac.uk. In that case, the link between the CN
and the alternative names is broken. Instead, I would add the domain for
the CNAMES (such as .phys.uni.ac.uk) to the permissions set, so it
covers all of Joe's CNAMEs on a single line.

4. Unfortunately checking is currently only done by the signing system
(which is the ultimate authority for signing stuff); not by the
servers.  So if your request is rejected, it does not sign. It would be
nice if you had prior warning (at submission time), or maybe an error
mail in the worst case; that would be the next step. (There is an
interesting amusing bug in CW which also should be fixed.)

5. Please note that this DOES NOT work for renewals. When the time for
renewal rolls around, it is RECOMMENDED you request a new certificate
(part of the reason is that the permission needs re-checking, and at
renewal time, the CA only sees the host certificate DN, not the owner's DN.)

6. Thanks to the following people:

  * Robert Frank, for very quickly updating the PeCR to support this stuff.
  * John Kewley for testing it on the dev CA
  * This was one of the many things [6] I worked on during the WLCG
    workshop, so thanks to Dave Kelsey.
  * Bruno Canning from T1 for being our first live volunteer.

I will join dteam today so I can explain, if you are confused...

Thanks
--jens

7. References

[1]
https://indico.cern.ch/event/592622/contributions/2582452/attachments/1476271/2286995/identity.pdf
[2] http://www.rfc-editor.org/rfc/rfc2818.txt
[3] https://www.gridpp.ac.uk/wiki/SubjectAltName
[4] http://www.ngs.ac.uk/ukca/pecr.html
[5] http://www.ogf.org/documents/GFD.225.pdf
[6] http://storage.esc.rl.ac.uk/weekly/20170628-minutes.txt