Restricción de certificados SSL Intercept y Proxy Sub CA

A menudo recibimos preguntas sobre cómo aplicar políticas que permitan a las CA emitir únicamente tipos específicos de certificados o certificados que sólo puedan utilizarse en casos de uso muy concretos. Una pregunta cada vez más popular es sobre cómo restringir o "bloquear" aplicaciones Proxy/SSL Intercept de terceros como Zscaler, F5 o Palo Alto.

Una aplicación SSL Intercept actúa como una aplicación man-in-the-middle que quiere emitir certificados en tiempo real haciéndose pasar por los servidores web de destino. Esto permite la supervisión autorizada de las conexiones de SSL . Estas aplicaciones crean sus propios CSR requiriendo un certificado Sub CA para poder emitir sus propios certificados como Autoridad de Certificación. Esto plantea inmediatamente algunos problemas de seguridad, ya que la emisión de un certificado de subCA para una aplicación "man-in-the-middle" la convierte en una CA emisora. Si esa aplicación se viera comprometida, el certificado de sub CA podría utilizarse para emitir certificados de confianza, CRL firmadas o más certificados de sub CA.

Normalmente, los CSR se emiten con dos temas principales:

• Sin restricción de longitud de ruta
• Ninguna política afirmada

Sin embargo, estas aplicaciones pueden solicitar funcionalidades adicionales que no debería tener, como la firma de código o la firma OCSP.

Cuando se necesita un certificado Sub CA para estas aplicaciones, deben tener la mínima funcionalidad.

Normalmente, volveríamos a firmar la CSR con un nuevo archivo policy.inf que utiliza las restricciones de política de aplicaciones de Microsoft para restringir el uso del certificado. Esto funcionará en las CA de Microsoft, ya que las restricciones de política de aplicación son un estándar de Microsoft, pero no es aplicable a los dispositivos de CA cuyas solicitudes no se originan para plantillas de certificados v2 de Microsoft. La aplicación Proxy o SSL Intercept ignoran las restricciones de política de aplicación.

Para restringir que la aplicación SSL Intercept o Proxy emita certificados con funcionalidades más allá de lo que debería, añadiremos una extensión Enhanced Key Usage a la solicitud. Normalmente las Sub CAs no especifican un EKU e incluir una nueva sección EKU al policy.inf hará dos cosas:

1. Incluya sólo esas EKU específicas en el certificado de CA secundaria.
2. Sobrescribir los EKU solicitados en el CSR.

La CSR deberá firmarse en la CA raíz o en una CA de política con la dirección command:

• Certreq - política "original_CSR.req" "Policy_file.inf" "new_request.req"

Como ejemplo, el Policy_file.inf podría tener un aspecto similar:

[Versión]

Firma="$Windows NT$"

[Strings]

DefaultPolicyOID = "1.2.3.4.1455.67.89.5"

PolicyNotice = "Esta Autoridad de Certificación es una CA proxy web privada. Los certificados emitidos por esta CA proxy web no se gestionan y pueden no cumplir ninguna política. Para más información, consulte: https://CDP.contoso.com/PKI/cps.txt"

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

[PolicyStatementExtension]

Políticas = Defaultpolicy

[DefaultPolicy]

OID = %DefaultPolicyOID%

NOTICE="%PolicyNotice%"

URL="%PolicyURL%"

[EnhancedKeyUsageExtension]

OID = 1.3.6.1.5.5.7.3.1 ; Autenticación del servidor

[Extensiones]

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

2.5.29.15 = AwIBBg==

Crítico = 2.5.29.19,2.5.29.15

Esto producirá un CSR que al ser firmado generará un certificado con los EKUs especificados. Una vez instalado el certificado en la aplicación SSL Intercept o Proxy, la app sólo podrá emitir certificados con las políticas definidas en el EKU del certificado Sub CA.

Si necesita un certificado Sub CA para una aplicación SSL Intercept o Proxy, considere la posibilidad de renunciar a la CSR para aplicar la política, una restricción de longitud de ruta y una restricción EKU para evitar que la aplicación genere certificados con usos más allá de lo necesario.