Introducción
HTTPS y autoridades de certificación
Uno de los pilares estructurales de la Internet moderna es que establecer una conexión desde su ordenador a su sitio web favorito es increíblemente seguro, al menos desde la perspectiva del tráfico subyacente. Ninguna persona u organización puede husmear en sus hábitos en Internet simplemente observando el tráfico entre su ordenador y el sitio web que visita. Todo esto es transparente para el usuario final. Aun así, las tecnologías subyacentes son avanzadas, pero dependen de la definición de círculos de confianza y de una infraestructura de clave pública.
La función de los certificados SSL/TLS
Si su empresa, FooBar, Inc., es propietaria del dominio foobar.com y desea que los usuarios se sientan seguros al interactuar con sus widgets en línea, debería obtener un certificado SSL/TLS de una autoridad de certificación (CA) de confianza. Tras instalarlo en su servidor web, su sitio web puede ofrecer a los usuarios un servicio HTTPS. Esto garantiza que los sistemas operativos y los navegadores web puedan verificar que el sitio web con el que se están comunicando es realmente foobar.com y no un impostor.
Confianza y verificación
Técnicamente, cualquiera puede generar un certificado TLS para cualquier dominio e instalarlo en su infraestructura. Sin embargo, a menos que el certificado sea emitido por una Autoridad de Certificación (CA) reconocida y de confianza, y verificado por esas CAs, los navegadores y sistemas operativos marcarán cualquier intento de utilizar ese certificado con advertencias de seguridad, disuadiendo a los usuarios de continuar.
Convertirse en una CA de confianza
Operar como CA significa emitir certificados en los que confía Internet en general. Esto requiere que su certificado raíz sea reconocido por las principales organizaciones y proveedores que mantienen una base de datos de CA raíz de confianza. Como mínimo, Google, Mozilla, Apple y Microsoft deben confiar en usted, lo que requiere un trabajo ingente.
Cumplimiento y certificación
Para ser considerado por cualquiera de estas organizaciones rectoras, debe pasar por un guantelete virtual de auditorías de cumplimiento y certificaciones. Cada organización rectora tiene sus requisitos mínimos:
Cumplir estas normas no es un esfuerzo puntual, sino un proceso continuo de mantenimiento de la confianza con los responsables de los almacenes raíz y la comunidad de Internet. Esto incluye responder públicamente a cualquier incidente, ya sea descubierto internamente o comunicado por la comunidad. Tanto Google como Mozilla exigen que una CA de confianza revele y responda públicamente a los incidentes mediante Bugzilla.
"Los participantes en el programa Chrome Root DEBEN divulgar públicamente y/o responder a los informes de incidentes en Bugzilla, independientemente del impacto percibido." - Google.
"Como mínimo, los operadores de CA DEBEN informar rápidamente de todos los incidentes a Mozilla en forma de Informe de Incidentes" - Mozilla.
La decisión de Google de retirar Entrust
Entrust es una empresa privada de software y hardware que emite certificados SSL desde 1997. Aunque no está clara la proporción exacta de su negocio que depende del mercado de certificados SSL, es bien sabido que una parte significativa del sector financiero depende exclusivamente de los certificados emitidos por Entrust.
En un anuncio, Google declaró que Entrust ya no cumplía sus expectativas de mantenimiento de los estándares de seguridad. Como resultado, Google decidió que los certificados de varias CA raíz de Entrust dejarían de ser de confianza por defecto para cualquier certificado emitido después del 31 de octubre de 2024.
"Los certificados de autenticación de servidor TLS que se validen en las siguientes raíces de Entrust cuya fecha más temprana del sello de tiempo del certificado firmado (SCT) sea posterior al 31 de octubre de 2024, ya no serán de confianza por defecto."
Este cambio significa que Chrome no confiará en los nuevos certificados emitidos por estas CA raíz de Entrust después de la fecha especificada. Los certificados existentes seguirán funcionando hasta que caduquen o sean revocados.
La razón principal parece ser la falta de comunicación de Entrust con respecto a los informes de incidentes, según Google; sin embargo, no se han dado muchos detalles sobre las razones específicas, pero podemos obtener algunas ideas revisando algunos de los problemas anteriores de Entrust. En la siguiente sección, revisaremos el informe de error/incidente que parece haber sido la gota que colmó el vaso en la decisión de Google de retirar a Entrust del almacén de certificados raíz de Chrome.
La confianza desenvuelta de Entrust
Un ingeniero de Google informó a Paul van Brouwershaven (Director de Tecnología de Entrust) de que a más de veinte mil certificados les faltaba un campo obligatorio en sus certificados. A su vez, estos certificados deberían haber sido tratados como no válidos y marcados como "mal emitidos". - Entrust declaró que se trataba de un error debido a una mala interpretación de los requisitos recientemente modificados.
El verdadero drama comenzó después de que un usuario comentara que Entrust todavía emitiendo certificados erróneos[Comentario #3]. ¿Había solucionado Entrust su error? Por el momento, era incierto.
A continuación, Entrust declara que no estaba previsto interrumpir la emisión actual ni revocar los certificados ya existentes, puesto que consideraban que el asunto no planteaba ningún problema y que la revocación podría tener consecuencias más negativas que la alternativa. El efecto de esto fue sacar sus propias conclusiones e interpretaciones.[Comentario #10]
"Creemos firmemente que la no revocación, y la continuación de la emisión no perjudica a la seguridad, fiabilidad y compatibilidad del ecosistema o a los usuarios de alguna otra manera".
Llegaron algunos comentarios más para recordar a Entrust que no puede limitarse a interpretar y hacer caso omiso de las políticas establecidas[comentario nº 5, comentario nº 6, Comentario #7En el comentario #8, Entrust pidió a la Autoridad de Certificación (CA) de Mozilla [Comentario #5] con un elemento de acción para detener la emisión actual de nuevos certificados y revocar los que ya han sido emitidos, citando la wiki de Mozilla CA que establece que "En casos de emisión errónea, una CA casi siempre debe cesar inmediatamente la emisión de la parte afectada de su PKI".
Entrust vuelve a responder y redobla su reticencia a revocar estos certificados mal emitidos [Comentario #10...], esta vez afirmando que esto afectaría a miles de clientes, muchos de los cuales no se gestionan a través de ningún tipo de proceso automatizado, y que la reemisión de estos certificados supondría una cantidad de trabajo inmanejable. En un último acto de desafío, el representante de Entrust dijo lo siguiente:
"Si Mozilla y la comunidad esperan que las Autoridades de Certificación (CAs) destinen su valioso tiempo a asuntos movidos únicamente por principios, podemos estar avanzando en la dirección equivocada y obstaculizando inadvertidamente el progreso del ecosistema."
Reacción de la comunidad.
Un ingeniero de software respondió de forma bastante cortante, exponiendo la naturaleza de los ecosistemas autorregulados, como una autoridad de certificación que no cumple estas normas de autorregulación; en lugar de la autorregulación, la única opción (obviamente) es una solución estatal que obstaculizaría aún más el progreso. [Comentario nº 11]. Otro usuario intervino poco después para recordar a Entrust que la "P" de PKI significa "Público", y que Entrust presta servicios a esa "P" de "Público", y no al revés. [Comentario#13]
Y como el ave fénix que resucita, un representante del Programa de Raíces de Google Chrome (el informador original de este asunto) escribió un extenso comentario con algunas preguntas muy concretas.
No estaban satisfechos con la respuesta de Entrust; uno de los problemas era el formato de la propia respuesta: carecía de algunos detalles clave que exigen las Directrices comunes para las autoridades de certificación, como la definición del número de activos afectados, un dato clave que sólo se descubrió en las respuestas, y no en el informe inicial. También reprendieron a Entrust por demostrar un juicio cuestionable y hacer caso omiso de las preocupaciones de la comunidad en un suceso que era innecesario y evitable. [ Comentario nº 19].
Durante nueve horas del 18 de marzo de 2024, la sección de comentarios de esta edición permaneció en silencio, sólo para ser interrumpida por una breve y punzante respuesta de Entrust:
"Hemos dejado de emitir certificados erróneos y hemos corregido el perfil de certificado EV.
Se informará a todos los clientes afectados de que sus certificados serán revocados.
Crearemos un error de revocación retardada y haremos un seguimiento de otras cuestiones en los próximos días". - Confiar / [Comentario #20]
Y así, el 18 de marzo a las 3 PM PST, Entrust renunció a su insistencia. Pero poco sabían que esto no era más que el principio de una oleada de consultas.
"¿Así que conseguiste detener la emisión errónea en menos de 10 horas, pero sólo una vez que intervino Google? Antes de eso, ¿simplemente no querías parar?", preguntó JR Moir en Comentario #21 - una pregunta válida que probablemente estaba en la mente de muchos en ese momento. JR continúa "Hay que quitar la confianza a Entrust". El primer disparo de revuelta sonó en el campo de hierba de la seguridad en Internet.
Durante las semanas siguientes, Entrust interactuó con la comunidad en un intento de localizar todos los certificados afectados. No fue hasta el 4 de abril cuando Entrust respondió directamente a los comentarios y preguntas iniciales del Programa Raíz de Chrome en el comentario nº 35. Entrust declaró que, si bien su respuesta no se ajustaba a las expectativas establecidas de una CA, la intención era actuar en el mejor interés de los clientes o, como ellos dicen, del ecosistema web. A continuación, Entrust respondió a cada una de las preguntas del comentario, insistió en que sólo se trataba de un descuido y reconoció su mala actuación.
"En retrospectiva, reconocemos que deberíamos haber detenido la emisión de certificados EV sin el calificador de política tras la confirmación del problema, y luego hacer un seguimiento para perseguir lo que vimos como un posible descuido en las Directrices EV." - Comentario nº 35 / Respuesta a la pregunta 1 del comentario nº 19
El comentario 35 está lleno de información valiosa que da una idea de todos los pasos en falso que Entrust dio a lo largo de este viaje, incluyendo detalles sobre todo su proceso de emisión; se dedicaron grandes cantidades de esfuerzo a las explicaciones de algunas de las suposiciones que se hicieron que llevaron a estas decisiones; No incluyeron el campo requerido en los nuevos certificados porque habían pensado erróneamente que era un error en el propio texto de las directrices de la CA:
"...creíamos que la falta de "certificatePolicies:policyQualifiers:qualifier:cPSuri" en los certificados EV emitidos se debía a un error en las Directrices EV". - Comentario nº 35 (Entrust)
Seis días después, Entrust publicó un informe de incidentes actualizado para este problema(comentario nº 41) que incluía una cronología completa de los hechos. Una respuesta que sólo evocó la ira de la comunidad una vez más. En el comentario 44, un usuario escribe que espera que otras autoridades de certificación consideren todo este incidente como una "lección de la que aprender" tras observar que, incluso después de tres semanas, ni siquiera la mitad de los "clientes afectados" han sido reparados, y sólo la mitad de los certificados emitidos erróneamente han sido revocados. Y luego otro llamamiento a la retirada de Entrust:
"Esta repetición de fallos muestra claramente que no se puede confiar en Entrust en la WebPKI y debe ser eliminada". - JR Moir(Comentario #44)
En respuesta, el representante de Entrust declaró que su base de abonados es diferente a la de otras CA (posiblemente más grandes) - posiblemente refiriéndose a la clase de cliente a la que Entrust atiende. Entrust continúa:
"Esperamos que los miembros de la comunidad que tienen experiencia en el ámbito en el que opera Entrust comprendan nuestros retos y que estamos haciendo todo lo posible para que nuestros abonados estén mejor preparados y sean más ágiles ante los incidentes de seguridad" - Entrust(Comentario nº 46)
El hilo se queda en silencio después de esto, aparte de una salpicadura de comentarios aquí y allá con historias y cuentos de los fallos históricos de Entrust. El último comentario fue del director del programa Mozilla CA, Ben Wilson, solicitando acciones adicionales de Entrust, que se emitió un nuevo ticket ID #1901270: Entrust: Action Items from June 2024 Report.
Este ha sido sólo el último drama en el que se ha visto envuelto Entrust. En marzo de 2024, se informó de que Entrust había emitido erróneamente 1.176 certificados porque sus herramientas no detectaron algunos certificados no conformes. Aunque esto no fue un gran problema en sí mismo, los certificados afectados por este error no se revocaron a tiempo, lo que dio lugar a otro incidente que se hizo público.
Algunos comentaristas incluso hicieron referencia a la naturaleza escasa del seguimiento y señalaron que Entrust parece estar culpando a los clientes de su incapacidad para revocar estos certificados rápidamente. Un mes antes de esto, se informó de que Entrust estaba utilizando SHA-1 (un algoritmo hash obsoleto) para firmar respuestas a través de OCSP y tuvo un largo tira y afloja con la comunidad en general, respondiendo a preguntas frustradas sobre por qué no habían descubierto esta información antes.
Existen varios ejemplos más de la pérdida de confianza del público en Entrust, la mayoría de los cuales implican retrasos en las respuestas y lentitud en la revocación de certificados. Estos problemas agravados son la razón por la que Google ha decidido dejar de admitir certificados emitidos por Entrust en su almacén de certificados raíz.
Con más de dos décadas en el sector y su (desgraciadamente) mal recibida historia reciente, parece que puede ser el principio del fin para la autoridad de certificación de Entrust. Hoy es Google, mañana pueden ser Mozilla y Microsoft.
Se trata de algo importante, una decisión que no debe tomarse a la ligera. En todo caso, hay lecciones que aprender aquí. La erosión de la confianza entre un servicio público y su comunidad puede tener consecuencias nefastas.
Marcas de tiempo de certificados firmados
Los SCT son recibos digitales emitidos por los registros de Certificate Transparency (CT) cuando una CA envía un certificado para su registro. Estas marcas de tiempo proporcionan la prueba de que el certificado se ha registrado en un registro público, lo que permite la auditoría pública. Cuando una autoridad de certificación (CA) emite un nuevo certificado, lo envía a uno o varios registros CT. Una vez que el registro CT recibe el certificado y crea un registro del mismo, el registro CT genera un SCT, que incluye lo siguiente:
- Una marca de tiempo que indica cuándo se registró el certificado
- El hash del certificado
- Un identificador único para el registro
- Una firma digital creada por la clave privada del registro.
En la mayoría de los casos, este SCT se incrusta directamente en el certificado. A continuación se muestra un ejemplo de cómo se podría ver la información SCT del nombre de dominio "www.censys.com":
echo | openssl s_client \
-connect www.censys.com:443 2>/dev/null | | | \
openssl x509 -text -noout | | | \
grep -A 11 "Certificado firmado Timestamp"
La salida de este comando será similar a la siguiente:
Marca de tiempo del certificado firmado:
Versión : v1 (0x0)
ID de registro : 3F:17:4B:4F:D7:22:47:58:94:1D:65:1C:84:BE:0D:12:
ED:90:37:7F:1F:85:6A:EB:C1:BF:28:85:EC:F8:64:6E
Timestamp : May 21 05:16:30.739 2024 GMT
Extensiones: ninguna
Firma : ecdsa-with-SHA256
30:45:02:21:00:EC:76:D9:73:19:C7:94:12:EE:60:28:
D7:0B:71:F6:7F:33:60:ED:47:3F:B1:CD:E4:26:59:83:
21:B0:AD:99:5C:02:20:24:98:7F:9B:DC:E5:FD:E8:A9:
1E:B9:25:F7:5E:0C:15:ED:B7:38:2B:5F:C4:68:FB:26:
A9:E9:03:60:D1:CF:F5
- Versión: Indica la versión del SCT; aquí es la versión 1.
- Sello de tiempo: La fecha y hora en que se emitió el SCT..
- Firma: La firma criptográfica que valida el SCT.
- ID del registro: Un identificador único para el registro que emitió el SCT, representado como una secuencia de bytes hexadecimales.
Para encontrar el proveedor de registros para un "Log ID" determinado, (donde se pueden encontrar detalles sobre esta emisión) se pueden utilizar los siguientes comandos:
$ LOGID=$(echo 3F:17:4B:4F:D7:22:47:58:94:1D:65:1C:84:BE:0D:12:ED:90:37:7F:1F:85:6A:EB:C1:BF:28:85:EC:F8:64:6E | \
sed -s 's/://g' | \
xxd -p -r | base64); \
curl -s https://www.gstatic.com/ct/log_list/v3/all_logs_list.json | \
jq ".operators[].logs[]|select(.log_id == \"$LOGID\")|."
{
"description": "Let's Encrypt 'Oak2024H2' log",
"log_id": "PxdLT9ciR1iUHWUchL4NEu2QN38fhWrrwb8ohez4ZG4=",
"key": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE13PWU0fp88nVfBbC1o9wZfryUTapE4Av7fmU01qL6E8zz8PTidRfWmaJuiAfccvKu5+f81wtHqOBWa+Ss20waA==",
"url": "https://oak.ct.letsencrypt.org/2024h2/",
"mmd": 86400,
"state": {
"usable": {
"timestamp": "2022-11-30T17:00:00Z"
}
},
"temporal_interval": {
"start_inclusive": "2024-06-20T00:00:00Z",
"end_exclusive": "2025-01-20T00:00:00Z"
}
}
Este resultado nos indica que podemos validar este SCT utilizando el servidor "Let's Encrypt 'Oak2024H2' log".
En el caso de Google Chrome, se añade un paso adicional (o restricción) al proceso de verificación de cualquier certificado. Esta restricción comprueba si este SCT se generó el 31 de octubre de 2024 o después, y si se ha cumplido la restricción, el certificado será rechazado.
El impacto en Internet
Podemos examinar los conjuntos de datos de hosts y certificados de Censys para comprender la posición de Entrust entre otras autoridades de certificación y el impacto potencial que esto puede tener si no se aborda con prontitud.
Desglose de autoridades de certificación
En total, Google ha confiado en certificados de 464 autoridades distintas, que suman 7.559.114.541 (siete mil millones) de certificados emitidos. Entre ellas, Entrust, Inc. ocupa el puesto 22, con 3.999.827 (0,05%) certificados de confianza de Google, y AffirmTrust el puesto 78, con la friolera de 37.646.
Las cifras son diferentes si nos fijamos en los certificados actualmente válidos, es decir, los certificados que no han sido revocados ni han caducado. A 28 de junio de 2024, Google confía en 747.659.643 certificados válidos emitidos por 244 autoridades de certificación distintas. Entrust, Inc. ocupa el puesto 20 con 571.469 certificados actualmente válidos, y AffirmTrust el puesto 120 con 625.
Estas cifras reflejan el número total de certificados emitidos, no necesariamente los que están actualmente en uso. Determinar el número de certificados en uso y activos es imposible, ya que requeriría acceder a cada organización u ordenador individual. Sin embargo, utilizando datos de escaneado actuales e históricos, Censys puede proporcionar datos sobre el número de certificados emitidos por Entrust observados en la Internet pública.
Entrust en Internet
En la entrada original, Google enumera nueve autoridades emisoras de certificados raíz diferentes propiedad de Entrust y enlaza con cada entrada correspondiente en crt.sh; desde aquí, podemos anotar la huella digital SHA-256 del certificado de cada una de ellas y buscar hosts que tengan una de estas nueve huellas digitales en sus cadenas de certificados:
| CA emisora |
Huella digital SHA-256 |
| CN=Autoridad de certificación raíz deEntrust - EC1 |
02ed0eb28c14da45165c566791700d6451d7fb56f0b2ab1d3b8eb070e56edff5 |
| CN=Autoridad de certificación raíz deEntrust - G2 |
43df5774b03e7fef5fe40d931a7bedf1bb2e6b42738c4e6d3841103d3aa7f339 |
| CN=Autoridad de certificación deEntrust.net (2048) |
6dc47172e01cbcb0bf62580d895fe2b8ac9ad4f873801e0c10b9c837d21eb177 |
| CN=Autoridad de certificación raíz de Entrust |
73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c |
| CN=Autoridad de certificación raíz deEntrust - G4 |
db3517d1f6732a2d5ab97c533ec70779ee3270a62fb4ac4238372460e6f01e88 |
| CN=AffirmTrust Comercial |
0376ab1d54c5f9803ce4b2e201a0ee7eef7b57b636e8a93c9b8d4860c96f5fa7 |
| CN=Red de confianza |
0a81ec5a929777f145904af38d5d509f66b5e2c58fcdb531058b0e17f3f0b41b |
| CN=AffirmTrust Premium |
70a73f7f376b60074248904534b11482d5bf0e698ecc498df52577ebf2e93b9a |
| CN=AffirmTrust Premium ECC |
bd71fdf6da97e4cf62d1647add2581b07d79adf8397eb4ecba9c5e8488821423 |
services.tls.certificates.chain.fingerprint = {
02ed0eb28c14da45165c566791700d6451d7fb56f0b2ab1d3b8eb070e56edff5,
43df5774b03e7fef5fe40d931a7bedf1bb2e6b42738c4e6d3841103d3aa7f339,
6dc47172e01cbcb0bf62580d895fe2b8ac9ad4f873801e0c10b9c837d21eb177,
73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c,
db3517d1f6732a2d5ab97c533ec70779ee3270a62fb4ac4238372460e6f01e88,
0376ab1d54c5f9803ce4b2e201a0ee7eef7b57b636e8a93c9b8d4860c96f5fa7,
0a81ec5a929777f145904af38d5d509f66b5e2c58fcdb531058b0e17f3f0b41b,
70a73f7f376b60074248904534b11482d5bf0e698ecc498df52577ebf2e93b9a,
bd71fdf6da97e4cf62d1647add2581b07d79adf8397eb4ecba9c5e8488821423
}
Industrias y organizaciones afectadas
En el momento de escribir estas líneas, 876.681 hosts físicos y virtuales utilizaban un certificado emitido por una de las nueve CA de Entrust. Aunque puede que no sea una cifra muy interesante, podemos examinar las hojas de certificados para saber en qué organizaciones e industrias se encuentran estos certificados.
Analizamos cada nombre de dominio registrado encontrado en los certificados de hoja emitidos por estas nueve CA de Entrust. En la medida de nuestras posibilidades, clasificamos los dominios por el número de hosts únicos que se encuentran actualmente en Internet. Además, clasificamos las empresas e industrias asociadas para los certificados con diez o más hosts (5.285 nombres de dominio). Aquí no incluimos los subdominios, sino sólo los nombres de dominio registrados ("www.censys.com" se convierte en "censys.com").
La gran mayoría de los certificados Entrust emitidos en línea pertenecen a los sectores de Servicios Financieros (254.654 hosts y 19.151 certificados de hoja únicos), Tecnología (136.408 hosts y 9.609 certificados de hoja), Entretenimiento (63.884 hosts y 1.121 certificados de hoja) y Administración Pública (58.490 hosts y 8.044 certificados de hoja).
Sin embargo, el número de certificados de hoja por sector ofrece una imagen ligeramente diferente. Los "Servicios profesionales" pasan del nº 9 al nº 3 cuando examinamos el número de certificados de hoja, lo que indica que, aunque el sector del "Entretenimiento" se encuentra en muchos hosts, abarca un número limitado de empresas o nombres de dominio. Sin embargo, también podemos ver que el sector de los servicios financieros se mantiene en el nº 1 tanto en número de hosts como de certificados de hoja únicos. En otras palabras, muchas empresas financieras confían en Entrust.
Las 20 primeras industrias por número de hosts y certificados de hoja.
Organizaciones
También podemos examinar las organizaciones específicas que componen estas industrias para comprender mejor quién se verá afectado por la relación rota de Entrust con Google. De nuevo, separamos las estadísticas por el número de hosts y certificados de hoja única encontrados con un emisor de Entrust en Internet.
Aquí podemos ver resultados muy diferentes en función de cómo se ordenen los datos. La empresa Disney tiene certificados emitidos por Entrust en más de 57.000 hosts reales y virtuales únicos, pero sólo 636 certificados de hoja únicos. Una rápida Censys Search revelará por qué ocurre esto.
Muchos hosts en los que vemos certificados emitidos por Entrust para "*.disney.com" se encuentran en Akamai, una Red de Entrega de Contenidos que muchas empresas medianas y grandes utilizan para almacenar en caché y servir sus datos. Aunque Disney sólo tiene 636 certificados, se han encontrado en más de 57.000 hosts "virtuales" en nuestros datos de escaneado.
Disney ocupó el primer puesto en número de hosts, y tenía 40 nombres de dominio en 636 certificados leaf únicos, la mayoría de los cuales eran para disney.com y dominios relacionados con disney.com. A continuación se muestran los veinte principales dominios relacionados con Disney con un certificado emitido por Entrust y las estadísticas de host y hoja correspondientes.
Sin embargo, Ernst & Young sólo tenía diez nombres de dominio que clasificamos con 6.200 certificados de hoja únicos emitidos por Entrust en 16.063 hosts.
Una vez más, la mayoría de estos certificados ey.com se encuentran en Akamai. Sin embargo, una buena parte de ellos también se ejecutan en el sistema autónomo de Microsoft, lo que indica que Ernst & Young ejecuta gran parte de su infraestructura en Azure.
Pero estos recuentos de hosts pueden ser muy engañosos porque un único certificado puede contener muchos nombres diferentes sobre los que es autoritativo; por ejemplo, este único certificado de Ernst & Young de la izquierda es para ambos nombres de dominio "ey.com" y "eyclienthub.com", por lo que si se desglosan las estadísticas por el nombre de dominio registrado, este certificado en un único host se contaría dos veces.
¿Qué se puede hacer?
- Aunque los certificados de confianza actuales no se verán afectados por este cambio, si una persona u organización utiliza Entrust ahora y sigue necesitando certificados en un futuro previsible, debe planificar la obtención de sus nuevos certificados de otra CA de confianza y actualizar la infraestructura en consecuencia.
- Si cree que puede verse afectado por este cambio, esta consulta de búsqueda puede modificarse para encontrar cualquier host que Entrust emita para su dominio (sólo tiene que sustituir "sudominio.com: por su propio nombre de dominio).
- Censys Los clientes de ASM pueden acceder a un nuevo riesgo de baja prioridad denominado "Certificado emitido por Entrust", que notificará automáticamente a los clientes cuando se encuentre un certificado emitido por Entrust en su entorno.
