Certificado de clave pública - Public key certificate
En criptografía , un certificado de clave pública , también conocido como certificado digital o certificado de identidad , es un documento electrónico que se utiliza para demostrar la propiedad de una clave pública . El certificado incluye información sobre la clave, información sobre la identidad de su propietario (llamado sujeto) y la firma digital de una entidad que ha verificado el contenido del certificado (llamado emisor). Si la firma es válida y el software que examina el certificado confía en el emisor, entonces puede usar esa clave para comunicarse de forma segura con el sujeto del certificado. En los sistemas de cifrado de correo electrónico , firma de código y firma electrónica, el asunto 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 personas 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), se destaca 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), generalmente una empresa que cobra a los clientes 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.
El formato más común para los certificados de clave pública está definido por X.509 . Debido a que X.509 es muy general, el formato está aún más restringido por los perfiles definidos para ciertos casos de uso, como la Infraestructura de clave pública (X.509) como se define en RFC 5280 .
Tipos de certificado
Certificado de servidor TLS / SSL
En TLS (un reemplazo actualizado de SSL), se requiere que un servidor presente un certificado como parte de la configuración de conexión inicial. Un cliente que se conecte a ese servidor realizará el algoritmo de validación de la ruta de certificación :
- El asunto del certificado coincide con el nombre de host (es decir, el nombre de dominio) al que el cliente está intentando conectarse;
- El certificado está firmado por una autoridad certificadora de confianza.
El nombre de host principal ( nombre de dominio del sitio web) aparece como Nombre común en el campo Asunto del certificado. Un certificado puede ser válido para varios nombres de host (varios sitios web). 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 incluirán 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 .
Un servidor TLS se puede configurar con un certificado autofirmado. Cuando ese es el caso, los clientes generalmente no podrán verificar el certificado y terminarán la conexión a menos que la verificación de certificados esté deshabilitada.
Según las aplicaciones, los certificados SSL se pueden clasificar en tres tipos:
- SSL de validación de dominio;
- SSL de validación de la organización;
- SSL de validación extendida.
Certificado de cliente TLS / SSL
Los certificados de cliente son menos comunes que los certificados de servidor y se utilizan para autenticar 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 brindan 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, debido a que la autenticación suele ser administrada por el proveedor de servicios, los certificados de cliente no suelen ser emitidos por una CA pública que proporciona certificados de servidor. En cambio, el operador de un servicio que requiere certificados de cliente generalmente operará su propia CA interna para emitirlos. Los certificados de cliente son compatibles con muchos navegadores web, pero la mayoría de los servicios utilizan contraseñas y cookies para autenticar a los usuarios, en lugar de certificados de cliente.
Los certificados de cliente son más comunes en los sistemas RPC , donde se utilizan para autenticar dispositivos para garantizar que solo los dispositivos autorizados puedan realizar determinadas llamadas RPC.
Certificado de correo electrónico
En el protocolo S / MIME para correo electrónico seguro, los remitentes deben descubrir qué clave pública usar para un destinatario determinado. Obtienen esta información de un certificado de correo electrónico. Algunas autoridades de certificación de confianza pública proporcionan certificados de correo electrónico, pero más comúnmente se usa S / MIME cuando se comunica dentro de una organización determinada, y esa organización ejecuta su propia CA, en la que los participantes de ese sistema de correo electrónico confían.
Certificado EMV
Las tarjetas de pago EMV están precargadas con un certificado del emisor de la tarjeta, firmado por la autoridad certificadora de EMV para validar la autenticidad de la tarjeta de pago durante la transacción de pago. El certificado EMV CA se carga en terminales de tarjetas ATM o POS y se utiliza para validar el certificado del emisor de la tarjeta.
Certificado de firma de código
Los certificados también se pueden utilizar para validar firmas en programas para garantizar que no se manipulen durante la entrega.
Certificado calificado
Un certificado que identifica a una persona, generalmente con fines de firma electrónica . Estos son los más utilizados en Europa, donde el reglamento eIDAS los estandariza y requiere su reconocimiento.
Certificado raíz
Un certificado autofirmado que se utiliza para firmar otros certificados. A veces también se denomina ancla de confianza o raíz de confianza .
Certificado intermedio
Un certificado que se utiliza para firmar otros certificados. Un certificado intermedio debe estar firmado por otro certificado intermedio o un certificado raíz.
Certificado de entidad final o hoja
Cualquier certificado que no se pueda utilizar para firmar otros certificados. Por ejemplo, los certificados de cliente y servidor 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 basado en roles
Definidos en la Política de certificados X.509 para la Autoridad de certificación puente federal, 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 en el interés de respaldar las prácticas comerciales aceptadas . "
Certificado de grupo
Definido en la Política de Certificación X.509 para la Autoridad de Certificación de Puente Federal, para "casos en los que hay varias entidades actuando en una capacidad y donde no se desea el no repudio de las transacciones".
Certificado autofirmado
Un certificado con un asunto que coincide con su emisor y una firma que puede ser verificada por su propia clave pública. La mayoría de los tipos de certificados se pueden autofirmar. Los certificados autofirmados también se denominan a menudo certificados de aceite de serpiente para enfatizar su falta de confiabilidad.
Campos comunes
Estos son algunos de los campos más comunes en los certificados. La mayoría de los certificados contienen varios 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" pero 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, esto se utiliza para rastrear la información de revocación.
- Asunto : 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 : la fecha y hora más tempranas en las que el certificado es válido. Por lo general, se establece unas horas o días antes del momento en que se emitió el certificado, para evitar problemas de desviación del reloj .
- Not After : La hora y fecha después de las cuales el certificado ya no es válido.
- Uso de clave : los usos criptográficos válidos de la clave pública del certificado. Los valores comunes incluyen la validación de firmas digitales, el cifrado de claves y la firma de certificados.
- Uso extendido de claves : las aplicaciones en las que se puede utilizar el certificado. Los valores comunes incluyen autenticación de servidor TLS, protección de correo electrónico y firma de código.
- Clave pública : una clave pública que pertenece al sujeto del certificado.
- Algoritmo de firma : contiene un algoritmo hash y un algoritmo de cifrado. Por ejemplo, "sha256RSA", donde sha256 es el algoritmo hash y RSA es el algoritmo de cifrado.
- Firma : El cuerpo del certificado es hash (se usa el algoritmo hash en el campo "Algoritmo de firma") y luego el hash se cifra (se usa el algoritmo de cifrado en el campo "Algoritmo de firma") con la clave privada del emisor.
Certificado de muestra
Este es un ejemplo de un certificado SSL / TLS decodificado obtenido del sitio web SSL.com. El nombre común del emisor (CN) se muestra como SSL.com EV SSL Intermediate CA RSA R3, identificándolo 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.
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3
Validity
Not Before: Apr 18 22:15:06 2019 GMT
Not After : Apr 17 22:15:06 2021 GMT
Subject: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ad:0f:ef:c1:97:5a:9b:d8:1e ...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD
Authority Information Access:
CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt
OCSP - URI:http://ocsps.ssl.com
X509v3 Subject Alternative Name:
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
X509v3 Certificate Policies:
Policy: 2.23.140.1.1
Policy: 1.2.616.1.113527.2.5.1.1
Policy: 1.3.6.1.4.1.38064.1.1.1.5
CPS: https://www.ssl.com/repository
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl
X509v3 Subject Key Identifier:
E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 87:75:BF:E7:59:7C:F8:8C:43:99 ...
Timestamp : Apr 18 22:25:08.574 2019 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:40:51:53:90:C6:A2 ...
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : A4:B9:09:90:B4:18:58:14:87:BB ...
Timestamp : Apr 18 22:25:08.461 2019 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:43:80:9E:19:90:FD ...
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 55:81:D4:C2:16:90:36:01:4A:EA ...
Timestamp : Apr 18 22:25:08.769 2019 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:C1:3E:9F:F0:40 ...
Signature Algorithm: sha256WithRSAEncryption
36:07:e7:3b:b7:45:97:ca:4d:6c ...
Uso en la Unión Europea
En la Unión Europea, las firmas electrónicas (avanzadas) en documentos legales se realizan comúnmente utilizando firmas digitales con certificados de identidad adjuntos. Sin embargo, solo las firmas electrónicas calificadas (que requieren el uso de un proveedor de servicios de confianza calificado y un dispositivo de creación de firmas) reciben el mismo poder que una firma física.
Autoridades de certificación
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 introducció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 basado en 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 confianza general 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 confiables 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 sobre los certificados que han emitido, lo que indica 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 Listas de revocación de certificados (CRL). Algunas de las autoridades de certificación más importantes del mercado incluyen IdenTrust , DigiCert y Sectigo .
Programas raíz
Algunos programas importantes contienen una lista de autoridades de certificación en las que se confía de forma predeterminada. Esto hace que sea más fácil para los usuarios finales validar certificados y más fácil para las personas u organizaciones que solicitan certificados saber qué autoridades de certificación pueden emitir un certificado que será ampliamente confiable. Esto es particularmente importante en HTTPS, donde el operador de un sitio web generalmente desea obtener un certificado en el que casi todos los visitantes potenciales de su sitio web confíen.
Las políticas y 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:
- Programa raíz de Microsoft
- Programa de raíz de Apple
- Programa raíz de Mozilla
- Programa raíz de Oracle Java
- Adobe AATL Adobe Approved Trust List 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. Entonces, 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 en el Programa raíz de Apple. Edge y Safari también usan 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 se opera 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. Por ejemplo, si bien no existe un programa raíz común de Linux, muchas distribuciones de Linux, como Debian, incluyen un paquete que copia periódicamente el contenido de la lista de confianza de Firefox, que luego utilizan 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.
Certificados y seguridad del sitio web
El uso más común de 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 intrusos y que el sitio web es quien dice ser. Esta seguridad es importante para el comercio electrónico . En la práctica, el operador de un sitio web obtiene un certificado solicitándolo a una autoridad certificadora con 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 conecte al sitio web y demuestre al navegador web que el proveedor cree que ha emitido un certificado al propietario del sitio web.
A modo de ejemplo, cuando un usuario se conecta a https://www.example.com/su navegador, si el navegador no muestra ningún mensaje de advertencia de certificado, entonces el usuario puede estar teóricamente seguro de que interactuar con https://www.example.com/es equivalente a interactuar con la entidad en contacto con la dirección de correo electrónico que aparece en la registrador público en "example.com", aunque es posible que esa dirección de correo electrónico no se muestre en ninguna parte del sitio web. 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 frágil y no está garantizada. En el mejor de los casos, el certificado garantiza la unicidad del sitio web, siempre que el sitio web en sí no haya sido comprometido (pirateado) o el proceso de emisión del certificado subvertido.
Un proveedor de certificados puede optar por emitir tres tipos de certificados, cada uno de los cuales requiere su propio grado de rigor de investigación. En orden de rigor creciente (y naturalmente, costo) son: Validación de dominio, Validación de organización y Validación extendida. Los participantes voluntarios en el CA / Browser Forum acuerdan libremente estos rigores .
Niveles de validación
Validación de dominio
Un proveedor de certificados emitirá un certificado de dominio validado (DV) a un comprador si el comprador puede demostrar un criterio de verificación: el derecho a administrar administrativamente 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 el comprador puede cumplir con dos criterios: el derecho a administrar administrativamente el nombre de dominio en cuestión y, quizás, la existencia real de la organización como entidad legal. Un proveedor de certificados publica sus criterios de verificación de VO a través de su política de certificados .
Validación extendida
Para adquirir un certificado de Validación Extendida (EV), el comprador debe persuadir al proveedor del certificado de su identidad legal, incluidas las comprobaciones de verificación manuales realizadas por un ser humano. Al igual que con los certificados OV, un proveedor de certificados publica sus criterios de verificación de 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 hizo mostrando el nombre legal antes del dominio y un color verde brillante para resaltar el cambio. La mayoría de los navegadores desaprobaron esta función, lo que no proporciona ninguna diferencia visual al usuario sobre el tipo de certificado utilizado. Este cambio siguió a las preocupaciones de seguridad planteadas por los expertos forenses y los intentos exitosos de comprar certificados de vehículos eléctricos para hacerse pasar por organizaciones famosas, lo que demuestra la ineficacia de estos indicadores visuales y resalta posibles abusos.
Debilidades
Un navegador web no advertirá al usuario si un sitio web presenta repentinamente 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. lejano en el futuro. Cuando los proveedores de certificados están bajo la jurisdicción de los gobiernos, esos gobiernos 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 confiables , muchos de los cuales están controlados por organizaciones que pueden ser desconocidas para el usuario. 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.
La lista de certificados incorporados 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 las intranets de la empresa. 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 una seguridad demostrable , esta dependencia de algo externo al sistema tiene la consecuencia de que cualquier esquema de certificación de clave pública tiene que depender de algún supuesto de configuración especial, como la existencia de una autoridad de certificación .
Utilidad frente a sitios web no seguros
A pesar de las limitaciones descritas anteriormente, todas las pautas de seguridad consideran obligatorio TLS autenticado por certificado 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 .
Estándares
La División de Seguridad Informática del Instituto Nacional de Estándares y Tecnología ( NIST ) 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 la infraestructura PKI federal
- SP 800-25 Uso de la tecnología de clave pública por parte de la agencia federal para firmas digitales y autenticación