¿Es posible crear un certificado de CA (incluso sin firma), que solo está permitido firmar certificados para un dominio o dominios limitados específicos, de modo que no se pueda usar mal para otros dominios?
¿Es posible crear un certificado de CA (incluso sin firma), que solo está permitido firmar certificados para un dominio o dominios limitados específicos, de modo que no se pueda usar mal para otros dominios?
(Supongo que está hablando de certificados para servidores SSL).
Técnicamente no. Lo que sería más cercano sería la extensión Name Constraints
(consulte sección 4.2.1.10 del RFC 5280 ) ( OID 2.5.29.30 ), que teóricamente permite restringir un subárbol PKI completo a un explícito Conjunto de dominios (y subdominios de los mismos). La extensión admite semánticas tanto de listas blancas como de listas negras (en su caso, le gustaría una lista blanca). En la práctica, sin embargo, esto falla por dos razones:
La extensión Name Constraints
en su mayoría no es compatible con las implementaciones existentes de SSL. Es probable que ignoren la extensión.
Cuando un cliente SSL se conecta a un servidor, busca el nombre del servidor en el certificado del servidor, como se especifica en RFC 2818, sección 3.1 . Buscará los nombres del tipo dNSName
en una extensión Subject Alt Name
, y estos nombres están cubiertos (teóricamente) por el Name Constraints
. Sin embargo, si el certificado del servidor carece de una extensión Subject Alt Name
, los clientes recurrirán al Nombre común (en el subjectDN
). El nombre común no está dentro del alcance de Name Constraints
. Esto significa que un certificado podría evadir las restricciones de nombre al omitir la extensión Subject Alt Name
y poner un nombre de servidor arbitrario en su nombre común.
(Esta es toda la historia de X.509: muchos enganches y disposiciones para muchas características útiles, que no funcionan debido a la falta de apoyo de la implementación y la falta de coordinación entre los organismos de especificación).
Thomas Pornin 's a Name Constraints
está creciendo.
Descubrí que OpenSSL 1.0.1k y Windows 7 son compatibles con la extensión.
Al usar XCA , creé un certificado CA autofirmado y agregué una extensión crítica Name Constraints
para .lab.example.com
, agregando la siguiente línea en la pestaña "Avanzado" durante la creación del certificado:
nameConstraints=critical,permitted;DNS:.lab.example.com
Nota: la restricción no debe tener un punto inicial. Es técnicamente incorrecto, pero el soporte para esto se está expandiendo: enlace
Luego, utilicé ese certificado de CA para firmar otros dos certificados para servidores HTTPS:
test.lab.example.com
- Válido bad.google.com
- Claramente inválido A continuación, después de configurar las entradas de DNS en consecuencia, usé este simple-https-server.py
modificado para ejecutar un servidor HTTPS, una vez con cada uno de los certificados generados:
./simple-https-server --certfile test.lab.example.com.pem --hostname test.lab.example.com
y
./simple-https-server --certfile bad.google.com.pem --hostname bad.google.com
Después de instalar el certificado de CA en la confianza del sistema operativo, intenté visitar cada sitio con varios clientes.
OpenSSL 1.0.1k parece apoyar esto. curl
me dio el siguiente error cuando intenté visitar bad.google.com
:
curl: (60) La Autoridad de Certificación para este certificado no tiene permiso para emitir un certificado con este nombre.
Chrome en Windows 7 también hace lo correcto. Chrome proporciona un net::ERR_CERT_INVALID
bastante genérico, pero el visor de certificados de Windows es bastante explícito:
El certificado tiene un nombre no válido. El nombre no se incluye en la lista permitida o se excluye explícitamente.
También intenté firmar un certificado que no especificaba un Nombre alternativo del sujeto, en lugar de basarme únicamente en el antiguo nombre común.
OpenSSL / curl aún se negó a aceptar el certificado.
Tanto Chrome como IE11 en Windows se negaron a aceptar el certificado en Windows, aunque Windows en sí (al ver el certificado del servidor) no se quejó de ello. Para mí, eso significa que los navegadores están haciendo más que simplemente pedirle al sistema operativo que verifique el certificado, lo cual es bueno.
Sin embargo, parece que las restricciones de nombre son no es compatible con OSX .
Me siento seguro al pedirle a otros que instalen mi certificado de CA raíz, sin ponerlos en riesgo.
Lea otras preguntas en las etiquetas public-key-infrastructure tls certificates certificate-authority