Securism Blog

Recently I’ve been involved in discussions in the Mozilla security policy mail list where the topic of permitting privately owned PKIs to be subordinates of publicly trusted CAs is being debated. It’s an interesting debate because I see valid reasons to both permit and forbid private PKIs from being subordinates of public CAs.

First, a little background. Previous visitors that have read my post on certificate validation will recall that a standard PKI hierarchy has a single CA (root CA) that is issuing certificates to subscribers. In this model, subscribers are assumed to have a copy of the root CA certificate in their devices. That certificate is then used to validate that certificates presented to the subscriber have been issued by the CA. In an enterprise network environment, a simple flat hierarchy where the root CA directly issues all subscriber certificates, all devices which will need to access resources protected by subscriber certificates would then need to be provisioned with the root CA certificate. In some simple environments, this is easy. For example, in a standard Microsoft Active Directory network, a domain controller could be configured to both act as a CA and could add the root CA certificate to group policy. Computers which are domain members could then fetch the root CA certificate as part of the domain login process.

However, as the set of devices which are used in enterprise networks continue to grow (iPads, iPhones) and as other web browsers (Mozilla, Opera) gain even more acceptance, the problem of provisioning root CA certificates gets more complicated. These devices/software applications obviously cannot be joined to the domain to obtain the root CA certificate. Therefore, the enterprise network administrator will have to provision the root CA certificate on these other devices using some other centralized certificate management solution.

Several commercial certificate authorities offer a service where they will issue a subordinate CA certificate to enterprise customers (full disclosure: my company offers this service as well.) In this case, an enterprise PKI CA certificate would be signed by a root CA certificate that is already embedded in most browsers, operating systems and devices. This permits the enterprise root CA to be trusted by those devices/applications without a need to provision an additional root CA certificate in them.

Such an approach has pros and cons to it. Let’s analyze this approach in the context of 4 common enterprise PKI use cases as outlined in my SANS gold paper using a simple pros/cons approach.

802.1x WLAN

Pros:

• The WLAN authenticator (typically a AAA server) is automatically trusted by wireless clients which makes it easy to seamlessly support both enterprise and guest WiFi use cases in the same WLAN infrastructure.

Cons:

• Opens up WiFi clients to rogue AP attacks (if an attacker can obtain a valid certificate, he can easily setup a rogue AP that would be automatically trusted by enterprise WiFi clients which would enable him to exfiltrate credentials from those clients.)

HTTPS

Pros:

• Enables enterprises to secure Intranet websites with HTTPS without requiring users to ‘click through’ standard browser warnings.
• Allows any device/web browser software to access the Intranet website without requiring additional user actions to provision the root CA certificate.

Cons:

• Enterprise sub CAs could potentially issue valid certificates for Internet websites. A rogue enterprise CA administrator could easily issue certificates that do not belong to his enterprise domain. These certificates could be resold to attackers who could use them to setup MITM attacks for other HTTPS protected Internet sites.

S/MIME

Pros:

• Digitally signed emails could be validated by email recipients that are outside of the enterprise.

Cons:

• If an attacker is able to obtain a valid S/MIME certificate, he/she could send very convincing spear-phishing emails to enterprise users. It is unlikely that emails with valid digital signatures would be marked as spam by spam filtering software.

Infrastructure (routers, VPN gateways etc)

Pros:

• Could possibly simplify the provisioning of new network infrastructure components.
• Makes it easier to support additional VPN client types.

Cons:

• Makes it much easier for an attacker who has physical access to the enterprise network to setup rogue devices; especially since many network devices which support certificate based authentication use the certificate as the sole means of identifying valid peers.

In my opinion, the risks of using certificates rooted to a public CA for enterprise WLAN, S/MIME and infrastructure authentication outweigh the benefits. For securing Intranet websites with HTTPS, the benefits outweigh the risks because HTTPS protected websites could easily require the user to present credentials that are valid for the enterprise network. That being said, there are certainly additional controls that could be implemented in S/MIME and WLAN deployments to mitigate the risks pointed out above.

What do you think? Are there other risks or use cases for publicly trusted enterprise PKIs?