06-15-2015 01:38 PM
I am attempting to deploy public certificates for my ClearPass cluster following the guidelines in this tech note: CPPM-Certificates 101 Technote V1.0
However, current baseline requirements will no longer allow the issuance of a public certificate with private IPs or private server names in the subject alternative name fields:
9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.
Wildcard FQDNs are permitted.
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.
What is the recommendation for addressing this limitation?
06-15-2015 01:39 PM
06-15-2015 02:13 PM
Aruba controllers/APs. The goal is to have trusted certificates in place for 802.1x where devices do not prompt for trusting the cert (Android/Apple) or having the push cert to Windows with GPO or avoid server validation. Also to avoid the browser prompts for cert issues when accessing ClearPass.
06-15-2015 02:16 PM
Couple of things:
- If you're using Aruba equipment, you can do all redirects using DNS name, so the IP address in the cert issue shouldn't apply.
- For the private vs public FQDN, you can just create CNAMES for public FQDNs and use those in your cert.
- You will always get the certificate trust warning the first time you connect to a new 802.1X SSID (unless you pre-configure clients via onboarding, GPO, etc). The message is not referring to certificate trust, it's asking if you trust the server's identity.
06-15-2015 02:43 PM
Thank you for the quick reply. I will try to work out some of these options.
I guess I misunderstood thinking a public cert would remove the server identity prompt. I was thinking if the server had a cert from an issuer the client trusted, the identity trust would be inherent much like how a browser works with a cert on a secure site. I wanted to find a way to keep users from having to accept or re-accept a cert or reconfigure their connect each time we have to renew a cert.
I guess I will need to revisit the benefits of having a public cert beyond it just being the "right way". Any quick benefits you could relay?
I know we got some MacBooks recently that needed the ClearPass cert loaded locally before it would authenticate. Would the public cert resolve this issue?
06-15-2015 02:57 PM
You'll still want to use a public certificate, otherwise you'd have to install the root CA on every device.
The only way to get rid of the security prompt would be to manually configure the clients, onboard them, or push down a GPO or profile.
I haven't heard of that Mac issue. There is a major bug that has been present for a few years where the user tries to roam and OS X does an OCSP certificate check which causes connectivity issues. The fix for that is to install the server certificate and set it to always trust.