Hispanopedia Wiki
Articulo de referencia

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 que se utiliza para probar...

Hispanopedia WikiContenido en espanolLectura gratuita

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 probar la atribución válida de una clave pública a la identidad de su titular. [ 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 (llamado emisor).

Si la parte que examina el certificado confía en el emisor y considera que la firma es válida, puede usar la clave pública incluida para interactuar 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 un ordenador u otro dispositivo, aunque los certificados TLS pueden identificar organizaciones o personas además de su función principal de identificar 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 ] generalmente una empresa que cobra a sus clientes una tarifa por emitirles certificados. Por el contrario, en un esquema de red de confianza , los individuos firman directamente las claves de los demás, en un formato que cumple una función similar a la de un certificado de clave pública.

Un certificado de clave pública se solicita normalmente a una infraestructura de clave pública (PKI) mediante una solicitud de firma de certificado (CSR) , que debe transferirse utilizando un protocolo de inscripción de certificados seguro como CMP , EST o ACME . Las partes involucradas en el proceso de inscripción deben verificar la autenticidad, la integridad y la autorización de la CSR, responsabilidad principal del emisor del certificado.

En caso de que se vea comprometida la clave o en otras situaciones que puedan dar lugar a un uso no autorizado, puede ser necesario revocar un certificado .

El formato general para certificados de clave pública y de atributos está definido por X.509 . Para los certificados de clave pública, el formato ha sido perfilado por el IETF para casos de uso relacionados con Internet, como la infraestructura de clave pública (X.509) . [ 4 ]

Cadena de confianza

Las funciones del certificado raíz, el certificado intermedio y el certificado de entidad final en la cadena de confianza.

Un sistema de certificados digitales proporciona una cadena de confianza , lo que significa que la mayoría de los certificados pueden validarse con respecto a certificados raíz. La cadena comienza con un certificado raíz , que actúa como ancla de confianza (también conocido como raíz de confianza). Este certificado es autofirmado (véase más abajo) y no tiene un certificado raíz. La autoridad de certificación emisora ​​utiliza otros métodos para proteger y validar este certificado.

Un certificado intermedio tiene una función similar a la del certificado raíz: su único uso es firmar otros certificados. Sin embargo, un certificado intermedio no es autofirmado. Un certificado raíz u otro certificado intermedio debe firmarlo.

Un certificado de entidad final , o certificado 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 cualificados son todos certificados de entidad final.

Tipos de certificado

Certificado de servidor TLS/SSL

El protocolo Transport Layer Security (TLS), así como su predecesor obsoleto, el protocolo Secure Sockets Layer (SSL), garantiza que la comunicación entre un ordenador cliente y un servidor sea segura. El protocolo exige 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 sujeto del certificado coincide con el nombre de host (que no debe confundirse con el nombre de dominio ) al que el cliente intenta conectarse.
  2. El certificado ha sido firmado por una autoridad de certificación de confianza.

El campo Asunto del certificado debe identificar el nombre de host principal del servidor como Nombre Común . Esto significa que el nombre que aparece en el certificado debe coincidir exactamente con el nombre de dominio al que se conectan los usuarios (por ejemplo, www.example.com), lo que garantiza que el certificado sea válido para ese nombre de host específico. [ 5 ] El nombre de host debe ser accesible públicamente, sin utilizar direcciones privadas ni dominios reservados . [ 6 ] Un certificado puede ser válido para varios 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 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 sea exitosa, el cliente podrá establecer una conexión cifrada con el servidor.

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

Certificado de cliente TLS/SSL

Los certificados de cliente autentican al cliente que se conecta a un servicio TLS, por ejemplo, para controlar el acceso. Dado 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 este proveedor quien debe realizar la autenticación.

Aunque la mayoría de los navegadores web admiten certificados de cliente, la forma más común de autenticación en Internet es mediante 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 los dispositivos.

Certificado de correo electrónico

De acuerdo con el protocolo S/MIME , los certificados de correo electrónico permiten tanto garantizar la integridad del mensaje como cifrarlo. Para establecer una comunicación por correo electrónico cifrada, las partes que se comunican deben contar con sus certificados digitales con antelación. Cada una 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 habitual es que se utilice S/MIME al comunicarse dentro de una organización determinada, y esa organización gestiona su propia CA, en la que confían los participantes de ese sistema de correo electrónico.

Certificado autofirmado

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

Si bien este tipo de certificado no sirve para establecer confianza remota entre partes desconocidas, tiene pleno valor de confianza cuando el emisor y el único usuario son la misma entidad. Como se mencionó anteriormente (en la sección  Cadena de confianza ), un certificado raíz es un certificado autofirmado. La autoridad de certificación, que es el único usuario del certificado, utiliza otros medios para validarlo y protegerlo. Otro ejemplo es el Sistema de cifrado de archivos de Microsoft Windows, que emite un certificado autofirmado en nombre del usuario que realiza el cifrado y lo utiliza para descifrar datos de forma transparente y en tiempo real.

Certificado de nombre alternativo del sujeto

Ejemplo de una sección de Nombre Alternativo del Sujeto para nombres de dominio propiedad de la Fundación Wikimedia.

Los certificados de Nombre Alternativo del Sujeto (SAN) son una extensión de X.509 que permite asociar varios valores a un certificado de seguridad mediante un subjectAltNamecampo. [ 7 ] Estos valores se denominan Nombres Alternativos del Sujeto (SAN). Algunos ejemplos de nombres son: [ 4 ] : §4.2.1.6

Desde mayo de 2000, los Nombres Alternativos del Sujeto (SAN) son el método preferido para agregar nombres DNS a los certificados. [ 8 ] El método anterior de colocar nombres DNS en el commonNamecampo ahora está obsoleto. [ 9 ] Google Chrome versión 58 (marzo de 2017) eliminó la compatibilidad para verificar el commonNamecampo por completo, y en su lugar solo busca los SAN. [ 9 ] Como se muestra en la imagen de la sección de Wikimedia a la derecha, el campo SAN puede contener comodines. [ 10 ] No todos los proveedores admiten o respaldan la mezcla de comodines en certificados SAN. [ 11 ]

Certificado comodín

Un ejemplo de certificado comodín en comifuro.net (nótese el asterisco : *)

Un certificado de clave pública que utiliza un asterisco* ( comodín ) en la parte del nombre de dominio de su sujeto se denomina certificado comodín. Mediante el uso de comodín *, un único certificado puede utilizarse para múltiples subdominios . Se utiliza comúnmente 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 usar un solo certificado para todos los dominios principales y subdominios y reducir costos. [ 12 ]

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

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

Tenga en cuenta las posibles excepciones de las CA, por ejemplo, el certificado wildcard-plus de DigiCert contiene una propiedad "Plus" automática para el dominio sin protección example.com.

Limitaciones

Solo se admite un único nivel de coincidencia de subdominios . [ 13 ] [ 15 ]

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

RFC 6125 argumenta en contra de los certificados comodín por motivos de seguridad, en particular los "comodines parciales". [ 20 ] 

Otros ejemplos

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

Las primeras especificaciones [ 8 ] permitían que el comodín apareciera en cualquier lugar dentro de una etiqueta como un "comodín parcial":

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 "comodín parcial". Desde 2011, la compatibilidad con comodines parciales es opcional y está explícitamente prohibida en los encabezados SubjectAltName que se requieren para los certificados de varios nombres. [ 21 ] : §6.3 Todos los navegadores principales han eliminado deliberadamente la compatibilidad con certificados comodín parciales; [ 22 ] [ 23 ] 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 "comodín parcial". Por ejemplo, ningún certificado "comodín parcial" funcionará con las últimas versiones de Python [ 24 ] y Go. Por lo tanto,

No permita una etiqueta que consista únicamente en un 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 caracteres comodín en su nombre.

*.*.domain.com

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

*.com

Es 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. [ 25 ]

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

Otros certificados

  • 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 vienen precargadas con un certificado del emisor, firmado por la autoridad certificadora EMV [ 26 ], para validar la autenticidad de la tarjeta durante la transacción.
  • Certificado de firma de código : Los certificados pueden validar las aplicaciones (o sus binarios ) para garantizar que no hayan sido manipuladas durante su entrega.
  • Certificado cualificado : Un certificado que identifica a una persona, generalmente para fines de firma electrónica . Su uso es más común en Europa, donde el reglamento eIDAS los estandariza y exige su reconocimiento.
  • Certificado basado en roles: Definidos en la Política de certificados X.509 para la Autoridad Federal de Certificación de Puentes (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". [ 27 ]
  • Certificado de grupo: Definido en la Política de certificados X.509 para la Autoridad Federal de Certificación de Puentes (FBCA) , para "casos en los que hay varias entidades que actúan en una misma capacidad y en los que no se desea la no repudiación de las transacciones". [ 28 ]

Campos comunes

Estos son algunos de los campos más comunes en los certificados. La mayoría de los certificados contienen otros campos que no se enumeran aquí. Cabe destacar que, en términos de la representación X.509 de un certificado, este no es "plano", sino que contiene estos campos anidados en diversas estructuras internas.

  • Número de serie : Se utiliza para identificar de forma unívoca el certificado dentro de los sistemas de una CA. En particular, se utiliza para realizar un seguimiento de la información de revocación.
  • Sujeto : La entidad a la que pertenece un certificado: una máquina, un individuo o una organización.
  • Emisor : La entidad que verificó la información y firmó el certificado.
  • 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 de su emisión para evitar problemas de desfase horario .
  • Fecha y hora a partir de las cuales el certificado deja de ser válido.
  • Uso de la clave : 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 clave y la firma de certificados.
  • Uso extendido de la clave : Aplicaciones en las que se puede utilizar el certificado. Algunos ejemplos comunes son la autenticación de servidor TLS, la protección de correo electrónico y la firma de código.
  • Clave pública : Una clave pública perteneciente 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 somete a una función hash (se utiliza el algoritmo hash especificado en el campo "Algoritmo de firma") y, a continuación, el hash se firma (se utiliza el algoritmo de firma especificado en el campo "Algoritmo de firma") con la clave privada del emisor.

Ejemplo

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

Uso en la Unión Europea

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

Autoridades certificadoras

El procedimiento para obtener un certificado de clave pública

En el modelo de confianza X.509 , una autoridad de certificación (CA) es responsable de firmar certificados. Estos certificados actúan como intermediarios 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 (denominadas suscriptores), verifica la información y, potencialmente, firma un certificado de entidad final basado en dicha información. Para desempeñar esta función de manera efectiva, una CA necesita tener uno o más certificados raíz o 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 gozan de confianza dentro de una comunidad relativamente pequeña, como una empresa, y se distribuyen mediante otros mecanismos, como la Directiva 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 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 principales autoridades de certificación del mercado son IdenTrust , DigiCert y Sectigo . [ 29 ]

Programas raíz

Algunos programas informáticos importantes incluyen una lista de autoridades de certificación de confianza por defecto. Esto facilita a los usuarios finales la validación de certificados y a las personas u organizaciones que los solicitan saber qué autoridades de certificación pueden emitir un certificado ampliamente reconocido. Esto es especialmente importante en HTTPS, donde el operador de un sitio web generalmente busca obtener un certificado en el que confíen prácticamente todos los visitantes potenciales de su sitio.

Las políticas y los procesos que un proveedor utiliza 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 de raíz de Mozilla
  • Programa raíz de Oracle Java
  • Adobe AATL ( Lista de confianza aprobada por Adobe) y EUTL (programas raíz utilizados para la firma de documentos)

Los navegadores distintos de Firefox suelen utilizar las funciones del sistema operativo para determinar qué autoridades de certificación son de confianza. 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. [ 30 ] 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 de Certificación Raíz de Mozilla es de dominio público y su lista de certificados forma parte del navegador web de código abierto Firefox, por lo que se utiliza ampliamente fuera de Firefox. Por ejemplo, aunque no existe un Programa de Certificación Raíz común en Linux, muchas distribuciones de Linux, como Debian, [ 31 ] 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 para los certificados que incluyen. Por ejemplo, algunas autoridades de certificación pueden considerarse de confianza para emitir certificados de servidor TLS, pero no para certificados de firma de código. Esto se indica mediante un conjunto de bits de confianza en el sistema de almacenamiento de certificados raíz.

Revocación

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

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 contrapone al uso de recursos en la consulta de estados de revocación y a las preocupaciones de privacidad. [ 35 ] Si la información de revocación no está disponible (ya sea por accidente o por un ataque), los clientes deben decidir si fallar de forma estricta y tratar un certificado como si estuviera revocado (y así degradar la disponibilidad ) o fallar de forma flexible y tratarlo como no revocado (y permitir que los atacantes eludan la revocación). [ 36 ]

Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de los servicios remotos potencialmente poco fiables, los navegadores web limitan las comprobaciones de revocación que realizan y, cuando las realizan, optan por una comprobación suave. [ 37 ] 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 estricta. [ 33 ]

Seguridad del sitio web

El uso más común de los certificados es para sitios web basados ​​en HTTPS . Un navegador web valida la autenticidad de un servidor web HTTPS , lo que permite al usuario tener la seguridad de que su interacción con el sitio web está protegida y que el sitio es quien dice ser. Esta seguridad es fundamental para el comercio electrónico . En la práctica, el operador de un sitio web obtiene un certificado solicitándolo a una autoridad de certificación mediante una solicitud de firma de certificado . Esta solicitud 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, generando así un certificado público. Durante la navegación web, este certificado público se muestra a cualquier navegador que se conecte al sitio web, demostrando que el proveedor cree haber emitido un certificado al propietario del sitio.

Por ejemplo, https://www.example.com/si un usuario se conecta con su navegador y este no muestra ninguna advertencia sobre el certificado, teóricamente puede estar seguro de que interactuar con el sitio web https://www.example.com/equivale a interactuar con la entidad asociada a la dirección de correo electrónico registrada en el registro público "example.com", aunque dicha dirección no aparezca en ninguna parte del sitio. No se ofrece ninguna otra garantía. Además, la relación entre el comprador del certificado, el operador del sitio web y el creador del contenido puede ser precaria y no está garantizada. En el mejor de los casos, el certificado garantiza la unicidad del sitio web, siempre que este no haya sido comprometido (hackeado) ni se haya manipulado el proceso de emisión del certificado.

Un proveedor de certificados puede optar por emitir tres tipos de certificados, cada uno con su propio nivel de rigor en la verificación. En orden de rigor creciente (y, naturalmente, de coste), son: Validación de Dominio, Validación de Organización y Validación Extendida. Estos niveles de rigor son acordados de forma general por los participantes voluntarios del Foro CA/Browser .

Niveles de validación

Validación de dominio

Un proveedor de certificados emitirá un certificado de validación de dominio (DV) a un comprador si este puede demostrar que cumple con uno de los siguientes criterios de verificación: el derecho a administrar administrativamente el o los dominios DNS afectados.

Validación de la organización

Un proveedor de certificados emitirá un certificado de validación de organización (OV) a un comprador si este cumple dos criterios: el derecho a administrar administrativamente el nombre de dominio en cuestión y, posiblemente, la existencia real de la organización como entidad jurídica. El proveedor de certificados publica sus criterios de verificación OV en su política de certificados .

Validación extendida

Para obtener un certificado de Validación Extendida (EV), el comprador debe demostrar al proveedor de certificados su identidad legal, lo que incluye verificaciones manuales realizadas por una persona. Al igual que con los certificados OV, el proveedor de certificados publica sus criterios de verificación EV en 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 dejaron de ofrecer esta función [ 38 ] [ 39 ], sin proporcionar ninguna diferencia visual al 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 EV para suplantar la identidad de organizaciones famosas, lo que demostró la ineficiencia de estos indicadores visuales y puso de manifiesto los posibles abusos. [ 40 ]

Debilidades

Un navegador web no avisará al usuario si un sitio web presenta repentinamente un certificado diferente, incluso si este tiene un menor número de bits de clave, si proviene de un proveedor distinto o si la fecha de caducidad del certificado anterior es muy lejana. Cuando los proveedores de certificados están bajo la jurisdicción de los gobiernos, estos pueden tener la facultad de ordenarles que generen cualquier certificado, por ejemplo, para fines de aplicación de la ley. Los proveedores mayoristas de certificados subsidiarios también tienen la facultad de generar cualquier certificado.

Todos los navegadores web incluyen una extensa lista integrada 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 tiene la libertad de emitir cualquier certificado para cualquier sitio web y garantizar que los navegadores web que incluyan sus certificados raíz lo aceptarán como auténtico. En este caso, los usuarios finales deben confiar en que el desarrollador del software del navegador gestione su lista integrada de certificados y en que los proveedores de certificados actúen correctamente e informen al desarrollador del navegador sobre los certificados problemáticos. Si bien es poco común, se han producido incidentes en los que se han emitido certificados fraudulentos: en algunos casos, los navegadores han detectado el fraude; en otros, transcurrió un tiempo antes de que los desarrolladores de navegadores eliminaran estos certificados de su software. [ 41 ] [ 42 ]

La lista de certificados integrados tampoco se limita a los proporcionados por el desarrollador del navegador: los usuarios (y en cierta medida las aplicaciones) pueden ampliarla para fines especiales, como las intranets de las empresas. [ 43 ] Esto significa que si alguien accede a un equipo y puede instalar un nuevo certificado raíz en el navegador, este reconocerá como legítimos los sitios web que utilicen dicho certificado.

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

Utilidad frente a sitios web no seguros

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

Estándares

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

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

Véase también

Referencias

  1. 1 2 "Lista de certificados incluidos por Mozilla" . Mozilla.org. Archivado del original el 3 de agosto de 2012. Recuperado el 30 de julio de 2012 .
  2. ↑ Alrawais, Arwa; Alhothaily, Abdulrahman; Cheng, Xiuzhen ; Hu, Chunqiang; Yu, Jiguo (2018-06-01). "SecureGuard: Un sistema de validación de certificados en infraestructura de clave pública". IEEE Transactions on Vehicular Technology . 67 (6): 5399– 5408. Bibcode : 2018ITVT...67.5399A . doi : 10.1109/TVT.2018.2805700 . ISSN 0018-9545 . S2CID 49270949 .  
  3. ↑ Chadwick, David W; Basden, Andrew (31 de octubre de 2001). "Evaluación de la confianza en una autoridad de certificación de clave pública" . Computers & Security . 20 (7): 592– 611. doi : 10.1016/S0167-4048(01)00710-6 . ISSN 0167-4048 . Archivado del original el 26 de febrero de 2022. Consultado el 26 de febrero de 2022 . 
  4. 1 2 Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. (mayo de 2008). Perfil de certificado y lista de revocación de certificados (CRL) de la infraestructura de clave pública X.509 de Internet . IETF . doi : 10.17487/RFC5280 . RFC 5280 .Estándar propuesto. Actualizado por RFC 9549 , 9598 , 8398 , 8399 y 6818. Deja obsoletas las RFC 4630 , 4325 y 3280 .  
  5. ↑ "¿Qué es el nombre común del certificado SSL? - Ayuda de DNSimple" . support.dnsimple.com . Consultado el 22/10/2025 .
  6. ↑ "Nombres internos" . Documentación de DigiCert .
  7. ↑ "x509v3_config - Formato de configuración de extensión de certificado X509 V3" . OpenSSL . Consultado el 16 de enero de 2020 .
  8. 1 2 E. Rescorla (mayo de 2000). HTTP sobre TLS . Grupo de trabajo de redes de la IETF . doi : 10.17487/RFC2818 . RFC 2818 .Obsoleto. Obsoleto según RFC 9110. Actualizado por RFC 5785 y 7230 .  
  9. 1 2 Medley, Joseph (marzo de 2017). "Descontinuaciones y eliminaciones en Chrome 58" . Google Inc. Recuperado el 4 de enero de 2022 .
  10. ↑ "Nombre común (CN) para un certificado comodín" . Documentación de DigiCert.
  11. ↑ "Wildcard and SAN: Understanding Multi-Use SSL Certificates" (PDF) . Thawte . 2013.
  12. ↑ "Certificado comodín explicado en términos más sencillos" . 23 de mayo de 2016.
  13. 1 2 R. Fielding ; M. Nottingham; J. Reschke, eds. (junio de 2022). HTTP Semantics . Internet Engineering Task Force . doi : 10.17487/RFC9110 . ISSN 2070-1721 . STD 97. RFC 9110 . Estándar de Internet 97. Deja obsoletos los RFC 2818 , 7230 , 7231 , 7232 , 7233 , 7235 , 7538 , 7615 y 7694. Actualiza el RFC 3864 .  
  14. ↑ C. Newman (junio de 1999). Uso de TLS con IMAP, POP3 y ACAP . Grupo de trabajo de redes. doi : 10.17487/RFC2595 . RFC 2595 .Norma propuesta. Actualizada por RFC 4616 , 7817 y 8314 . 
  15. ↑ Limitación del certificado SSL comodín en QuovadisGlobal.com
  16. ↑ "Directrices para la emisión y gestión de certificados de validación extendida, versión 1.5.2" (PDF) . CA/Browser Forum. 16 de octubre de 2014. pág. 10. Consultado el 15 de diciembre de 2014. No se permiten certificados comodín para certificados EV. 
  17. ↑ x509v3_config Nombre alternativo del sujeto
  18. ↑ La opción SAN está disponible para certificados EV SSL en Symantec.com.
  19. ↑ Búsqueda de certificados SSLTools del certificado SSL comodín de Wikipedia.org
  20. ↑ Saint-Andre, P.; Hodges, J. (marzo de 2011). RFC 6125 - Representación y verificación de la identidad del servicio de aplicación basado en dominio dentro de la infraestructura de clave pública de Internet mediante certificados X.509 (PKIX) en el contexto de la seguridad de la capa de transporte (TLS) . Grupo de trabajo de ingeniería de Internet . pág. 31. doi : 10.17487/RFC6125 . RFC 6125. Consultado el 10 de diciembre de 2014. Este documento establece que el carácter comodín '*' NO DEBE incluirse en los identificadores presentados, pero PUEDE ser verificado por los clientes de la aplicación (principalmente por motivos de compatibilidad con versiones anteriores de la infraestructura implementada). [...] Varias consideraciones de seguridad justifican el endurecimiento de las reglas: [...] 
  21. ↑ P. Saint-Andre; R. Salz (noviembre de 2023). Identidad de servicio en TLS . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9525 . ISSN 2070-1721 . RFC 9525 . Norma propuesta. Sustituye a RFC 6125 . 
  22. ↑ "Deshabilitar la compatibilidad con a*.example.net, *a.example.net y a*b.example.net en el manejo de comodines de certificados" . The Chromium Projects, Google Inc. 3 de diciembre de 2014. Consultado el 21 de octubre de 2020 .
  23. ↑ "Limitar la compatibilidad con identificadores DNS comodín a nombres con el formato *.example.com (no foo*.example.com)" . La Fundación Mozilla. 10 de diciembre de 2014. Consultado el 21 de octubre de 2020 .
  24. ↑ "No se permite la compatibilidad con a*.example.net, *a.example.net y a*b.example.net en el manejo de comodines de certificados" . The Python Software Foundation. 26 de noviembre de 2017. Consultado el 21 de octubre de 2020 .
  25. ↑ "Restricciones en la introducción de datos para certificados públicos" . Documentación de DigiCert .
  26. ↑ "EMV CA" . Autoridad de Certificación EMV a nivel mundial. 2 de diciembre de 2010. Archivado del original el 4 de julio de 2020. Consultado el 20 de enero de 2020 .
  27. ↑ "Política de certificación X.509 para la Autoridad Federal de Certificación de Puentes (FBCA)" (PDF) . Archivado (PDF) del original el 18 de marzo de 2021. Consultado el 7 de mayo de 2021 .
  28. ↑ "Política de certificación X.509 para la Autoridad Federal de Certificación de Puentes (FBCA)" (PDF) . Archivado (PDF) del original el 18 de marzo de 2021. Consultado el 7 de mayo de 2021 .
  29. ↑ "Estadísticas de uso y cuota de mercado de las autoridades de certificación SSL para sitios web, mayo de 2020" . w3techs.com . Archivado del original el 30 de junio de 2022. Consultado el 1 de mayo de 2020 .
  30. ↑ "Política de certificados raíz – Los proyectos Chromium" . www.chromium.org . Archivado del original el 20 de marzo de 2017. Consultado el 19 de marzo de 2017 .
  31. ↑ "ca-certificates en Launchpad" . launchpad.net . 30 de abril de 2010. Archivado del original el 20 de marzo de 2017. Consultado el 19 de marzo de 2017 .
  32. ↑ Smith, Dickinson y Seamons 2020 , pág. 1.
  33. ^ Sheffer , Saint-André y Fossati 2022 , 7.5. Revocación del Certificado.
  34. ↑ Chung et al. 2018 , pág. 3.
  35. ↑ Smith, Dickinson y Seamons 2020 , pág. 10.
  36. ↑ Larisch y otros. 2017 , pág. 542.
  37. ↑ Smith, Dickinson y Seamons 2020 , págs. 1-2.
  38. ↑ "Grupo de Google Firefox-dev - Intención de lanzamiento: Mover la información de validación extendida fuera de la barra de URL" . groups.google.com . Archivado del original el 12 de agosto de 2020. Consultado el 3 de agosto de 2020 .
  39. ↑ "Chrome Security-dev Google group - Próximo cambio en los indicadores de identidad de Chrome" . groups.google.com . Archivado del original el 7 de junio de 2020. Consultado el 3 de agosto de 2020 .
  40. ↑ "Los certificados de validación extendida están (realmente, realmente) muertos" . troyhunt.com . 12 de agosto de 2019. Archivado del original el 16 de julio de 2020. Consultado el 3 de agosto de 2020 .
  41. ↑ "Mozilla elimina DigiNotar" . Mozilla.org. 2 de septiembre de 2011. Archivado del original el 3 de junio de 2012. Consultado el 30 de julio de 2012 .
  42. ↑ "Eliminación de DigiNotar por Google" . Archivado del original el 13 de septiembre de 2011. Consultado el 30 de julio de 2012 .
  43. ↑ "Artículo sobre el uso de certificados en Mozilla.org" . Mozilla.org. Archivado del original el 12 de julio de 2012. Consultado el 30 de julio de 2012 .
  44. ↑ Ran Canetti: Firma, certificación y autenticación universalmente componibles. CSFW 2004, http://eprint.iacr.org/2003/239 Archivado el 28 de agosto de 2009 en Wayback Machine
  45. ↑ Ben Laurie , Ian Goldberg (18 de enero de 2014). "Reemplazar contraseñas en Internet, también conocido como cifrado oportunista posterior a Snowden" (PDF) . Archivado (PDF) del original el 27 de octubre de 2014. Recuperado el 15 de noviembre de 2014 .
  46. ↑ "Publicaciones de seguridad informática del NIST – Publicaciones especiales (SP) del NIST" . csrc.nist.gov . Archivado del original el 17 de septiembre de 2017. Consultado el 19 de junio de 2016 .
  47. ↑ "SP 800-32 Introducción a la tecnología de clave pública y la infraestructura PKI federal" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado (PDF) del original el 5 de junio de 2018. Consultado el 19 de junio de 2016 .
  48. ↑ "SP 800-25 Uso de la tecnología de clave pública por parte de agencias federales para firmas digitales y autenticación" (PDF) . Instituto Nacional de Estándares y Tecnología. Archivado (PDF) del original el 2 de junio de 2018. Consultado el 19 de junio de 2016 .

Obras citadas

  • 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 OCSP Must-Staple?" (PDF) . Actas de la Conferencia de Medición de Internet 2018. págs. 105–118 . doi : 10.1145/3278532.3278543 . ISBN  9781450356190. S2CID 53223350 . 
  • Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). «CRLite: Un sistema escalable para enviar todas las revocaciones TLS a todos los navegadores». Simposio IEEE de 2017 sobre seguridad y privacidad (SP) . págs. 539–556 . doi : 10.1109/sp.2017.17 . ISBN  978-1-5090-5533-3. S2CID 3926509 . 
  • Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre de 2022). Recomendaciones para el uso seguro de Transport Layer Security (TLS) y Datagram Transport Layer Security (DTLS) . IETF . doi : 10.17487/RFC9325 . RFC 9325 .
  • Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). «Revoquemos: Revocación global escalable de certificados». Actas del Simposio de Seguridad de Redes y Sistemas Distribuidos de 2020. doi : 10.14722/ndss.2020.24084 . ISBN 978-1-891562-61-7. S2CID 211268930 . 
Lecturas relacionadas
6 articulos
Máquina de cifrado de Lorenz de doce rotores con mecanismoCriptografíaMáquina de cifrado de Lorenz , utilizada en la Segunda Guerra Mundial para cifrar las comunicaciones del Alto Mando alemán La criptografía , o crip...Documento electrónicoUn documento electrónico es un documento que puede enviarse por medios no físicos, como télex , correo electrónico e Internet . [1] Originalmente, ...Autenticación de claveLa autenticación mediante clave /configuración se utiliza para resolver el problema de autenticar las claves de una persona (por ejemplo, "persona ...Alice firma un mensaje ("¡Hola Bob!") añadiendo una firma calculada a partir del mensaje y su clave privada. Bob recibe el mensaje, incluida la firma, y, utilizando la clave pública de Alice, verifica la autenticidad del mensaje firmado.Firma digitalUna firma digital es un esquema matemático para verificar la autenticidad de mensajes o documentos digitales. Una firma digital válida en un mensaj...Cifrado de correo electrónicoEl cifrado de correo electrónico consiste en encriptar los mensajes de correo electrónico para proteger su contenido e impedir que sea leído por en...Firma de códigoFirma de códigoLa firma de código es el proceso de firmar digitalmente archivos ejecutables y scripts para confirmar el autor del software y garantizar que el cód...