Este blog es una continuación de una serie de blogs relacionados con los peligros de añadir información de Subject Alternate Name (SAN) a una solicitud de firma de certificado (CSR).
En blogs anteriores, describí cómo las configuraciones necesarias para añadir información SAN a las solicitudes de firma de certificados existentes pueden dejar a una CA vulnerable a ataques de suplantación de identidad. Es decir, si su flujo de trabajo de emisión de certificados depende de que la información SAN del certificado se añada después de que se cree una CSR, entonces es probable que su CA pueda ser utilizada de forma maliciosa.
¿Por qué ocurre esto?
Para añadir información SAN a un certificado de forma segura, esta debe incluirse en la parte firmada de su solicitud de certificado. La información SAN puede enviarse dentro de una CSR o junto a ella. Y la Microsoft CA puede configurarse (estableciendo el indicador de política “EDITF_ATTRIBUTESUBJECTALTNAME2”) para confiar y utilizar ambas ubicaciones al añadir información SAN a un certificado. Sin embargo, CSS no suele recomendar el uso de este indicador.
Añadir la información SAN después de que una CSR haya sido firmada significa que no se puede incluir la información SAN del certificado dentro de la parte firmada. Por lo tanto, la información SAN debe añadirse al final de la CSR. Este método añade información SAN a la CSR en forma de atributo de solicitud de certificado. Un atributo de solicitud de certificado, en este caso, solo puede estar fuera de la parte firmada de la solicitud original y, por lo tanto, no se considera seguro. Añadir información SAN de esta manera significa que la información SAN puede ser modificada en cualquier momento y por cualquier persona. Normalmente, esto no se considera seguro, y es la razón por la que Microsoft y CSS advierten encarecidamente contra este método.
Desafortunadamente, así es exactamente como muchos administradores han estructurado su flujo de trabajo de CSR. Un equipo de aplicaciones genera una CSR, que luego se envía al Oficial de Certificados para su firma. El Oficial de Certificados añade entonces toda la información SAN apropiada a la solicitud, firma la CSR y devuelve el certificado firmado. ¿Le resulta familiar?
Desafortunadamente, veo este tipo de configuración con demasiada frecuencia. Y hasta cierto punto, es comprensible.
Pero, ¿cuál es la alternativa?
En el pasado, he sugerido que el mejor enfoque es asegurar que el equipo de aplicaciones conozca cuál debe ser la información SAN apropiada y que toda la información SAN se incluya como parte del proceso de generación de la CSR. Rechazando cualquier CSR que carezca de la información SAN adecuada y firmando solo aquellas que sean correctas.
Esto sigue siendo un buen consejo.
Pero para aquellos entornos donde este enfoque simplemente no funcione, puede haber una alternativa.
Volver a firmar las CSR
Una opción más segura para añadir información SAN a una CSR ya firmada es utilizar un certificado de agente de inscripción (EA) para volver a firmar la solicitud original. A continuación, puede especificar la información SAN correcta y volver a firmar la solicitud original con el certificado EA.
Esto permite que la información SAN se incluya después de la creación inicial del certificado, pero que siga estando en una parte firmada de una CSR.
A continuación, se explica cómo:
- Adquirir un certificado de agente de inscripción
- Modificar una plantilla de certificado SSL para requerir un certificado EA para su emisión
- Adquirir una CSR que necesite información SAN
- Utilizar el certificado EA para volver a firmar la CSR mientras se añade la información SAN.
A continuación, se presenta un resumen rápido de estos 4 pasos. Este blog no es una guía prescriptiva, sino que tiene como objetivo proporcionar una visión general del proceso.
1.) Adquirir un certificado de agente de inscripción
Se trata de un certificado basado en la plantilla predeterminada de Agente de Inscripción. El certificado EA resultante debe contener la extensión de política de aplicación "Agente de Solicitud de Certificado" (1.3.6.1.4.1.311.20.2.1.).
Este certificado (y la clave privada asociada) debe ubicarse en una estación de trabajo donde el administrador tenga acceso a ambos. Es este certificado el que un Oficial de Certificados seleccionaría cuando se le solicite durante el proceso de nueva firma.
2.) Modificar una plantilla de certificado SSL para requerir un certificado EA para su emisión
Modifique su plantilla SSL existente para requerir una firma EA. Esta plantilla también debe configurarse para aceptar el sujeto en la propia solicitud.
Esto significa que solo aquellos que posean un certificado EA podrán utilizar esta plantilla. Y aunque los agentes de inscripción restringidos no son el objetivo de esta publicación de blog, podría considerar especificar un agente de inscripción particular para la plantilla SSL específica que se está probando para este ejercicio.
3.) Adquirir una CSR que necesite información SAN
La creación de una CSR puede lograrse de múltiples maneras. Esta publicación de blog asumirá que ya existe una CSR. A continuación, se presenta una descripción general de una CSR existente:
PKCS10 Certificate Request:
Version: 1
Subject:
CN=Demonstration Web Server v1
Name Hash(sha1): ded0833a1bb48a7a747a06598988c9e12ef97342
Name Hash(md5): bd27f43381a77a239a935f86206424e5
2.5.29.17: Flags = 0, Length = 1f
Subject Alternative Name
DNS Name=Banana.css-vstc.com
DNS Name=Banana
Signature matches Public Key
Key Id Hash(rfc-sha1): bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Key Id Hash(sha1): 53 bb 85 45 53 3f 9a ef aa 59 08 91 37 da b1 c7 c4 29 9d 2d
Como puede observar, este CSR tiene un sujeto y un nombre alternativo de sujeto (SAN).
A efectos de demostración, modificaremos la información del SAN.
4.) Utilice el certificado EA para volver a firmar el CSR mientras añade la información del SAN
Mediante un simple certreq.exe Command, puede utilizar el certificado EA para volver a firmar la solicitud anterior mediante la siguiente línea de Command:
certreq -policy -config "CA1.csstest.com\CSS Test CA 1" "ORIGINAL-SERVER-REQUEST.REQ" "Server-policy.inf" "Corrected-Server-Request.req"
Como se puede observar, este Command especifica el archivo de solicitud original para construir un nuevo archivo de solicitud «corregido».
Esta línea de Command especifica un archivo de política denominado "Server-policy.inf" para especificar la nueva información correcta del SAN. Así es como se ve mi "Server-policy.inf" tiene el siguiente aspecto:
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "[email protected]&"
_continue_ = "DNS=Orange.css-vstc.com"
Como puede observar, este es solo un archivo de texto simple que añade la información corregida del SAN como una extensión.
El Command certreq anterior utiliza el archivo «Server-policy.inf» y mi certificado EA para añadir la nueva información del SAN, y luego volver a firmar el CSR original, creando un nuevo archivo.
Internamente en el nuevo CSR resultante, el proceso envuelve nueva información alrededor del CSR original. El contenido original del CSR sigue presente, simplemente está superpuesto dentro del nuevo contenido. A continuación, se presenta una vista abreviada de cómo se ve el nuevo CSR (ahora envuelto):
PKCS7/CMS Message:
CMSG_SIGNED(2)
CMSG_SIGNED_DATA_CMS_VERSION(3)
Content Type: 1.3.6.1.5.5.7.12.2 CMC Data
PKCS7 Message Content:
================ Begin Nesting Level 1 ================
CMS Certificate Request:
Tagged Attributes: 1
Extensions: 1
2.5.29.17: Flags = 0, Length = 2f
Subject Alternative Name
RFC822 [email protected]
DNS Name=Orange.css-vstc.com
================ Begin Nesting Level 2 ================
Element 0:
PKCS10 Certificate Request:
Version: 1
Subject:
CN=Demonstration Web Server v1
Name Hash(sha1): ded0833a1bb48a7a747a06598988c9e12ef97342
Name Hash(md5): bd27f43381a77a239a935f86206424e5
2.5.29.17: Flags = 0, Length = 1f
Subject Alternative Name
DNS Name=Banana.css-vstc.com
DNS Name=Banana
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Signature matches Public Key
Key Id Hash(rfc-sha1): bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Key Id Hash(sha1): 53 bb 85 45 53 3f 9a ef aa 59 08 91 37 da b1 c7 c4 29 9d 2d
---------------- End Nesting Level 2 ----------------
Tagged Content Info: 0
Tagged Other Messages: 0
---------------- End Nesting Level 1 ----------------
Como puede observar, el CSR original sigue presente, pero ahora con nueva información del SAN envuelta alrededor de él y firmado con el certificado EA.
Este nuevo CSR sería entonces simplemente enviado a la CA:
Certreq -submit -config "CA1.csstest.com\CSS Test CA 1" "Corrected-Server-Request.req" "Server.cer"
Al enviar este certificado a la CA se obtendrá un certificado cuya información del SAN será actualizada por un Oficial de Certificados. Más importante aún, esto se logra sin establecer el indicador de política «EDITF_ATTRIBUTESUBJECTALTNAME2».
En este caso, de Banana.css-vstc.com to Orange.css-vstc.com.
El módulo de política de la CA no rechazará esta solicitud, ya que esta nueva información del SAN sigue estando en una parte firmada de la solicitud de firma de certificado y está, de hecho, firmada. Esta solución da como resultado una CA cuya seguridad se mantiene, al tiempo que permite la flexibilidad de añadir información del SAN a los CSR existentes de forma segura y controlada.
Resumen
Si usted está a cargo de una PKI corporativa y está considerando establecer el indicador de política «EDITF_ATTRIBUTESUBJECTALTNAME2» en su CA para cumplir con los requisitos del flujo de trabajo del SAN, le sugiero que considere una alternativa a esta configuración de política.
En su lugar, considere utilizar un certificado EA para volver a firmar los CSR mientras especifica la información correcta del SAN.
Volver a firmar sus CSR utilizando Certreq.exe con un certificado de agente de inscripción permite la adición segura de información del SAN a un CSR *después* de su creación, pero de una manera que no deja su PKI vulnerable a ataques de suplantación de identidad.
