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.
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:
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.
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.
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.
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.
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]
*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:
payment.example.comcontact.example.comlogin-secure.example.comwww.example.comEn 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]
test.login.example.comexample.comTenga 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 ]
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]
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.combaz*.example.netEstá bien y coincidebaz1.example.net*baz.example.netEstá bien y coincidefoobaz.example.netb*z.example.netEstá bien y coincidebuzz.example.netSin 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.comNo se permite un certificado con *un dominio de nivel superior.
*.comDemasiado 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é.comxn--caf-dma*.comNo está permitidoLw*.xn--caf-dma.comestá permitidoEstos 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.
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.
Certificado: Datos: Versión: 3 (0x2) Número de serie: 72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31 Algoritmo de firma: sha256WithRSAEncryption Emisor: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3 Validez No antes: 18 de abril de 2019, 22:15:06 GMT No después de: 17 de abril de 2021, 22:15:06 GMT Asunto: C=EE. UU., ST=Texas, L=Houston, O=SSL Corp/número de serie=NV20081614243, CN=www.ssl.com/código postal=77098/categoría empresarial=organización privada/calle=3100 Richmond Ave/jurisdicciónST=Nevada/jurisdicciónC=EE. UU. Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública RSA: (2048 bit) Módulo: 00:ad:0f:ef:c1:97:5a:9b:d8:1e ... Exponente: 65537 (0x10001) Extensiones X509v3: Identificador de clave de autoridad X509v3: ID de clave:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD Acceso a la información de la autoridad: Emisores de CA - URI: http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt OCSP - URI: http://ocsps.ssl.com X509v3 Nombre alternativo del sujeto: DNS: www.ssl.com, DNS: answers.ssl.com, DNS: faq.ssl.com, DNS: info.ssl.com, DNS: links.ssl.com, DNS: reseller.ssl.com, DNS: secure.ssl.com, DNS: ssl.com, DNS: support.ssl.com, DNS: sws.ssl.com, DNS: tools.ssl.com Políticas de certificación X509v3: Política: 2.23.140.1.1 Política: 1.2.616.1.113527.2.5.1.1 Política: 1.3.6.1.4.1.38064.1.1.1.5 Página de inicio: https://www.ssl.com/repository Uso extendido de la clave X509v3: Autenticación de cliente web TLS, autenticación de servidor web TLS Puntos de distribución de CRL X509v3: Nombre completo: Dirección URL: http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl Identificador de clave de sujeto X509v3: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B Uso de la clave X509v3: crítico Firma digital, cifrado de clave Precertificados de CT SCT: Sello de tiempo del certificado firmado: Versión: v1 (0x0) ID de registro: 87:75:BF:E7:59:7C:F8:8C:43:99 ... Marca de tiempo: 18 de abril de 2019, 22:25:08.574 GMT Extensiones: ninguna Firma: ecdsa-with-SHA256 30:44:02:20:40:51:53:90:C6:A2... Sello de tiempo del certificado firmado: Versión: v1 (0x0) ID de registro: A4:B9:09:90:B4:18:58:14:87:BB... Marca de tiempo: 18 de abril de 2019, 22:25:08.461 GMT Extensiones: ninguna Firma: ecdsa-with-SHA256 30:45:02:20:43:80:9E:19:90:FD... Sello de tiempo del certificado firmado: Versión: v1 (0x0) ID de registro: 55:81:D4:C2:16:90:36:01:4A:EA ... Marca de tiempo: 18 de abril de 2019, 22:25:08.769 GMT Extensiones: ninguna Firma: ecdsa-with-SHA256 30:45:02:21:00:C1:3E:9F:F0:40... Algoritmo de firma: sha256WithRSAEncryption 36:07:e7:3b:b7:45:97:ca:4d:6c ...
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.
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]
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 sea de confianza para todos. 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.
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]
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 ]
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.
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 .
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]
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]
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]
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:
[...] *.a.com coincide con foo.a.com pero no con bar.foo.a.com.
Por ejemplo, *.example.com coincidiría con a.example.com, foo.example.com, etc., pero no con example.com.
No se permiten certificados comodín para certificados EV.
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: [...]
{{cite journal}}: Requiere citar revista |journal=( ayuda )