No.

(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 answer está bien, pero un poco desactualizado. El soporte para Name Constraints está creciendo.

Descubrí que OpenSSL 1.0.1k y Windows 7 son compatibles con la extensión.

Prueba

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.

Resultados

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.

Referencias

• enlace

Actualización 1

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 .

Conclusión

Me siento seguro al pedirle a otros que instalen mi certificado de CA raíz, sin ponerlos en riesgo.