stringtranslate.com

Certificado de clave pública

En criptografía , un certificado de clave pública , también conocido como certificado digital o certificado de identidad , es un documento electrónico utilizado para demostrar la validez de una clave pública . [1] [2] El certificado incluye la clave pública e información sobre ella, información sobre la identidad de su propietario (llamado el sujeto) y la firma digital de una entidad que ha verificado el contenido del certificado (llamado el emisor). Si el dispositivo que examina el certificado confía en el emisor y encuentra que la firma es una firma válida de ese emisor, entonces puede usar la clave pública incluida para comunicarse de forma segura con el sujeto del certificado. En el cifrado de correo electrónico , la firma de código y los sistemas de firma electrónica , el sujeto de un certificado suele ser una persona u organización. Sin embargo, en Transport Layer Security (TLS) el sujeto de un certificado suele ser una computadora u otro dispositivo, aunque los certificados TLS pueden identificar organizaciones o individuos además de su función principal en la identificación de dispositivos. TLS, a veces llamado por su nombre anterior Secure Sockets Layer (SSL), es notable por ser parte de HTTPS , un protocolo para navegar de forma segura en la web .

En un esquema típico de infraestructura de clave pública (PKI), el emisor del certificado es una autoridad de certificación (CA), [3] normalmente una empresa que cobra a los clientes una tarifa por emitir certificados para ellos. Por el contrario, en un esquema de red de confianza , los individuos firman las claves de los demás directamente, en un formato que realiza una función similar a un certificado de clave pública. En caso de que la clave se vea comprometida, puede ser necesario revocar un certificado .

El formato más común para los certificados de clave pública se define en X.509 . Debido a que X.509 es muy general, el formato está aún más limitado por los perfiles definidos para ciertos casos de uso, como la infraestructura de clave pública (X.509) , tal como se define en RFC  5280.

Tipos de certificado

Los roles del certificado raíz, del certificado intermedio y del certificado de entidad final en la cadena de confianza .

Certificado de servidor TLS/SSL

El protocolo Transport Layer Security (TLS), así como su predecesor obsoleto, el protocolo Secure Sockets Layer (SSL), garantiza que la comunicación entre un equipo cliente y un servidor sea segura. El protocolo requiere que el servidor presente un certificado digital que demuestre que es el destino previsto. El cliente que se conecta realiza una validación de la ruta de certificación , lo que garantiza que:

  1. El asunto del certificado coincide con el nombre de host (que no debe confundirse con el nombre de dominio ) al que el cliente intenta conectarse.
  2. Una autoridad de certificación confiable ha firmado el certificado.

El campo Asunto del certificado debe identificar el nombre de host principal del servidor como Nombre común . [ aclaración necesaria ] El nombre de host debe ser de acceso público, no usar direcciones privadas o dominios reservados . [4] Un certificado puede ser válido para varios nombres de host (por ejemplo, un dominio y sus subdominios). Dichos certificados se denominan comúnmente certificados de Nombre alternativo del sujeto (SAN) o Certificados de comunicaciones unificadas (UCC) . Estos certificados contienen el campo Nombre alternativo del sujeto , aunque muchas CA también los colocan en el campo Nombre común del sujeto para compatibilidad con versiones anteriores. Si algunos de los nombres de host contienen un asterisco (*), un certificado también puede denominarse certificado comodín .

Una vez que la validación de la ruta de certificación es exitosa, el cliente puede establecer una conexión encriptada con el servidor.

Los servidores que dan a Internet, como los servidores web públicos , deben obtener sus certificados de una autoridad de certificación (CA) pública y confiable.

Certificado de cliente TLS/SSL

Los certificados de cliente autentican al cliente que se conecta a un servicio TLS, por ejemplo, para proporcionar control de acceso. Debido a que la mayoría de los servicios proporcionan acceso a personas, en lugar de dispositivos, la mayoría de los certificados de cliente contienen una dirección de correo electrónico o un nombre personal en lugar de un nombre de host. Además, la autoridad de certificación que emite el certificado de cliente suele ser el proveedor de servicios al que se conecta el cliente, ya que es el proveedor que necesita realizar la autenticación. Algunos proveedores de servicios incluso ofrecen certificados SSL gratuitos como parte de sus paquetes. [5]

Si bien la mayoría de los navegadores web admiten certificados de cliente, la forma más común de autenticación en Internet es un par de nombre de usuario y contraseña. Los certificados de cliente son más comunes en redes privadas virtuales (VPN) y Servicios de Escritorio Remoto , donde autentican dispositivos.

Certificado de correo electrónico

De acuerdo con el protocolo S/MIME , los certificados de correo electrónico pueden establecer la integridad de los mensajes y cifrarlos. Para establecer una comunicación por correo electrónico cifrada, las partes que se comunican deben disponer de sus certificados digitales con antelación. Cada una de ellas debe enviar a la otra un correo electrónico firmado digitalmente y optar por importar el certificado del remitente.

Algunas autoridades de certificación de confianza pública proporcionan certificados de correo electrónico, pero lo más común es que se use S/MIME cuando se comunica dentro de una organización determinada, y esa organización ejecuta su propia CA, en la que confían los participantes de ese sistema de correo electrónico.

Certificados raíz y autofirmados

Un certificado autofirmado es un certificado con un sujeto que coincide con su emisor y una firma que puede verificarse mediante su propia clave pública.

Los certificados autofirmados tienen sus propios usos limitados. Tienen un valor de confianza total cuando el emisor y el usuario único son la misma entidad. Por ejemplo, el Sistema de cifrado de archivos de Microsoft Windows emite un certificado autofirmado en nombre del usuario que cifra y lo utiliza para descifrar datos de forma transparente sobre la marcha. La cadena de confianza de certificados digitales comienza con un certificado autofirmado, llamado certificado raíz , ancla de confianza o raíz de confianza . Una autoridad de certificación firma automáticamente un certificado raíz para poder firmar otros certificados.

Un certificado intermedio tiene una finalidad similar a la del certificado raíz: su único uso es firmar otros certificados. Sin embargo, un certificado intermedio no está autofirmado. Un certificado raíz u otro certificado intermedio deben firmarlo.

Un certificado de entidad final o de hoja es cualquier certificado que no puede firmar otros certificados. Por ejemplo, los certificados de servidor y cliente TLS/SSL, los certificados de correo electrónico, los certificados de firma de código y los certificados calificados son todos certificados de entidad final.

Certificado de nombre alternativo del sujeto

Un ejemplo de una sección de Nombre alternativo del sujeto para nombres de dominio propiedad de la Fundación Wikimedia

Los certificados de nombre alternativo del sujeto (SAN) son una extensión de X.509 que permite asociar varios valores con un certificado de seguridad mediante un subjectAltNamecampo. [6] Estos valores se denominan nombres alternativos del sujeto (SAN). Los nombres incluyen: [7]

RFC  2818 (mayo de 2000) especifica los nombres alternativos de sujeto como el método preferido para agregar nombres DNS a los certificados, lo que deja en desuso el método anterior de colocar nombres DNS en el commonNamecampo. [8] La versión 58 de Google Chrome (marzo de 2017) eliminó la compatibilidad para verificar el commonNamecampo y, en su lugar, solo se observan los SAN. [8]

Como se muestra en la imagen de la sección de Wikimedia a la derecha, el campo SAN puede contener comodines. [9] No todos los proveedores admiten o aprueban la combinación de comodines en los certificados SAN. [10]

Certificado comodín

Un ejemplo de un certificado comodín en comifuro.net (tenga en cuenta el asterisco :)*

Un certificado de clave pública que utiliza un asterisco * (el comodín ) en su fragmento de nombre de dominio se denomina certificado comodín. Mediante el uso de *, se puede utilizar un único certificado para varios subdominios . Se utiliza habitualmente para la seguridad de la capa de transporte en redes informáticas .

Por ejemplo, un único certificado comodín https://*.example.comprotegerá todos estos subdominios en el https://*.example.comdominio:

En lugar de obtener certificados separados para subdominios, puede utilizar un único certificado para todos los dominios y subdominios principales y reducir costos. [11]

Debido a que el comodín solo cubre un nivel de subdominios (el asterisco no coincide con los puntos), [12] estos dominios no serían válidos para los certificados: [13]

Tenga en cuenta las posibles excepciones de las CA, por ejemplo, el certificado wildcard-plus de DigiCert contiene una propiedad "Plus" automática para el dominio simple example.com. [ cita requerida ]

Limitaciones

De acuerdo con RFC  2818, solo se admite un único nivel de coincidencia de subdominios . [1]

No es posible obtener un comodín para un Certificado de Validación Extendida . [14] Una solución alternativa podría ser agregar cada nombre de host virtual en la extensión de Nombre Alternativo del Sujeto (SAN), [15] [16] el problema principal 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 añadir como dominios en certificados multidominio o certificados de comunicaciones unificadas (UCC). Además, los comodines pueden tener subjectAltNameextensiones, incluidos otros comodines. Por ejemplo, el certificado comodín *.wikipedia.orgtiene *.m.wikimedia.orgun nombre alternativo del sujeto. De este modo, protege www.wikipedia.orgtanto como el nombre de un sitio web completamente diferente meta.m.wikimedia.org. [17]

El RFC  6125 se opone a los certificados comodín por razones de seguridad, en particular a los "comodines parciales". [18]

Más ejemplos

El comodín se aplica solo a un nivel del nombre de dominio. *.example.comcoincide sub1.example.compero no example.comy nosub2.sub1.domain.com

El comodín puede aparecer en cualquier lugar dentro de una etiqueta como un "comodín parcial" según las primeras especificaciones [19].

f*.domain.comEstá bien. Coincidirá frog.domain.compero nofrog.super.domain.com
baz*.example.netEstá bien y coincidebaz1.example.net
*baz.example.netEstá bien y coincidefoobaz.example.net
b*z.example.netEstá bien y coincidebuzz.example.net

Sin embargo, no se recomienda el uso de certificados "partial-wildcard". A partir de 2011, la compatibilidad con comodines parciales es opcional y está explícitamente prohibida en los encabezados SubjectAltName que son necesarios para los certificados de varios nombres. [20] Todos los navegadores principales han eliminado deliberadamente la compatibilidad con certificados parciales con comodines; [21] [22] 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 "partial-wildcard". Por ejemplo, cualquier certificado "partial-wildcard" no funcionará con las últimas versiones de Python [23] y Go. Por lo tanto,

No permita una etiqueta que consista enteramente en un solo comodín a menos que sea la etiqueta más a la izquierda

sub1.*.domain.comNo está permitido.

No se permite un certificado con varios comodines en un nombre.

*.*.domain.com

No se permite un certificado con *un dominio de nivel superior.

*.com

Demasiado general y no debería permitirse.

*

Los nombres de dominio internacionales codificados en ASCII (etiqueta A) son etiquetas que están codificadas en ASCII y comienzan con xn--. Las URL con etiquetas internacionales no pueden contener comodines. [24]

xn--caf-dma.comescafé.com
xn--caf-dma*.comNo está permitido
Lw*.xn--caf-dma.comestá permitido

Otros certificados

Campos comunes

Estos son algunos de los campos más comunes en los certificados. La mayoría de los certificados contienen una serie de campos que no se enumeran aquí. Tenga en cuenta que, en términos de la representación X.509 de un certificado, un certificado no es "plano", sino que contiene estos campos anidados en varias estructuras dentro del certificado.

Ejemplo

Este es un ejemplo de un certificado SSL/TLS decodificado obtenido del sitio web de SSL.com. El nombre común (CN) del emisor se muestra como SSL.com EV SSL Intermediate CA RSA R3, lo que lo identifica como un certificado de validación extendida (EV). La información validada sobre el propietario del sitio web (SSL Corp) se encuentra en el Subjectcampo. El X509v3 Subject Alternative Namecampo contiene una lista de nombres de dominio cubiertos por el certificado. Los campos X509v3 Extended Key Usagey X509v3 Key Usagemuestran todos los usos apropiados.

Uso en la Unión Europea

En la Unión Europea, las firmas electrónicas (avanzadas) en documentos legales se realizan habitualmente mediante firmas digitales acompañadas de certificados de identidad. Sin embargo, solo las firmas electrónicas cualificadas (que requieren el uso de un proveedor de servicios de confianza cualificado y un dispositivo de creación de firmas) tienen el mismo poder que una firma física.

Autoridades de certificación

El procedimiento para obtener un certificado de clave pública

En el modelo de confianza X.509 , una autoridad de certificación (CA) es responsable de firmar los certificados. Estos certificados actúan como una presentación entre dos partes, lo que significa que una CA actúa como un tercero de confianza. Una CA procesa las solicitudes de personas u organizaciones que solicitan certificados (llamados suscriptores), verifica la información y potencialmente firma un certificado de entidad final en función de esa información. Para desempeñar esta función de manera eficaz, una CA debe tener uno o más certificados raíz o certificados intermedios de amplia confianza y las claves privadas correspondientes. Las CA pueden lograr esta amplia confianza al incluir sus certificados raíz en software popular o al obtener una firma cruzada de otra CA que delegue la confianza. Otras CA son de confianza dentro de una comunidad relativamente pequeña, como una empresa, y se distribuyen mediante otros mecanismos como la Política de grupo de Windows .

Las autoridades de certificación también son responsables de mantener actualizada la información de revocación de los certificados que han emitido, indicando si los certificados siguen siendo válidos. Proporcionan esta información a través del Protocolo de estado de certificados en línea (OCSP) y/o las Listas de revocación de certificados (CRL). Algunas de las autoridades de certificación más importantes del mercado son IdenTrust , DigiCert y Sectigo . [28]

Programas raíz

Algunos programas importantes contienen una lista de autoridades de certificación que son de confianza de forma predeterminada. [ cita requerida ] Esto facilita que los usuarios finales validen los certificados y que las personas u organizaciones que solicitan certificados sepan qué autoridades de certificación pueden emitir un certificado que será de confianza generalizada. Esto es particularmente importante en HTTPS, donde el operador de un sitio web generalmente desea obtener un certificado en el que confíen casi todos los visitantes potenciales de su sitio web.

Las políticas y los procesos que utiliza un proveedor para decidir en qué autoridades de certificación debe confiar su software se denominan programas raíz. Los programas raíz más influyentes son: [ cita requerida ]

Los navegadores distintos de Firefox generalmente utilizan las funciones del sistema operativo para decidir qué autoridades de certificación son confiables. Por ejemplo, Chrome en Windows confía en las autoridades de certificación incluidas en el Programa raíz de Microsoft, mientras que en macOS o iOS, Chrome confía en las autoridades de certificación del Programa raíz de Apple. [29] Edge y Safari también utilizan sus respectivos almacenes de confianza del sistema operativo, pero cada uno solo está disponible en un único sistema operativo. Firefox utiliza el almacén de confianza del Programa raíz de Mozilla en todas las plataformas.

El Programa Raíz de Mozilla es operado públicamente, y su lista de certificados es parte del navegador web de código abierto Firefox, por lo que se usa ampliamente fuera de Firefox. [ cita requerida ] Por ejemplo, si bien no existe un Programa Raíz de Linux común, muchas distribuciones de Linux, como Debian, [30] incluyen un paquete que copia periódicamente el contenido de la lista de confianza de Firefox, que luego es utilizada por las aplicaciones.

Los programas raíz generalmente proporcionan un conjunto de propósitos válidos con los certificados que incluyen. Por ejemplo, algunas CA pueden considerarse confiables para emitir certificados de servidor TLS, pero no para certificados de firma de código. Esto se indica con un conjunto de bits de confianza en un sistema de almacenamiento de certificados raíz.

Revocación

Un certificado puede ser revocado antes de su vencimiento, lo que indica que ya no es válido. Sin la revocación, un atacante podría explotar un certificado comprometido o emitido incorrectamente hasta su vencimiento. [31] Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública . [32] La revocación la realiza la autoridad de certificación emisora , que produce una declaración de revocación autenticada criptográficamente . [33]

Para distribuir información de revocación a los clientes, la puntualidad del descubrimiento de la revocación (y, por lo tanto, la ventana para que un atacante explote un certificado comprometido) se compensa con el uso de recursos en la consulta de estados de revocación y las preocupaciones de privacidad. [34] Si la información de revocación no está disponible (ya sea debido a un accidente o un ataque), los clientes deben decidir si fallan de manera total y tratan un certificado como si estuviera revocado (y así degradan la disponibilidad ) o fallan de manera suave y lo tratan como si no estuviera revocado (y permiten a los atacantes eludir la revocación). [35]

Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de servicios remotos potencialmente poco fiables, los navegadores web limitan las comprobaciones de revocación que realizan y, cuando lo hacen, fallan de manera suave. [36] Las listas de revocación de certificados consumen demasiado ancho de banda para su uso rutinario, y el Protocolo de estado de certificados en línea presenta problemas de latencia de conexión y privacidad. Se han propuesto otros esquemas, pero aún no se han implementado con éxito, para permitir la comprobación de fallas de manera estricta. [32]

Seguridad del sitio web

El uso más común de los certificados es para sitios web basados ​​en HTTPS . Un navegador web valida que un servidor web HTTPS es auténtico, de modo que el usuario puede sentirse seguro de que su interacción con el sitio web no tiene espías y que el sitio web es quien dice ser. Esta seguridad es importante para el comercio electrónico . En la práctica, un operador de un sitio web obtiene un certificado solicitándole a una autoridad de certificación una solicitud de firma de certificado . La solicitud de certificado es un documento electrónico que contiene el nombre del sitio web, la información de la empresa y la clave pública. El proveedor del certificado firma la solicitud, produciendo así un certificado público. Durante la navegación web, este certificado público se envía a cualquier navegador web que se conecta al sitio web y demuestra al navegador web que el proveedor cree que ha emitido un certificado al propietario del sitio web.

Por ejemplo, cuando un usuario se conecta a https://www.example.com/un sitio web con su navegador, si este no muestra ningún mensaje de advertencia sobre el certificado, entonces el usuario puede estar teóricamente seguro de que interactuar con https://www.example.com/el sitio web es equivalente a interactuar con la entidad en contacto con la dirección de correo electrónico que figura en el registro público bajo "example.com", aunque esa dirección de correo electrónico no se muestre en ninguna parte del sitio web. [ cita requerida ] No se implica ninguna otra garantía de ningún tipo. Además, la relación entre el comprador del certificado, el operador del sitio web y el generador del contenido del sitio web puede ser tenue y no está garantizada. [ cita requerida ] En el mejor de los casos, el certificado garantiza la singularidad del sitio web, siempre que el sitio web en sí no haya sido comprometido (pirateado) o que el proceso de emisión del certificado no haya sido subvertido.

Un proveedor de certificados puede optar por emitir tres tipos de certificados, cada uno de los cuales requiere su propio grado de rigor en la verificación. En orden de rigor creciente (y, naturalmente, de costo), son: Validación de dominio, Validación de organización y Validación extendida. Estos rigores son acordados de manera general por los participantes voluntarios en el CA/Browser Forum . [ cita requerida ]

Niveles de validación

Validación de dominio

Un proveedor de certificados emitirá un certificado validado por dominio (DV) a un comprador si el comprador puede demostrar un criterio de evaluación: el derecho a gestionar administrativamente el o los dominios DNS afectados.

Validación de la organización

Un proveedor de certificados emitirá un certificado de clase de validación de organización (OV) a un comprador si este puede cumplir dos criterios: el derecho a gestionar administrativamente el nombre de dominio en cuestión y, tal vez, la existencia real de la organización como entidad legal. Un proveedor de certificados publica sus criterios de verificación de OV a través de su política de certificados .

Validación extendida

Para adquirir un certificado de Validación Extendida (EV), el comprador debe convencer al proveedor del certificado de su identidad legal, lo que incluye verificaciones manuales realizadas por un humano. Al igual que con los certificados OV, un proveedor de certificados publica sus criterios de verificación EV a través de su política de certificados .

Hasta 2019, los principales navegadores, como Chrome y Firefox, generalmente ofrecían a los usuarios una indicación visual de la identidad legal cuando un sitio presentaba un certificado EV. Esto se hacía mostrando el nombre legal antes del dominio y un color verde brillante para resaltar el cambio. La mayoría de los navegadores descontinuaron esta función [37] [38], lo que no proporcionaba ninguna diferencia visual al usuario sobre el tipo de certificado utilizado. Este cambio se produjo a raíz de las preocupaciones de seguridad planteadas por expertos forenses y los intentos exitosos de comprar certificados EV para hacerse pasar por organizaciones famosas, lo que demostró la ineficacia de estos indicadores visuales y destacó posibles abusos. [39]

Debilidades

Un navegador web no avisará al usuario si un sitio web presenta de repente un certificado diferente, incluso si ese certificado tiene un número menor de bits de clave, incluso si tiene un proveedor diferente, e incluso si el certificado anterior tenía una fecha de vencimiento muy lejana en el futuro. [ cita requerida ] Cuando los proveedores de certificados están bajo la jurisdicción de los gobiernos, estos pueden tener la libertad de ordenar al proveedor que genere cualquier certificado, por ejemplo, para fines de aplicación de la ley. Los proveedores de certificados mayoristas subsidiarios también tienen la libertad de generar cualquier certificado.

Todos los navegadores web vienen con una extensa lista incorporada de certificados raíz de confianza , muchos de los cuales están controlados por organizaciones que pueden resultar desconocidas para el usuario. [1] Cada una de estas organizaciones es libre de emitir cualquier certificado para cualquier sitio web y tiene la garantía de que los navegadores web que incluyen sus certificados raíz lo aceptarán como genuino. En este caso, los usuarios finales deben confiar en el desarrollador del software del navegador para administrar su lista incorporada de certificados y en los proveedores de certificados para comportarse correctamente e informar al desarrollador del navegador sobre los certificados problemáticos. Si bien es poco común, ha habido incidentes en los que se han emitido certificados fraudulentos: en algunos casos, los navegadores han detectado el fraude; en otros, pasó algún tiempo antes de que los desarrolladores de navegadores eliminaran estos certificados de su software. [40] [41]

La lista de certificados integrados tampoco se limita a los proporcionados por el desarrollador del navegador: los usuarios (y hasta cierto punto las aplicaciones) son libres de ampliar la lista para fines especiales, como por ejemplo para intranets de empresas. [42] Esto significa que si alguien obtiene acceso a una máquina y puede instalar un nuevo certificado raíz en el navegador, ese navegador reconocerá los sitios web que utilicen el certificado insertado como legítimos.

Para lograr una seguridad demostrable , esta dependencia de algo externo al sistema tiene como consecuencia que cualquier esquema de certificación de clave pública debe basarse en algún supuesto de configuración especial, como la existencia de una autoridad certificadora . [43]

Utilidad frente a sitios web no seguros

A pesar de las limitaciones descritas anteriormente, todas las directrices de seguridad consideran que la autenticación TLS mediante certificado es obligatoria siempre que un sitio web aloje información confidencial o realice transacciones importantes. Esto se debe a que, en la práctica, a pesar de las debilidades descritas anteriormente, los sitios web protegidos por certificados de clave pública siguen siendo más seguros que los sitios web http:// no protegidos . [44]

Normas

La División de Seguridad Informática del Instituto Nacional de Estándares y Tecnología ( NIST ) [45] proporciona documentos de orientación para los certificados de clave pública:

Véase también

Referencias

  1. ^ Limitación del certificado SSL con comodín abc en QuovadisGlobal.com Error en la cita: La referencia nombrada ":0" se definió varias veces con contenido diferente (ver la página de ayuda ).
  2. ^ Alrawais, Arwa; Alhothaily, Abdulrahman; Cheng, Xiuzhen ; Hu, Chunqiang; Yu, Jiguo (1 de junio de 2018). "SecureGuard: un sistema de validación de certificados en infraestructura de clave pública". IEEE Transactions on Vehicular Technology . 67 (6): 5399–5408. doi :10.1109/TVT.2018.2805700. ISSN  0018-9545. S2CID  49270949. Archivado desde el original el 26 de agosto de 2022 . Consultado el 26 de agosto de 2022 .
  3. ^ Chadwick, David W; Basden, Andrew (31 de octubre de 2001). "Evaluación de la confianza en una autoridad de certificación de clave pública". Computers & Security . 20 (7): 592–611. doi :10.1016/S0167-4048(01)00710-6. ISSN  0167-4048. Archivado desde el original el 26 de febrero de 2022 . Consultado el 26 de febrero de 2022 .
  4. ^ "Nombres internos". Documentación de DigiCert .
  5. ^ "Certificado SSL gratuito | IONOS by 1&1". www.ionos.es . Archivado desde el original el 2022-07-18 . Consultado el 2022-07-15 .
  6. ^ "x509v3_config - Formato de configuración de la extensión del certificado X509 V3". OpenSSL . Consultado el 16 de enero de 2020 .
  7. ^ RFC  5280: 4.2.1.6. Nombre alternativo del sujeto
  8. ^ ab Medley, Joseph (marzo de 2017). "Desactivaciones y eliminaciones en Chrome 58". Google Inc. Recuperado el 4 de enero de 2022 .
  9. ^ "Nombre común (CN) para un certificado comodín". Documentación de DigiCert.
  10. ^ "Wildcard y SAN: comprensión de los certificados SSL multiuso" (PDF) . Thawte . 2013.
  11. ^ "Explicación del certificado comodín en términos más sencillos". 23 de mayo de 2016.
  12. ^ "RFC 2818 - HTTP sobre TLS". Grupo de trabajo de ingeniería de Internet . Mayo de 2000. pág. 5. Consultado el 15 de diciembre de 2014. [...] *.a.com coincide con foo.a.com pero no con bar.foo.a.com.
  13. ^ Newman, C. (junio de 1999). RFC 2595 - Uso de TLS con IMAP, POP3 y ACAP. Grupo de trabajo de ingeniería de Internet . pág. 3. doi : 10.17487/RFC2595 . RFC 2595. Consultado el 15 de diciembre de 2014. Por ejemplo, *.example.com coincidiría con a.example.com, foo.example.com, etc., pero no con example.com .
  14. ^ "Directrices para la emisión y gestión de certificados de validación extendida, versión 1.5.2" (PDF) . CA/Browser Forum. 16 de octubre de 2014. pág. 10. Consultado el 15 de diciembre de 2014. No se permiten certificados comodín para certificados EV .
  15. ^ x509v3_config Nombre alternativo del sujeto
  16. ^ La opción SAN está disponible para certificados SSL EV en Symantec.com
  17. ^ Búsqueda de certificados SSLTools del certificado SSL comodín de Wikipedia.org
  18. ^ Saint-Andre, P.; Hodges, J. (marzo de 2011). RFC 6125 - Representación y verificación de la identidad de servicios de aplicaciones basados ​​en dominios 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). Internet Engineering Task Force . p. 31. doi : 10.17487/RFC6125 . RFC 6125 . Consultado el 10 de diciembre de 2014 . Este documento establece que el carácter comodín '*' NO DEBE incluirse en los identificadores presentados, pero los clientes de la aplicación PUEDEN comprobarlo (principalmente por el bien de la compatibilidad con versiones anteriores de la infraestructura implementada). [...] Varias consideraciones de seguridad justifican el endurecimiento de las reglas: [...]
  19. ^ Rescorla, E. (mayo de 2000). "RFC 2818 - HTTP sobre TLS". tools.ietf.org . doi : 10.17487/RFC2818 . RFC 2818 . Consultado el 20 de abril de 2019 .
  20. ^ Saint-Andre, P.; Hodges, J. (marzo de 2011). "RFC 6125 - Representación y verificación de la identidad de servicios de aplicaciones basados ​​en dominios 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 . doi : 10.17487/RFC6125 . RFC 6125 . Consultado el 20 de abril de 2019 .
  21. ^ "No permitir la compatibilidad con a*.example.net, *a.example.net y a*b.example.net en el manejo de comodines de certificados". The Chromium Projects, Google Inc. 3 de diciembre de 2014. Consultado el 21 de octubre de 2020 .
  22. ^ "Limita la compatibilidad de los ID de DNS comodín a nombres con el formato *.example.com (no foo*.example.com)". The Mozilla Foundation. 10 de diciembre de 2014. Consultado el 21 de octubre de 2020 .
  23. ^ "No permitir la compatibilidad con a*.example.net, *a.example.net y a*b.example.net en el manejo de comodines de certificados". The Python Software Foundation. 26 de noviembre de 2017. Consultado el 21 de octubre de 2020 .
  24. ^ "Restricciones en la entrada de datos para certificados públicos". Documentación de DigiCert .
  25. ^ "EMV CA". Autoridad de certificación EMV a nivel mundial. 2 de diciembre de 2010. Archivado desde el original el 4 de julio de 2020. Consultado el 20 de enero de 2020 .
  26. ^ "Política de certificación X.509 para la Autoridad de certificación de puentes federales (FBCA)" (PDF) . Archivado (PDF) del original el 2021-03-18 . Consultado el 2021-05-07 .
  27. ^ "Política de certificación X.509 para la Autoridad de certificación de puentes federales (FBCA)" (PDF) . Archivado (PDF) del original el 2021-03-18 . Consultado el 2021-05-07 .
  28. ^ "Estadísticas de uso y cuota de mercado de las autoridades de certificación SSL para sitios web, mayo de 2020". w3techs.com . Archivado desde el original el 2022-06-30 . Consultado el 2020-05-01 .
  29. ^ "Política de certificados raíz: los proyectos Chromium". www.chromium.org . Archivado desde el original el 20 de marzo de 2017 . Consultado el 19 de marzo de 2017 .
  30. ^ "ca-certificates in Launchpad". launchpad.net . 30 de abril de 2010. Archivado desde el original el 20 de marzo de 2017 . Consultado el 19 de marzo de 2017 .
  31. ^ Smith, Dickinson y Seamons 2020, pág. 1.
  32. ^ ab Sheffer, Saint-Andre & Fossati 2022, 7.5. Revocación del Certificado.
  33. ^ Chung y otros. 2018, pág. 3.
  34. ^ Smith, Dickinson y Seamons 2020, pág. 10.
  35. ^ Larisch y otros. 2017, pág. 542.
  36. ^ Smith, Dickinson y Seamons 2020, pág. 1-2.
  37. ^ "Grupo de Google Firefox-dev - Intención de envío: mover la información de validación extendida fuera de la barra de URL". groups.google.com . Archivado desde el original el 2020-08-12 . Consultado el 2020-08-03 .
  38. ^ "Grupo de Google de desarrolladores de seguridad de Chrome: Próximo cambio en los indicadores de identidad de Chrome". groups.google.com . Archivado desde el original el 2020-06-07 . Consultado el 2020-08-03 .
  39. ^ "Los certificados de validación extendida están (realmente, realmente) muertos". troyhunt.com . 12 de agosto de 2019. Archivado desde el original el 2020-07-16 . Consultado el 2020-08-03 .
  40. ^ "Eliminación de DigiNotar por parte de Mozilla". Mozilla.org. 2 de septiembre de 2011. Archivado desde el original el 3 de junio de 2012. Consultado el 30 de julio de 2012 .
  41. ^ "Eliminación de DigitNotar por parte de Google". Archivado desde el original el 13 de septiembre de 2011. Consultado el 30 de julio de 2012 .
  42. ^ "Artículo sobre el uso de certificados en Mozilla.org". Mozilla.org. Archivado desde el original el 12 de julio de 2012. Consultado el 30 de julio de 2012 .
  43. ^ Ran Canetti: Firma, certificación y autenticación universalmente componibles. CSFW 2004, http://eprint.iacr.org/2003/239 Archivado el 28 de agosto de 2009 en Wayback Machine.
  44. ^ Ben Laurie , Ian Goldberg (18 de enero de 2014). «Reemplazo de contraseñas en Internet, también conocido como cifrado oportunista post-Snowden» (PDF) . Archivado (PDF) del original el 27 de octubre de 2014. Consultado el 15 de noviembre de 2014 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
  45. ^ "Publicaciones de seguridad informática del NIST: publicaciones especiales (SP) del NIST". csrc.nist.gov . Archivado desde el original el 17 de septiembre de 2017. Consultado el 19 de junio de 2016 .
  46. ^ "SP 800-32 Introducción a la tecnología de clave pública y la infraestructura de PKI federal" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado (PDF) desde el original el 2018-06-05 . Consultado el 2016-06-19 .
  47. ^ "SP 800-25 Uso de tecnología de clave pública para firmas digitales y autenticación por parte de agencias federales" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado (PDF) desde el original el 2018-06-02 . Consultado el 2016-06-19 .

Obras citadas