Field Report – Mitigating PKI Template Risks for Ephemeral Workloads and Desktop

Recently we were working with one of our large customers to address some challenges that aren’t new in PKI, but that we were able to handle with an entirely new set of tools to Mitigate PKI Risks. This customer is not only a consulting services customer leveraging our expertise to move off of a managed PKI to their own internal global enterprise PKI but is also one of our PKI Spotlight customers.

Our customer was in the midst of rolling out certificates to devices throughout the enterprise – services, laptops, desktops, you name it. It also happened to include ephemeral desktops which are spun up from a master image and used by an employee for a work day, then deleted. When the employee connects the next day a new image is created. This meant that each time an employee connected and a desktop was created, a new certificate was being auto-enrolled as the machine would be reverting back to a base image without a certificate. Autoenrollment would then trigger the processing to determine that a certificate wasn’t present and a new request was sent to the CA. Over the course of a weekend, there were 10s of thousands of certificates issued.

Something needed to be done to prevent the long-term issue of a bloated database as well as possible data integrity and performance issues. While not an overnight urgent issue, it had the potential to cripple the PKI and the identity systems that depended on it in the future.

There is a method to address this sort of ephemeral certificate need. Microsoft created this to actually deal with some of its own product needs when OCSP was introduced to the product in Windows Server 2008. The OCSP Responder certificate is created without any mechanism to revoke it – due to how revocation checking logic would work. So the capability to issue a certificate without revocation checking URLs was introduced. In addition, they added the ability to configure a template so that a certificate could be issued and NOT recorded in the CA database. The latter capability is not natively used in any template, or Microsoft product, but was designed for this very specific need – ephemeral systems.

Within the template properties, on the Server tab, the optional check box “Do not store certificates and requests in the CA database” accomplishes the task of issuing short-lived certificates and doesn’t clutter the CA database. Originally envisioned for mechanisms like 802.1x to provide health-based certificates to devices before they were allowed to actively communicate on a network. But it also works for modern short-lived micro-services and ephemeral desktops. More details about this property are available in this Microsoft article.

Figure 1 – Advanced template attributes in V3 and V4 templates

To configure a CA for non-persistent certificate processing

But there are risks to using this option as well as an even more important issue, the feature only works if the CA itself is configured to allow this type of issuance. This means once it’s enabled on the CA for one specific template, any other template in the future could potentially purposely, accidentally, or maliciously be configured to issue without any record in the database. A big security issue especially if used maliciously to create administrative credentials that would be impossible to discover on a CA

Log on as a CA administrator.

Open a command prompt window.

Type certutil –setreg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS and press ENTER.

Type sc stop certsvc and press ENTER.

Type sc start certsvc and press ENTER.

As we talked through the risks with the customer, they rightly asked what could be done to mitigate the risk if the CA was configured to allow these ephemeral certificates. It could be a serious threat if other templates were changed or if the setting was accidentally applied to other long-term certificates.

In the past, the only option was to make sure we checked template properties during annual assessments (assuming they were even done) and to make sure everyone involved knew not to use the property unless approved. But there was no way to detect when it was enabled and where. Everything was about catching the use months or years after the vulnerability was introduced – way too late in a modern enterprise.

Well, if you can’t see where this is going, you haven’t been reading my blog posts of late. That’s right – PKI Spotlight changes this entire story! We showed the customer how PKI Spotlight tracks every change to templates – including this property change. As a result, we can set up an alert to a security group that includes details about what property changed and when – often within minutes of detecting the change.

Figure 2 – In this screenshot, we can detect the moment the DBFlag property is set to enable this functionality.

Figure 3 – Changes to the template properties are detected in realtime and alert notifications sent

This enables us to ensure that the organization can meet its security requirements while at the same time providing real-time alerting and visibility if a configuration is detected which could affect overall organizational security. Of all the nitty gritty bits of PKI security, this is definitely one of those settings you don’t want to be utilized in your environment without proper controls.

Again, my ability to answer the question with a very clear method and tool to Mitigate PKI Risk is something we have never had in the PKI space. Another game changer made simple through PKI Spotlight. I bet you probably don’t even know if and where this setting is in your PKI do you? Want to know how long it would take for PKI Spotlight to tell you? Seconds!