Jan 8, 2019 1:58:46 PM
Restricting SSL Intercept and Proxy Sub CA Certificates

We often get questions around how to apply policies that allow CAs to only issue specific types of certificates or certificates that can only be used in very specific use cases. An increasingly popular ask is around how to restrict, or ‘lock down’, third party Proxy/SSL Intercept applications such as Zscaler, F5, or Palo Alto.

Why restrict the certificate?

An SSL Intercept application acts as a man-in-the-middle app that wants to issue real-time certificates pretending to be the destination web servers. These allow for authorized monitoring of SSL connections. These applications create their own CSRs requiring a Sub CA certificate so that it can issue its own certificates as a Certificate Authority. This immediately raises some security concerns as issuing a Sub CA certificate for a man-in-the-middle application is effectively making that app an Issuing CA. If that application were to be compromised, the Sub CA certificate could possibly be used to issue trusted certificates, signed CRLs, or more Sub CA certificates.

Commonly, the CSRs are issued with two main issues:

  • No Path length constraint
  • No Asserted Policy

However, these applications may request additional functionality that it should not have such as Code Signing or OCSP Signing.

When a Sub CA certificate is needed for these applications, they should have the minimum amount of functionality.

What’s the alternative?

We would normally re-sign the CSR with a new policy.inf file that uses the Microsoft Application Policy Constraints to restrict the certificate usage. This will work on Microsoft CAs as Application Policy Constraints are a Microsoft standard, but it is not applicable for CA appliances whose requests do not originate for Microsoft v2 certificate templates. The Application Policy Constraints are effectively ignored by the Proxy or SSL Intercept application.

Restricting the certificate usage

In order to restrict the SSL Intercept or Proxy application from issuing certificates with functionality beyond what it should, we will add an Enhanced Key Usage extension to the request. Normally Sub CAs do not specify an EKU and including a new EKU section to the policy.inf will do two things:

  1. Include only those specific EKUs in the sub CA cert.
  2. Overwrite the requested EKUs in the CSR.

The CSR will need to be signed on either the root CA or a policy CA with the command:

  • Certreq – policy “original_CSR.req” “Policy_file.inf” “new_request.req”

As an example, the Policy_file.inf might look something like:

[Version]

Signature="$Windows NT$"

 

[Strings]

DefaultPolicyOID = "1.2.3.4.1455.67.89.5"

PolicyNotice = "This Certification Authority is private web proxy CA.  Certificates issued by this web proxy CA are not managed, and may not be compliant with any policy. For more information please refer to: http://CDP.contoso.com/PKI/cps.txt"

PolicyURL = "http://CDP.contoso.com/PKI/cps.txt"

 

[PolicyStatementExtension]

Policies = Defaultpolicy

 

[DefaultPolicy]

OID = %DefaultPolicyOID%

NOTICE="%PolicyNotice%"

URL="%PolicyURL%"

 

[EnhancedKeyUsageExtension]

OID = 1.3.6.1.5.5.7.3.1      ; Server Authentication

 

[Extensions]

2.5.29.19 = "{text}ca=1&pathlength=0"

2.5.29.15 = AwIBBg==

Critical = 2.5.29.19,2.5.29.15


This will produce a CSR that when signed will generate a certificate with the specified EKUs. Once the certificate is installed on the SSL Intercept or Proxy application, the app will only be able to issue certificates with the policies defined in the Sub CA certificate EKU.

Summary

If you need a Sub CA certificate for an SSL Intercept or Proxy application, consider resigning the CSR to apply policy, a path length restriction, and an EKU restriction to prevent the application from generating certificates with usages beyond what is necessary. 

Contact Keyfactor