En las redes informáticas, un certificado comodín es un certificado de clave pública que se puede utilizar con varios subdominios de un dominio. El uso principal es para proteger sitios web con HTTPS , pero también existen aplicaciones en muchos otros campos. En comparación con los certificados convencionales, un certificado comodín puede ser más económico y conveniente que un certificado para cada subdominio. Los certificados comodín multidominio simplifican aún más la complejidad y reducen los costes al proteger varios dominios y sus subdominios.
Ejemplo
Un solo certificado comodín para https://*.example.com
protegerá todos estos subdominios en el https://*.example.com
dominio:
payment.example.com
contact.example.com
login-secure.example.com
www.example.com
En lugar de obtener certificados separados para subdominios, puede usar un solo certificado para todos los dominios y subdominios principales y reducir el costo. [1]
Debido a que el comodín solo cubre un nivel de subdominios (el asterisco no coincide con puntos), [2] estos dominios no serían válidos para el certificado:
test.login.example.com
El dominio "simple" es válido cuando se agrega por separado como un nombre alternativo del sujeto ( SubjectAltName
): [3]
example.com
Tenga en cuenta las posibles excepciones de las CA, por ejemplo, el certificado comodín plus de DigiCert contiene una propiedad "Plus" automática para el dominio simple example.com
.
Tipo de certificados comodín
Los certificados comodín se clasifican en función del nivel de validación, el número de dominio y el número de servidores con los que se pueden utilizar. Asimismo, se denominan certificado comodín de validación de dominio, certificado comodín de validación de organización y certificado comodín de validación extendida cuando los categorizamos según el nivel de validación. El nombre Certificados comodín multidominio y Certificados comodín multiservidor se dan según el número de dominio y el número de servidor. Todos los tipos de certificados comodín firmados por CA populares se clasifican y enumeran en Internet. Por lo tanto, existen tipos de comodines que pueden proteger múltiples dominios, múltiples servidores y proporcionar diferentes niveles de validación.
Limitaciones
Solo se admite un nivel único de coincidencia de subdominios de acuerdo con RFC 2818 . [4]
No es posible obtener un comodín para un certificado de validación extendida . [5] Una solución podría ser agregar cada nombre de host virtual en la extensión de Nombre alternativo del sujeto (SAN), [6] [7] el principal problema es que el certificado debe volver a emitirse cada vez que se agrega un nuevo servidor virtual. (Consulte Seguridad de la capa de transporte § Compatibilidad con servidores virtuales basados en nombres para obtener más información).
Los comodines se pueden agregar como dominios en certificados multidominio o certificados de comunicaciones unificadas (UCC). Además, los propios comodines pueden tener subjectAltName
extensiones, incluidos otros comodines. Por ejemplo, el certificado comodín *.wikipedia.org
tiene *.m.wikimedia.org
como nombre alternativo del sujeto. Por lo tanto, protege www.wikipedia.org
el nombre del sitio web completamente diferente meta.m.wikimedia.org
. [8]
RFC 6125 argumenta en contra de los certificados comodín por motivos de seguridad. [9]
Ejemplos de
El comodín se aplica solo a un nivel del nombre de dominio.
label.label.label.TLD
*.domain.com
está bien. Coincidiráwww.domain.com
pero nodomain.com
y nozzz.www.domain.com
El comodín puede aparecer en cualquier lugar dentro de una etiqueta como un "comodín parcial" según las especificaciones anteriores [10]
f*.domain.com
está bien. Coincidiráfrog.domain.com
pero nofrog.super.domain.com
baz*.example.net
está bien y coincidebaz1.example.net
*baz.example.net
está bien y coincidefoobaz.example.net
b*z.example.net
está bien y coincidebuzz.example.net
Sin embargo, no se recomienda el uso de certificados de "comodín parcial". A partir de 2011, la compatibilidad con comodines parciales es opcional y no se permite explícitamente en los encabezados SubjectAltName que son necesarios para los certificados de varios nombres. [11] Todos los principales navegadores han eliminado deliberadamente el soporte para certificados con comodines parciales; [12] [13] darán como resultado un error "SSL_ERROR_BAD_CERT_DOMAIN". De manera similar, es típico que las bibliotecas estándar en los lenguajes de programación no admitan certificados de "comodín parcial". Por ejemplo, cualquier certificado de "comodín parcial" no funcionará con las últimas versiones de Python [14] y Go. Por lo tanto,
No permita una etiqueta que consista en su totalidad solo de un comodín a menos que sea la etiqueta más a la izquierda
sub1.*.domain.com
No se permite.
No se permite un certificado con varios comodines en un nombre.
*.*.domain.com
*
No se permite un certificado con más un dominio de nivel superior.
*.com
Demasiado general y no debería permitirse.
*
Nombres de dominio internacionales codificados en ASCII (A-etiqueta) son etiquetas que son codificada en ASCII y comienzan con xn--
.
No permita comodines en una etiqueta internacional.
xn--caf-dma.com
escafé.com
xn--caf-dma*.com
No se permiteLw*.xn--caf-dma.com
esta permitido
Referencias
- ^ "Certificado comodín explicado en términos más simples" . 23 de mayo de 2016.
- ^ "RFC 2818 - HTTP sobre TLS" . Grupo de trabajo de ingeniería de Internet . Mayo de 2000. p. 5 . Consultado el 15 de diciembre de 2014 .
[...] * .a.com coincide con foo.a.com pero no con bar.foo.a.com.
- ^ "RFC 2595 - Usando TLS con IMAP, POP3 y ACAP" . Grupo de trabajo de ingeniería de Internet . Junio de 1999. p. 3 . Consultado el 15 de diciembre de 2014 .
Por ejemplo, * .example.com coincidiría con a.example.com, foo.example.com, etc. pero no coincidiría con example.com.
- ^ Limitación del certificado SSL comodín en QuovadisGlobal.com
- ^ "Directrices para la emisión y gestión de certificados de validación ampliada, versión 1.5.2" (PDF) . CA / Foro de navegadores. 2014-10-16. pag. 10 . Consultado el 15 de diciembre de 2014 .
Los certificados comodín no están permitidos para los certificados EV.
- ^ x509v3_config Nombre alternativo del sujeto
- ^ La opción SAN está disponible para certificados SSL con EV en Symantec.com
- ^ Búsqueda de certificados SSLTools del certificado ssl comodín de Wikipedia.org
- ^ "RFC 6125 - Representación y verificación de la identidad del servicio de aplicación basada en dominio dentro de la infraestructura de clave pública de Internet utilizando certificados X.509 (PKIX) en el contexto de la seguridad de la capa de transporte (TLS)" . Grupo de trabajo de ingeniería de Internet . Marzo de 2011. p. 31 . Consultado el 10 de diciembre de 2014 .
Este documento establece que el carácter comodín '*' NO DEBE incluirse en los identificadores presentados, pero PUEDE ser verificado por los clientes de la aplicación (principalmente por motivos de compatibilidad con versiones anteriores de la infraestructura implementada). [...] Varias consideraciones de seguridad justifican el endurecimiento de las reglas: [...]
- ^ Rescorla, E. (mayo de 2000). "RFC 2818 - HTTP sobre TLS" . tools.ietf.org . Consultado el 20 de abril de 2019 .
- ^ Saint-Andre, P .; Hodges, J. (marzo de 2011). "RFC 6125 - Representación y verificación de la identidad del servicio de aplicación basada en dominio dentro de la infraestructura de clave pública de Internet utilizando certificados X.509 (PKIX) en el contexto de la seguridad de la capa de transporte (TLS)" . tools.ietf.org . Consultado el 20 de abril de 2019 .
- ^ "No permitir la compatibilidad con * .example.net, * a.example.net y a * b.example.net en el manejo de comodines de certificado" . The Chromium Projects, Google Inc. 3 de diciembre de 2014 . Consultado el 21 de octubre de 2020 .
- ^ "Limite la compatibilidad con ID de DNS comodín a nombres con el formato * .example.com (no foo * .example.com)" . La Fundación Mozilla. 10 de diciembre de 2014 . Consultado el 21 de octubre de 2020 .
- ^ "No permitir la compatibilidad con * .example.net, * a.example.net y a * b.example.net en el manejo de comodines de certificado" . La Fundación de Software Python. 26 de noviembre de 2017 . Consultado el 21 de octubre de 2020 .
RFC relevantes
- "RFC 2595 - Usando TLS con IMAP, POP3 y ACAP" . Grupo de trabajo de ingeniería de Internet . Junio de 1999. p. 3.
- "RFC 2818 - HTTP sobre TLS" . Grupo de trabajo de ingeniería de Internet . Mayo de 2000. p. 5.
- "RFC 6125 - Representación y verificación de la identidad del servicio de aplicación basada en dominio dentro de la infraestructura de clave pública de Internet utilizando certificados X.509 (PKIX) en el contexto de la seguridad de la capa de transporte (TLS)" . Grupo de trabajo de ingeniería de Internet . Marzo de 2011.