Clean Access Certificates

[beason001]

Goals:

Secure communications between CAS and CAM

No SSL errors for users going through CAS

No SSL errors for admins going to CAS/CAM admin pages -- even when connecting to individual servers in an HA pair (rather than the service IP or name)

Support for AD SSO

Environment:

Serveral CAS HA pairs (various mixed in-band and out-of-band deployments) and one CAM HA pair (soon to be on 4.7(2)).  To simplify, let's use these:

     CAS1 and CAS2 are an in-band CAS HA pair (supports VPN and wireless networks)

     CAS3 and CAS4 are an  out-of-band CAS HA pair (supports users on wired switches)

     CAM1 and CAM2 are the HA CAM pair

Client devices running Mac OS X (10.4 and 10.5), Windows XP, Windows 7 (mostly on latest agent)

Certificates must be issued by an already deployed PKI (based on  Microsoft Certificate Services)

Questions:

1. Does anyone have a clever naming scheme (or IP addressing scheme) for the Service Name?

2. The certificate subject will match the FQDN that resolves to the Service IP, but should I include the IP addresses (of the individual servers in the HA pair), FQDNs, both, or neither in the subject alternate name attribute?

3. Is there any reason to include just the hostname anywhere in the certificate (as is required by Internet Explorer and various Windows processes for IWA)?

4. Would this approach work?

nac1.domain.tld resolves to the Service IP for the CAS1/CAS2 pair.  The certificate for the pair would have a subject of nac1.domain.tld and the following subject alternate names:

SAN:dns=nac1.domain.tld&dns=cas1.domain.tld&dns=cas2.domain.tld

&dns=nac1&dns=cas1&dns=cas2

[Lauren Sullivan]

The most common I've seen is casib.domain.tld for the SIP, casib1.domain.tld for the physical address of the primary, casib2.domain.tld for the physical of the secondary.  Not exactly clever, but it makes sense.

I don't know anything about service alternate name attributes, so can't  comment on those questions

[beason001]

Answers to my own questions:

1. For the individual devices, we followed the same naming scheme used for routers and switches.  It includes a reference to the device's location, function, and series.  For the service names (would it be more precise to refer to these as the certificate names?), which tend to be user facing, I wanted something much friendlier.  Because some locations actually have multiple sets of out-of-band pairs used for wired networks, I used [office nickname]cas[#], where # is a serial number that refers to the CAS pair.  For in-band something similar was used but a reference was made to their position within the DMZ.

2. I chose to use subject alternate names that matched everything but the IP addresses.  This worked well in my environment.  You should note this however, Cisco TAC informed me that while it has never before caused problems and they don't think it would, the only officially supported certificates are those where the CSR was generated in the web admin console and signed by the CA without subsequent modification.  I'll also say that the inclusion of IP addresses in the SAN could potentially make it more difficult to troubleshoot a particular issue that can arrise when switching from IP-based certificates to name-based certificates.  If getting DNS A records created for network gear is a hassle in your environment, it may make sense to only use IPs in the SAN, but otherwise I would leave them out.

3. It is smart to include just the hostname because when you have to connect to the management pages on the individual devices it is more convenient to type https://hostname/admin than https://hostname.somedomain.local/admin.  But again, for this to even be an option, you have to be able to create A records in a domain that your computer will be able to resolve using DNS suffix searching.  And I would be remiss if I did not point out that reliance on DNS suffix searching does introduce some additional risk if you don't carefully control the suffix search order.

4. Yes it would.  It works quite well in fact.  But see the note about TAC support in answer two above.