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 acreditar 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 sujeto) y la firma digital de una entidad que ha verificado el contenido del certificado (llamada emisor). Si el dispositivo que examina el certificado confía en el emisor y encuentra que la firma es válida de ese emisor, entonces puede usar la clave pública incluida 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 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), se destaca 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] generalmente una empresa que cobra a los clientes una tarifa por emitirles certificados. 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, es posible que sea necesario revocar un certificado .
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 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 una computadora cliente y un servidor sea segura. El protocolo requiere que el servidor presente un certificado digital que acredite que es el destino previsto. El cliente que se conecta realiza la validación de la ruta de certificación , asegurando que:
El campo Asunto del certificado debe identificar el nombre de host principal del servidor como Nombre común . [ se necesita aclaración ] Un certificado puede ser válido para múltiples nombres de host (por ejemplo, un dominio y sus subdominios). Estos 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 lograr 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 cifrada con el servidor.
Los servidores conectados a Internet, como los servidores web públicos , deben obtener sus certificados de una autoridad de certificación pública (CA) 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 brindan acceso a personas, en lugar de a 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 certificadora que emite el certificado del cliente suele ser el proveedor de servicios al que se conecta el cliente porque es el proveedor que necesita realizar la autenticación. Algunos proveedores de servicios incluso ofrecen certificados SSL gratuitos como parte de sus paquetes. [4]
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 del mensaje y cifrarlo. Para establecer una comunicación cifrada por correo electrónico, las partes comunicantes deberán disponer previamente de sus certificados digitales. Cada uno debe enviar al otro 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 utilice 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 asunto 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 valor de plena confianza cuando el emisor y el único usuario 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 del certificado digital comienza con un certificado autofirmado, llamado certificado raíz , ancla de confianza o raíz de confianza . Una autoridad certificadora autofirma un certificado raíz para poder firmar otros certificados.
Un certificado intermedio tiene un propósito similar al certificado raíz: su único uso es firmar otros certificados. Sin embargo, un certificado intermedio no está autofirmado. Es necesario firmar un certificado raíz u otro certificado intermedio.
Un certificado hoja o de entidad final es cualquier certificado que no puede 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.
Estos son algunos de los campos más comunes en los certificados. La mayoría de los certificados contienen una cantidad de campos que no se enumeran aquí. Tenga en cuenta que en términos de 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 recuperado del sitio web de SSL.com. El nombre común (CN) del emisor 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.
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 22:15:06 2019 GMT No después: 17 de abril 22:15:06 2021 GMT Asunto: C=EE.UU., ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/ jurisdicciónC=EE.UU. Información de clave pública del sujeto: Algoritmo de clave pública: rsaEncryption Clave pública RSA: (2048 bits) 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 Nombre alternativo del sujeto X509v3: 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 certificado 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 CPS: https://www.ssl.com/repository Uso de clave extendida X509v3: Autenticación de cliente web TLS, autenticación de servidor web TLS Puntos de distribución de CRL X509v3: Nombre completo: URI: http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl Identificador de clave de asunto X509v3: E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B Uso de clave X509v3: crítico Firma digital, cifrado de claves Precertificado de CT SCT: Marca 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 22:25:08.574 2019 GMT Extensiones: ninguna Firma: ecdsa-con-SHA256 30:44:02:20:40:51:53:90:C6:A2... Marca 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 22:25:08.461 2019 GMT Extensiones: ninguna Firma: ecdsa-con-SHA256 30:45:02:20:43:80:9E:19:90:FD... Marca 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 22:25:08.769 2019 GMT Extensiones: ninguna Firma: ecdsa-con-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 comúnmente mediante firmas digitales acompañadas de certificados de identidad. Sin embargo, sólo 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 certificadora (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 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 forma 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 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 certificadoras también son responsables de mantener actualizada la información de revocación de los certificados que han emitido, indicando si los certificados aún son 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 . [8]
Algunos programas importantes contienen una lista de autoridades certificadoras en las que se confía de forma predeterminada. [ cita necesaria ] Esto hace que sea más fácil para los usuarios finales validar certificados y que las personas u organizaciones que solicitan certificados sepan qué autoridades certificadoras pueden emitir un certificado que será ampliamente confiable. Esto es particularmente importante en HTTPS, donde un operador de 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 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 necesaria ]
Los navegadores distintos de Firefox generalmente utilizan las funciones del sistema operativo para decidir en qué autoridades de certificación se confía. Entonces, por ejemplo, Chrome en Windows confía en las autoridades certificadoras incluidas en el Programa raíz de Microsoft, mientras que en macOS o iOS, Chrome confía en las autoridades certificadoras del Programa raíz de Apple. [9] Edge y Safari también utilizan sus respectivos almacenes de confianza de sistemas operativos, 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. [ cita necesaria ] Por ejemplo, si bien no existe un programa raíz de Linux común, muchas distribuciones de Linux, como Debian, [10] incluyen un paquete que copia periódicamente el contenido de la lista de confianza de Firefox, que luego es utilizado 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 revocarse antes de que caduque, lo que indica que ya no es válido. Sin la revocación, un atacante podría explotar dicho certificado comprometido o emitido incorrectamente hasta su vencimiento. [11] Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública . [12] La revocación la realiza la autoridad certificadora emisora , que produce una declaración de revocación autenticada criptográficamente . [13]
Para distribuir información de revocación a los clientes, la oportunidad 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 al consultar los estados de revocación y las preocupaciones de privacidad. [14] 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 por completo y tratan un certificado como si estuviera revocado (y así degradan la disponibilidad ) o fallan por software y lo tratan como no revocada (y permitir a los atacantes eludir la revocación). [15]
Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de servicios remotos potencialmente poco confiables, los navegadores web limitan las comprobaciones de revocación que realizarán y fallarán cuando las realicen. [16] Las listas de revocación de certificados consumen demasiado ancho de banda para el 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 una verificación infalible. [12]
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 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, los datos de la empresa y la clave pública. El proveedor del certificado firma la solicitud, generando así un certificado público. Durante la navegación web, este certificado público se entrega a cualquier navegador web que se conecte al sitio web y le demuestra al navegador web que el proveedor cree que ha emitido un certificado al propietario del sitio web.
Como ejemplo, cuando un usuario se conecta con 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 figura en el registrador público en "ejemplo.com", aunque es posible que esa dirección de correo electrónico no aparezca en ninguna parte del sitio web. [ cita necesaria ] 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 necesaria ] 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 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 de investigación. En orden creciente de rigor (y naturalmente, de costo) son: Validación de Dominio, Validación de Organización y Validación Extendida. Estos rigores están vagamente acordados por los participantes voluntarios en el Foro CA/Browser . [ cita necesaria ]
Un proveedor de certificados emitirá un certificado de dominio validado (DV) a un comprador si el comprador puede demostrar un criterio de investigación: el derecho a administrar administrativamente los dominios DNS afectados.
Un proveedor de certificados emitirá un certificado de clase de validación de organización (OV) a un comprador si el comprador puede cumplir dos criterios: el derecho a gestionar 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 OV a través de su política de certificados .
Para adquirir un certificado de Validación Extendida (EV), el comprador debe persuadir al proveedor del certificado de su identidad legal, incluidas verificaciones manuales realizadas por un 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 [17] [18] y no proporcionaron ninguna diferencia visual para el usuario sobre el tipo de certificado utilizado. Este cambio se produjo tras las preocupaciones de seguridad planteadas por expertos forenses y los intentos exitosos de comprar certificados de vehículos eléctricos para hacerse pasar por organizaciones famosas, lo que demuestra la ineficiencia de estos indicadores visuales y destaca posibles abusos. [19]
Un navegador web no avisará 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 caducidad. lejos en el futuro. [ cita necesaria ] 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, con fines de aplicación de la ley. Los proveedores mayoristas de certificados subsidiarios también tienen la libertad de generar cualquier certificado.
Todos los navegadores web vienen con una extensa lista integrada de certificados raíz confiables , muchos de los cuales están controlados por organizaciones que pueden ser 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 que el desarrollador del software del navegador administre su lista integrada de certificados y en que los proveedores de certificados se comporten correctamente e informen al desarrollador del navegador sobre los certificados problemáticos. Aunque 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. [20] [21]
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 intranets de empresas. [22] 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 utilizan 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 basarse en algún supuesto de configuración especial, como la existencia de una autoridad de certificación . [23]
A pesar de las limitaciones descritas anteriormente, todas las pautas de seguridad consideran obligatorio el 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 seguros . [24]
La División de Seguridad Informática del Instituto Nacional de Estándares y Tecnología ( NIST ) [25] proporciona documentos de orientación para certificados de clave pública:
{{cite journal}}: Citar diario requiere |journal=( ayuda )