Certificado comodín

Un ejemplo de un certificado comodín en https://plus.google.com (note el asterisco: *).
Un ejemplo de un certificado EV actuando como certificado comodín en https://www.ssl.com (note el campo Subject Alternative Name (SAN)).

Un certificado comodín es un certificado de clave pública que se puede utilizar con varios subdominios de un dominio.[1]​

Dependiendo del número de subdominios una ventaja podría ser que ahorra dinero y también podría ser más conveniente.

Limitaciones

Solo un único nivel de subdominio es admitido.[2]​

No es posible conseguir un comodín para un certificado de validación extendida.[3]​

Una solución podría ser la de añadir cada nombre de host virtual en la extensión Subject Alternative Name (SAN),[4]​[5]​[6]​ el principal problema es que el certificado tiene que ser reeditado siempre que se agregue un nuevo servidor virtual (ver Seguridad de la capa de transporte § Soporte para servidores virtuales por nombre para más información).

Los comodines se pueden añadir como dominios en los certificados multi-dominio o Certificados de Comunicaciones Unificadas (UCC).[7]​ Además, los comodines en sí pueden tener extensiones subjectAltName, incluyendo otros comodines. Por ejemplo: El certificado comodín * .wikipedia.org tiene * .m.wikimedia.org como un nombre alternativo del sujeto. Por lo tanto, asegura https://www.wikipedia.org así como el nombre del sitio web completamente diferente https://meta.m.wikimedia.org.[8]​

RFC 6125 argumenta en contra de certificados comodín por motivos de seguridad.[9]​

Ejemplo

En el caso de un certificado comodín para *.example.com, estos dominios serían válidos:

  • payment.example.com
  • contact.example.com
  • login-secure.example.com
  • www.example.com

Debido a que el comodín solo cubre un nivel de subdominios (el asterisco no coincide con puntos y aparte),[10]​ estos dominios no serían válidos para el certificado:

  • test.login.example.com

El dominio "desnudo" tampoco es válido[11]​ (y hay que añadir por separado como un SubjectAltName):

  • example.com

Véase también

Referencias

  1. ↑ Certificado comodín SSL en Verisign.com
  2. ↑ Wildcard SSL certificate limitation on QuovadisGlobal.com
  3. ↑ «Guidelines For The Issuance And Management Of Extended Validation Certificates, Version 1.5.2». CA/Browser Forum. 16 de octubre de 2014. p. 10. Consultado el 15 de diciembre de 2014. «Wildcard certificates are not allowed for EV Certificates.» 
  4. ↑ x509v3_config-Subject Alternative Name Archivado el 15 de enero de 2015 en Wayback Machine. (en inglés)
  5. ↑ The subjectAltName field (en inglés)
  6. ↑ The SAN option is available for EV SSL Certificates on Symantec.com Archivado el 24 de mayo de 2013 en Wayback Machine. (en inglés)
  7. ↑ Wildcard domains can be used within UCC on SSL.com (en inglés)
  8. ↑ «SSLTools Certificate Lookup of Wikipedia.org's wildcard ssl certificate». Archivado desde el original el 13 de junio de 2016. Consultado el 18 de enero de 2015. 
  9. ↑ «RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)». Internet Engineering Task Force. Marzo de 2011. p. 31. Consultado el 10 de diciembre de 2014. «This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). [...] Several security considerations justify tightening the rules: [...]». 
  10. ↑ «RFC 2818 - HTTP Over TLS». Internet Engineering Task Force. Mayo de 2000. p. 5. Consultado el 15 de diciembre de 2014. «[...] *.a.com matches foo.a.com but not bar.foo.a.com.» 
  11. ↑ «RFC 2595 - Using TLS with IMAP, POP3 and ACAP». Internet Engineering Task Force. Junio de 1999. p. 3. Consultado el 15 de diciembre de 2014. «For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.» 

RFCs relevantes