Hidden Dangers: Certificate Subject Alternative Names (SANs)

Few companies have the luxury of a dedicated full time professional PKI staff. More typical are those companies that assign this duty as an adjunct to someone with a separate primary function, such as AD engineering.  As such, I find that many PKI practitioners don’t have PKI proficiency as a primary skillset.  It’s easy to understand how a “just make it work” mentality can eventually creep into a PKI operational processes. Too often, operational efficiency easily trumps perceived security risks.

But when a “just make it work” approach works its way into certificate subject name alternative (SAN) provisioning, I think it’s time to take a pause and review what exactly is at stake. This blog has three basic intentions:

• Demonstrate the risks associated with entering Subject Alternative Names incorrectly
• Review the MS SAN best practices (they are still relevant)
• Recommend a better approach

For a variety of reasons, it’s not uncommon for  a customer’s certificate request workflows to evolve to a point where the application or server owner will create a bare bones certificate signing request (CSR) and submit that CSR to a signing authority for completion or for signature. The owner of the PKI, being responsible for ‘finishing’ this CSR, adding the correct Hostname, DNS addresses, email address or IP address to the request. On a Microsoft CA, this is made possible by enabling the “EDITF_ATTRIBUTESUBJECTALTNAME2” policy flag on the CA.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2  

Setting this flag allows SAN information to be included as a ‘Request Attribute.’ That is, after the CSR has been created, the CSR’s attributes can be used to include SAN information after the fact which makes this aforementioned workflow possible. This setting ‘just makes it work.’ The effect of this setting is that requests can be modified using a variety of methods, including the AD/CS Web Enrollment, CertReq, and others.

Example: certreq -submit -attrib "SAN:DNS=someotherserver.csstest.com" someserver.req someserver.cer

But what is the impact of this configuration option? If this setting enabled, the CA’s policy configuration will now look something like this:

(Certutil –getreg policy)

  EditFlags                REG_DWORD = 35014e (3473742)

    EDITF_REQUESTEXTENSIONLIST -- 2

    EDITF_DISABLEEXTENSIONLIST -- 4

    EDITF_ADDOLDKEYUSAGE -- 8

    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)

    EDITF_ENABLEAKIKEYID -- 100 (256)

    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)

    EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)

    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

    EDITF_AUDITCERTTEMPLATELOAD -- 200000 (2097152)

Seeing this in a CA’s policy flags means that the CA will no longer reject SAN information that is included in the certificate’s request attributes. As such, this setting applies to the entire CA, and all other certificate templates that are issued by that certificate authority.

So let’s say this setting is enabled on the CA because the ‘Web Team’ needs this as part of SSL certificate provisioning. This means that the CA is configured to issue certs for both the Corporate Web Server team whose subject needs to be included in the request and for the Corporate User certificates, whose subject is configured to be automatically built from Active Directory.

Figure 1: CA Template configuration.

Custom Enrollment requests are working fine for the Web SSL certs and the users are auto-enrolling as expected from the user template. No problems, right?

Maybe. What if a malcontent user saboteur decides to act maliciously? Using this flag setting means that there is nothing in this configuration that would prevent a user from becoming whoever they want to be, by perhaps doing the following.

Create a new CSR:

certreq -new UserCert.inf UserCert.req 

Certreq is a widely available command line utility that will create a CSR.

This process uses the same certificate template to which the user already has permission.

(Here is the referenced usercert.inf)

NewRequest]

Exportable=FALSE

KeyLength=2048

KeySpec=1

RequestType=cmc

PrivateKeyArchive=FALSE

[RequestAttributes]

CertificateTemplate=CorporateUserCertificate

Submit this CSR to the CA.

Certreq -submit -config "CA.csstest.com\CSS Test CA 1" UserCert.req UserCert.cer

This yields a CA signed certificate, whose subject contains CN=Alice User. The automatically added SAN would look like this: [email protected].

And since the “CorporateUserCertificate” template is configured to use auto-enrollment, the resulting certificates are automatically approved. No certificate officer approval is required.

Figure 2: Typical User Certificate for Alice.

This is a pretty straightforward process.

But what if Alice acted maliciously. What if she took that same request file, and re-submitted it?

Submit the CSR to the CA, now with malicious intent.

Same request file as above, but in addition to automatically populating the certificate’s subject alternative name from AD, let’s say we add our own, in the form a CSR request attribute. Here’s how.

Certreq -submit -config "CA.csstest.com\CSS Test CA 1" -attrib "SAN:[email protected]&[email protected]" UserCert.req UserCert.cer

Now, because of the CA’s ”EDITF_ATTRIBUTESUBJECTALTNAME2”policy flag being set, and the fact that the “CorporateUserCertificate” template does not require approval, Alice has been able to arbitrarily add Bob’s UPN to her own certificate. Even though the template has this information coming from AD.

Figure 3: Alice has added Bob’s UPN to her cert.

In fact, Alice is now both Bob and Alice.  Or just Bob, or just Eve, or the CFO, or whoever. One can see how this process might appeal to malware, or to a malicious user.

Again, this is the Corporate User Certificate template, that is intended to just auto enroll corporate users. Any custom SAN entries are only supposed to be used on the other Corporate Web Server certificates, but because the EDITF_ATTRIBUTESUBJECTALTNAME2 setting applies to the entire CA, all templates on that CA are affected, and all templates and all resulting certificates are at risk from impersonation attacks.

This is why, among other things,  Microsoft recommends the following:

I would agree with that recommendation, and further suggest that everyone read and become familiar with the entire set of Microsoft’s recommendations.  Microsoft Security best practices for allowing SANs in certificates

I would offer that in addition to these best practices, companies using or considering the use of the EDITF_ATTRIBUTESUBJECTALTNAME2 flag do the following:

• Don’t do this
• Instead, ensure that there are up-to-date certificate content guidelines for app owners
• Ensure that there are established procedures for requesting certificates with the correct content
• All certificate subject information (including SAN) should be included in the original certificate request
• All certificates with Custom SAN requests should be evaluated and approved by a Certificate Officer, prior to CA signature

It is critical that companies reevaluate how application owners request certificates in order to mitigate risks associated with custom SAN information…even if this interferes with a “just make it work” based certificate workflow.