Este blog es la continuación de una serie de blogs relacionados con los peligros de añadir información sobre el nombre alternativo del sujeto (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 hacer que la CA sea 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 crear una CSR, es probable que su CA pueda utilizarse de forma malintencionada.
¿Por qué?
Para añadir información SAN a un certificado de forma segura, la información SAN debe incluirse dentro de la parte firmada de su solicitud de certificado. La información SAN puede presentarse dentro de una CSR, o junto a ella. Y 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 esta opción.
Añadir la información SAN después de que se haya firmado una CSR 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 la información SAN al CSR en forma de atributo de solicitud de certificado. En este caso, un atributo de solicitud de certificado sólo puede estar fuera de la parte firmada de la solicitud original, por lo que 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 cualquiera. Normalmente esto no se considera seguro, y es la razón por la que Microsoft y CSS advierten enérgicamente contra este método.
Por desgracia, así es exactamente como muchos administradores han estructurado su flujo de trabajo de CSR. Un equipo de aplicaciones genera una CSR y la envía al responsable de certificados para que la firme. A continuación, el responsable de certificados añade toda la información SAN pertinente a la solicitud, firma la CSR y devuelve el certificado firmado. ¿Le resulta familiar?
Por desgracia, 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 asegurarse de que el equipo de la aplicación sabe cuál debe ser la información SAN apropiada, y asegurarse de que toda la información SAN se incluye como parte del proceso de generación de CSR. Rechazar cualquier CSR que carezca de la información SAN apropiada, y firmar sólo aquellos que sean correctos.
Sigue siendo un buen consejo.
Pero para aquellos entornos en los que este enfoque simplemente no funcione, puede haber una alternativa.
Dimisión de los 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.
He aquí cómo:
- Adquirir un certificado de agente de matriculación
- Modificar una plantilla de certificado SSL para exigir un certificado EA para su emisión.
- Adquirir un RSE que necesite información SAN
- Utilice el certificado EA para renunciar al CSR mientras añade la información SAN.
A continuación se ofrece un rápido resumen de estos 4 pasos. Este blog no es una guía prescriptiva, sino que pretende ofrecer una visión general del proceso.
1.) Adquirir un certificado de agente de matriculación
Se trata de un certificado basado en la plantilla predeterminada del 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) deben estar ubicados en una estación de trabajo en la que el administrador tenga acceso a ambos. Es este certificado el que un responsable de certificados seleccionaría cuando se le preguntara durante el proceso de refirma.
2.) Modificar una plantilla de certificado SSL para exigir un certificado EA para su expedición.
Modifique su plantilla SSL existente para que requiera una Firma EA. Esta plantilla también debe configurarse para aceptar el asunto en la propia solicitud.
Esto significa que sólo 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 entrada de blog, podría considerar especificar un agente de inscripción específico para la plantilla SSL específica que se está probando para este ejercicio.
3.) Adquirir un RSE que necesite información RAS
La creación de un CSR puede llevarse a cabo de múltiples maneras. En esta entrada se parte del supuesto de que ya existe una RSE. A continuación se ofrece una visión general de un 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 ver, este CSR tiene un asunto y un nombre alternativo de asunto.
Para fines de demostración, vamos a cambiar la información SAN.
4.) Utilice el certificado EA para volver a firmar la CSR añadiendo la información SAN.
Utilizando un simple certreq.exe commandpuede utilizar el certificado EA para volver a firmar la solicitud anterior utilizando la siguiente línea command :
certreq -policy -config "CA1.csstest.com\CSS Test CA 1" "ORIGINAL-SERVER-REQUEST.REQ" "Server-policy.inf" "Corrected-Server-Request.req"
Como puede verse, este command especifica el fichero de petición original para construir un nuevo fichero de petición "corregido".
Esta línea command especifica un archivo de políticas llamado "Server-policy.inf" para especificar correctamente la nueva información SAN. Esto es lo que mi "Server-policy.inf" parece:
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "[email protected]&"
_continue_ = "DNS=Orange.css-vstc.com"
Como puede ver, se trata de un simple archivo de texto que añade la información SAN corregida como extensión.
El anterior certreq command utiliza el archivo "Server-policy.inf", y mi certificado EA para añadir la nueva información SAN, y luego volver a firmar el CSR original, creando un nuevo archivo.
Internamente al nuevo CSR resultante, el proceso envuelve nueva información alrededor del CSR original. El contenido original del CSR sigue estando ahí, sólo que está superpuesto dentro del nuevo contenido. A continuación se muestra de forma abreviada el aspecto del 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 ver, la CSR original sigue ahí, pero ahora con la nueva información SAN envuelta alrededor, y firmada con el certificado EA.
Este nuevo CSR simplemente se enviaría a la CA:
Certreq -submit -config "CA1.csstest.com\CSS Test CA 1" "Corrected-Server-Request.req" "Server.cer"
El envío de este certificado a la CA dará como resultado un certificado cuya información SAN será actualizada por un funcionario de certificación. Y lo que es más importante, esto se consigue sin establecer el indicador de directiva EDITF_ATTRIBUTESUBJECTALTNAME2".
En este caso, de Banana.css-vstc.com to Orange.css-vstc.com.
El módulo de políticas de la CA no rechazará esta solicitud, ya que esta nueva información SAN sigue estando en una parte firmada de la solicitud de firma de certificado, y de hecho está firmada. Esta solución da como resultado una CA cuya seguridad se mantiene, al tiempo que permite la flexibilidad de añadir información SAN a las CSR existentes, de forma segura y controlada.
Resumen
Si está a cargo de una PKI corporativa y está considerando establecer el indicador de política "EDITF_ATTRIBUTESUBJECTALTNAME2" en su CA para cumplir los requisitos de flujo de trabajo de SAN, le sugiero que considere una alternativa a esta configuración de política.
En su lugar, considere la posibilidad de utilizar un certificado EA para volver a firmar las CSR especificando la información SAN correcta.
Volver a firmar sus CSR utilizando Certreq.exe con un certificado de agente de inscripción permite la adición segura de información SAN a una CSR *después* de su creación, pero de una forma que no deja su PKI vulnerable a ataques de suplantación.
