Automating SAN Compliancy with CMS 5.0

Chrome 58 Patch Stirs up Controversy and Commotion

A few short months ago Google released a patch (v.58) on its widely used Chrome browser. This patch being released forced us all to question the way we are doing certificate issuance and retroactively broke a lot of browser and webserver connections simultaneously.

Figure – 1

The Certified Security Solutions (CSS) support team dealt with an influx of tickets and advised our clients on how to deal with this hot topic at the time. After observing the rising need for support following this patch, we released a blog article detailing how we could deal with this issue in the short and long term. The long term fix was to remediate the Subject Alternative Names (SANs) attribute entries in the environment and adopt some best practices around certificate issuance. This would ultimately be the best solution moving forward, since the “CommonName” (CN=Machine Name) attribute would no longer be RFC 2818 (field used in a certificate for TLS encryption) compliant on its own to enable TLS encryption and forcing at least one domain name system (DNS) SAN attribute eventually. With these efforts being pinned down as a solution, and as outages were being addressed, another issue presented itself.

Administrators and certificate officers alike would now be faced with new challenges as they moved forward to adopt these better practices in the organization. Prior processes had been defined and automation of certificate issuance had been in place for many years. Some of these adopted processes go as far back as May of 2000 when the “CommonName” attribute was still accepted for TLS encryption.The CSS support team documented various client use cases and procedures. Client advice coupled with internal Public Key Infrastructure (PKI) experts and development team findings, CSS was able to generate a viable solution around existing PKI and certificate processes available in the new release of the industry leading digital certificate and PKI management platform, CMS 5.0.

Seamless is really the key word here. With existing and newly built PKI infrastructure and policies in-place, the need to be able to satisfy a problem without long, time consuming “rip & replace” of processes or PKI to fix an already sinking problem is paramount. How can CMS be leveraged to remediate this condition?

In most cases, to stop an ongoing problem we first need to realize where the problem is stemming from and stop feeding it fuel. With the Chrome 58 patch, the culprit was revealed to be the initial certificate enrollment. The webserver and administrator teams would need to stop enrolling and issuing certificates that were not complaint. It sounds easy enough to enforce, but the challenge came with larger organizations where processes and automation had been defined for years. It is also easy to have certificates issued that slip by without satisfying the new SAN attribute requirement. CSS has placed an option in CMS 5.0 that will not allow enrollment for a certificate on any particular certificate authority (CA) defined on any of its CMSAdminEnroll Portals (CMS 5.0 feature used to Issue PFX and CSRs).

Figure – 2

This creates a seamless boundary of compliancy using the CMS 5.0 product as a simple on and off switch on a given CA being delegated operations for enrollment (CA defined in CMS for enrollment). So, if any issuance is going through the CMSAdminEnroll portal, CMS will fail any attempt to issue that certificate that does not have at least one DNS SAN entry.

To take the word seamless one step further, CSS has also created a CA policy module that adds at least one SAN to a certificate request automatically.

Policy modules are programs that receive requests from the Certificate Services, evaluate those requests, and specify optional properties of the certificates that are built to fill these requests.

Figure – 3

To do this, the RFC 2818 Policy Handler is installed on the CA and then particular templates are defined in the handler configuration. When a certificate request is received on the CA for that particular template, it then takes the “CommonName” attribute of the certificate request and places that as a DNS SAN attribute as well making the certificate compliant.

Figure – 4

Seamlessly Automating SANs Compliancy Wrap-Up

We touched on some of the pain points of generating SANs attributes and seamless integration that would help hold the reins of issuance and compliancy. We also introduced the newest CMS 5.0 release (forced complaint entries & policy module) that can be utilized to help make the reality of resisting outages and application downtime possible.

Other great CMS 5.0 features and enhancements:

• more robust certificate renewal workflows
• support for management of NetScaler certificates
• enhanced database protection options
• agent blueprints
• web API (application programming interface) PowerShell SDK
• complete UI overhaul

The newest features help make CSS’ digital certificate and PKI management platform, CMS, not only a necessity, but a powerhouse in any organization or enterprise.