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 por 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:

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.

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 permiten tanto establecer la integridad de los mensajes como 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]

• Direcciones de correo electrónico
• Direcciones IP
• URI
• Nombres DNS : normalmente también se proporcionan como nombre común (RDN) dentro del campo Asunto del certificado principal.
• Nombres de directorio: nombres distintivos alternativos a los que figuran en el asunto.
• Otros nombres, dados como Nombre General o Nombre Principal Universal : un identificador de objeto registrado seguido de un valor.

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.com
• contact.example.com
• login-secure.example.com
• www.example.com

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]

• test.login.example.com
• example.com

Tenga en cuenta las posibles excepciones por parte 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 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.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

• Certificado EMV: EMV es un método de pago basado en un estándar técnico para tarjetas de pago , terminales de pago y cajeros automáticos (ATM). Las tarjetas de pago EMV están precargadas con un certificado del emisor de la tarjeta, firmado por la autoridad de certificación EMV ^[25] para validar la autenticidad de la tarjeta de pago durante la transacción de pago.
• Certificado de firma de código : los certificados pueden validar aplicaciones (o sus binarios ) para garantizar que no hayan sido alterados durante la entrega.
• Certificado cualificado : certificado que identifica a una persona, normalmente para fines de firma electrónica . Son los más utilizados en Europa, donde el reglamento eIDAS los estandariza y exige su reconocimiento.
• Certificado basado en roles: definidos en la Política de certificación X.509 para la Autoridad de certificación de Federal Bridge (FBCA) , los certificados basados ​​en roles "identifican un rol específico en nombre del cual el suscriptor está autorizado a actuar en lugar del nombre del suscriptor y se emiten con el fin de respaldar las prácticas comerciales aceptadas". ^[26]
• Certificado de grupo: definido en la Política de certificación X.509 de la Autoridad de certificación de Federal Bridge (FBCA) , para "casos en los que hay varias entidades que actúan en una sola capacidad y donde no se desea el no repudio de las transacciones". ^[27]

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.

• Número de serie : se utiliza para identificar de forma única el certificado dentro de los sistemas de una CA. En particular, se utiliza para realizar un seguimiento de la información de revocación.
• Asunto : La entidad a la que pertenece un certificado: una máquina, un individuo o una organización.
• Emisor : Entidad que verificó la información y firmó el certificado.
• No antes de : la fecha y hora más tempranas en las que el certificado es válido. Generalmente se establece unas horas o días antes del momento en que se emitió el certificado, para evitar problemas de desfase horario .
• No después de : la hora y fecha después de las cuales el certificado ya no es válido.
• Uso de la clave : los usos criptográficos válidos de la clave pública del certificado. Los valores comunes incluyen la validación de firma digital, el cifrado de claves y la firma de certificados.
• Uso extendido de la clave : las aplicaciones en las que se puede utilizar el certificado. Los valores comunes incluyen la autenticación del servidor TLS, la protección del correo electrónico y la firma de código.
• Clave pública : una clave pública que pertenece al sujeto del certificado.
• Algoritmo de firma : contiene un algoritmo de hash y un algoritmo de firma digital. Por ejemplo, "sha256RSA", donde sha256 es el algoritmo de hash y RSA es el algoritmo de firma.
• Firma : El cuerpo del certificado se codifica (se utiliza el algoritmo de codificación en el campo "Algoritmo de firma") y luego se firma el código (se utiliza el algoritmo de firma en el campo "Algoritmo de firma") con la clave privada del emisor.

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 u 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 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 ]}

• Programa raíz de Microsoft
• Programa de rooteo de Apple
• Programa raíz de Mozilla
• Programa raíz de Oracle Java
• Lista de confianza aprobada por Adobe AATL y programas raíz EUTL (utilizados para la firma de documentos)

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 severa 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 surgió 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 que los proveedores de certificados se comporten correctamente e informen 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 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 usan 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 por certificado TLS 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:

• SP 800-32 Introducción a la tecnología de clave pública y a la infraestructura PKI federal ^[46]
• SP 800-25 Uso de tecnología de clave pública por parte de agencias federales para firmas digitales y autenticación ^[47]

• Certificado de autorización
• Muy buena privacidad

• Chung, Taejoong; Lok, Jay; Chandrasekaran, Balakrishnan; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Rula, John; Sullivan, Nick; Wilson, Christo (2018). "¿Está la Web preparada para el imprescindible OCSP?" (PDF) . Actas de la Conferencia de medición de Internet de 2018. págs. 105–118. doi :10.1145/3278532.3278543. ISBN . 9781450356190. Número de identificación del sujeto  53223350.
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). "CRLite: un sistema escalable para enviar todas las revocaciones de TLS a todos los navegadores". Simposio IEEE sobre seguridad y privacidad de 2017 (SP) . págs. 539–556. doi : 10.1109/sp.2017.17 . ISBN . 978-1-5090-5533-3. Número de identificación del sujeto  3926509.
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre de 2022). Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS). doi : 10.17487/RFC9325 . RFC 9325.
• Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Let's Revoke: revocación de certificados global escalable". Actas del Simposio sobre seguridad de redes y sistemas distribuidos de 2020. doi : 10.14722 /ndss.2020.24084 . ISBN . 978-1-891562-61-7. Número de identificación del sujeto  211268930.