{"schema_version":"1.0","service":"Publicasta","type":"article","id":941,"slug":"emudhra_intermediate_ca_compromise_certificate_migration_response","title":"El compromiso de la CA de eMudhra convierte la confianza en certificados en un plazo de migración","excerpt":"El compromiso de ocho claves de CA intermedias de eMudhra provocó cambios en navegadores y almacenes de confianza. Los propietarios deben identificar las cadenas afectadas, sustituirlas y revisar el software que no recibe actualizaciones de revocación.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=es","image":{"url":"https://publicasta.com/storage/projects/9/pages/941/2026/10/6b4c4f6e-1d6c-47fc-947a-1ac125e8d17e.webp","alt":"Portátil que muestra rutas abstractas de migración de cadenas de certificados en una sala de servidores segura"},"publisher":{"id":9,"slug":"cybersecurity","name":"Ciberseguridad sin pánico","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-10-22T13:39:37+00:00","updated_at":"2026-10-22T13:39:37+00:00","content_markdown":"## Qué se comprometió y por qué importa la respuesta de los almacenes raíz\n\n ![Portátil que muestra rutas abstractas de migración de cadenas de certificados en una sala de servidores segura](https://publicasta.com/storage/projects/9/pages/941/2026/10/6b4c4f6e-1d6c-47fc-947a-1ac125e8d17e.webp)\n\n El incidente de eMudhra afecta a las claves privadas asociadas con ocho autoridades de certificación subordinadas, o CA intermedias. Según las declaraciones de eMudhra sobre el incidente y los informes publicados por Mozilla y Google, esas claves se comprometieron después de que se generaran claves débiles durante una ceremonia de generación de claves celebrada en 2025. Las autoridades afectadas se utilizaban para TLS y firma de código. La distinción es importante: el incidente afecta a la capacidad de firma de las CA intermedias, no a un compromiso comunicado de las claves privadas raíz de eMudhra, y no debe interpretarse como una prueba de que todos los servicios o productos de certificados de eMudhra se vieran afectados.\n\n La misma distinción se aplica a los servicios de firma digital y eSign de eMudhra orientados a India. Las descripciones proporcionadas del incidente separan esos servicios de las CA intermedias de TLS y firma de código comprometidas. Por tanto, los propietarios de certificados deben identificar la cadena de confianza exacta implicada, en lugar de concluir que se ha producido un fallo en toda la empresa. Un certificado emitido por una CA intermedia afectada, un certificado cuya cadena llega hasta la raíz afectada y un certificado utilizado por un servicio de eMudhra no relacionado son casos técnicos distintos. Tratarlos como si fueran equivalentes crea riesgos operativos y alteraciones innecesarias.\n\n Una CA intermedia es de confianza porque los clientes pueden construir una ruta desde el certificado de entidad final, pasando por esa CA intermedia, hasta una raíz de confianza. La intermedia es la autoridad que firma los certificados presentados por sitios web, aplicaciones o sistemas de firma. Si su clave privada queda expuesta, un atacante puede adquirir la capacidad de crear firmas que parezcan proceder de esa autoridad. Por tanto, el problema central no se limita a saber si ya se ha utilizado indebidamente un certificado conocido. También consiste en determinar si los clientes seguirían aceptando firmas realizadas con una autoridad comprometida.\n\n Por eso, revocar únicamente los certificados de las CA intermedias no ofrece una respuesta uniforme. La revocación depende de que el cliente consulte y aplique la información de revocación pertinente. Los navegadores pueden recibir rápidamente actualizaciones de políticas o listas de bloqueo, mientras que los sistemas operativos, dispositivos integrados, almacenes de confianza privados, entornos de ejecución de aplicaciones y sistemas sin conexión pueden comportarse de otra manera. Algunos clientes quizá no comprueben la revocación de forma fiable; otros pueden seguir utilizando una raíz o una CA intermedia incluida localmente hasta que se actualicen su software o sus datos de confianza. Por ello, una CA intermedia revocada puede seguir planteando un problema práctico de confianza para los sistemas que no procesen la señal de revocación de la forma prevista.\n\n En consecuencia, la respuesta fue más allá de la revocación habitual de certificados. El trabajo de Mozilla sobre los almacenes de confianza y las protecciones de Google para los usuarios de Chrome y Android incluyeron medidas de desconfianza que afectan a la ruta de emSign ECC Root CA - G3. El objetivo de eliminar la confianza en el nivel del almacén raíz es lograr que las cadenas afectadas fallen incluso cuando un cliente no evalúe rápidamente el estado de revocación de una CA intermedia. Se trata de un control amplio: modifica la forma en que los clientes evalúan la propia cadena, en lugar de depender únicamente de una consulta de revocación separada.\n\n Ese cambio también explica por qué el incidente se convierte en un plazo de migración para los propietarios de certificados. Un sitio o servicio puede seguir pareciendo correcto en un navegador o sistema operativo y fallar en otro cliente cuyo almacén de confianza haya cambiado. A la inversa, un sistema que aún no haya recibido la actualización pertinente puede continuar aceptando una cadena que los clientes más recientes rechazan. El síntoma visible puede ser un error de TLS, un fallo de firma o una excepción de confianza específica de la aplicación, pero el problema subyacente es el mismo: distintos clientes pueden dejar de coincidir sobre si la cadena es aceptable.\n\n Por tanto, el límite práctico es preciso. Las pruebas citadas identifican claves de CA subordinadas de eMudhra comprometidas y la consiguiente necesidad de desconfiar de las rutas afectadas; no demuestran un compromiso general de las claves raíz de eMudhra, de servicios de DSC o eSign de India no relacionados, ni una filtración de datos general confirmada. Tampoco demuestran por sí solas que se hayan emitido certificados públicos fraudulentos. Lo que sí demuestran es que una capacidad de firma comprometida no puede gestionarse simplemente esperando las actualizaciones rutinarias de los navegadores. Las organizaciones deben determinar si sus certificados dependen de la cadena afectada y preparar reemplazos que no se basen en ella.\n\n ## Quién está expuesto a fallos y qué dicen realmente las pruebas\n\n El impacto inmediato no es uniforme, porque cada cliente se entera de los cambios de confianza a través de canales distintos. Los operadores de sitios web están expuestos si un certificado desplegado depende de un certificado intermedio de eMudhra afectado o de la ruta emSign ECC Root CA - G3. Los equipos de PKI empresariales afrontan la misma cuestión en servicios públicos y sistemas internos, especialmente cuando los certificados se distribuyen mediante balanceadores de carga, dispositivos, mallas de servicios privadas o almacenes de confianza personalizados. Los desarrolladores de aplicaciones y los responsables del mantenimiento de sistemas operativos tienen una responsabilidad diferente: su software puede depender de datos de certificados incluidos en el paquete o de un proceso de actualización que no siga las decisiones de confianza de un navegador.\n\n La respuesta de Google ilustra la diferencia entre revocar certificados y retirar la confianza en el nivel del cliente. Chrome y Android utilizaron bloqueos basados en CRLSet para los certificados intermedios afectados, mientras que la respuesta de Chrome Root Store también incluye la retirada de confianza en emSign ECC Root CA - G3, prevista para el 27 de octubre. La respuesta de Mozilla utiliza mecanismos de NSS y OneCRL para dejar de confiar en los certificados pertinentes. Estos controles pueden proteger a los usuarios de versiones actuales de navegadores y plataformas sin cambiar de inmediato todos los certificados. No garantizan que todos los consumidores de TLS reciban la misma decisión al mismo tiempo.\n\n Esa brecha es importante para el software que queda fuera del ciclo de actualización del navegador. Un servicio que utiliza el almacén de confianza del sistema operativo puede depender de una actualización de paquetes; una aplicación Java o Python puede usar un paquete mantenido por separado; un dispositivo integrado puede distribuirse con una imagen de larga duración; y una aplicación empresarial puede utilizar un conjunto privado de raíces ensamblado manualmente. La actualización del almacén de confianza de FreeBSD muestra el trabajo de mantenimiento del sistema operativo necesario cuando un compromiso modifica qué certificados deben considerarse confiables. Como resultado, una conexión puede funcionar para un cliente y fallar para otro, o seguir funcionando para un cliente que aún conserva datos de confianza obsoletos.\n\n Las pruebas públicas también deben interpretarse con cuidado. eMudhra afirma que los certificados intermedios afectados no emitieron certificados de entidad final. Es una afirmación importante sobre el historial de emisión observado, pero no equivale a una garantía técnica universal de que no pudiera haberse creado o utilizado ningún certificado no autorizado. El análisis citado de los investigadores señala que Certificate Transparency permite visibilizar los certificados registrados públicamente, mientras que la ausencia de una entrada coincidente no puede demostrar por sí sola que nunca se creó un certificado no registrado. Los registros de transparencia son útiles para investigar y vigilar, pero no eliminan la necesidad de sustituir las rutas de confianza vulnerables.\n\n La respuesta debe guiarse por la diferencia entre los hechos confirmados y la incertidumbre restante. El material citado demuestra el compromiso de las claves privadas asociadas a ocho certificados de CA subordinadas de eMudhra y documenta cambios de confianza en navegadores, almacenes raíz y sistemas operativos. No demuestra una filtración de datos generalizada ni aporta pruebas verificadas de una emisión pública fraudulenta de certificados. Al mismo tiempo, el compromiso de la capacidad de firma de una CA intermedia basta para que seguir confiando en la ruta afectada resulte inaceptable. Por tanto, la exposición práctica está definida menos por si un navegador ya ha bloqueado una conexión que por la capacidad de una organización para identificar todos los sistemas que aún aceptan la cadena antigua.\n\n Para los responsables de servicios, comprobar únicamente el nombre del emisor que aparece en un certificado hoja no basta. La cuestión relevante es cómo termina la cadena completa para cada cliente, incluidas las rutas alternativas y el comportamiento de las firmas cruzadas. Un navegador puede recibir rápidamente una actualización de políticas y dejar de aceptar la cadena, mientras un almacén de confianza privado, un certificado intermedio fijado, un dispositivo o un cliente integrado siguen validándola. Los equipos que consideren que el funcionamiento en un navegador demuestra una seguridad universal corren el riesgo de pasar por alto los sistemas con menos probabilidades de recibir actualizaciones de revocación o del almacén raíz. El siguiente paso debe ser inventariar las cadenas y las decisiones de confianza en toda la organización, no suponer que el resultado de un cliente representa a todo el entorno.\n\n ## El problema del inventario de certificados es la verdadera respuesta al incidente\n\n La cuestión operativa no es simplemente si un navegador rechazará un certificado de eMudhra. Es saber qué certificados, servicios y entornos cliente todavía dependen de una ruta de confianza que está siendo retirada. El primer objetivo útil del inventario es la cadena emSign ECC Root CA - G3. Los responsables deben identificar los certificados cuya ruta completa de certificación llega hasta esa raíz, y después determinar cómo se presenta cada certificado en producción y qué clientes lo consumen. Fijarse solo en el emisor del certificado final no basta: la ruta relevante puede incluir uno o varios certificados intermedios, configuraciones de firma cruzada y rutas alternativas que distintos almacenes de confianza seleccionan de manera diferente.\n\n Por eso, descubrir las cadenas es más importante que hacer una búsqueda rápida del nombre eMudhra en un panel de certificados. Puede que un certificado esté instalado en un servidor web público, pero el mismo servicio también puede estar detrás de un balanceador de carga o una CDN que presenta una copia distinta de la cadena. El material afectado puede existir asimismo en dispositivos de red, servicios internos, sistemas de pruebas, paquetes de confianza de Java o Python, imágenes de contenedores, aplicaciones móviles y otros programas que incorporan sus propios datos de certificados o almacenes raíz. Un inventario que solo cubra el sitio web principal puede ofrecer un resultado tranquilizador y dejar, sin embargo, puntos finales menos visibles dependiendo de la antigua relación de confianza.\n\n Para cada certificado, los equipos deberían registrar el certificado final, todos los intermedios entregados, la raíz o raíces disponibles para el cliente y el sistema responsable de servir o validar la cadena. El objetivo es establecer si la ruta desplegada llega a emSign ECC Root CA - G3 y si existe una ruta de reemplazo que no dependa de los intermedios comprometidos. Esta comprobación debe realizarse sobre los archivos y las configuraciones reales utilizados en producción, no únicamente desde un portal centralizado de gestión de certificados. Un certificado que aparece actualizado en un registro central puede seguir incluido en la imagen de un dispositivo, copiado en un contenedor, fijado dentro de una aplicación o conservado en un entorno gestionado por separado.\n\n La diferencia entre la protección de los navegadores y la protección de otros clientes es fundamental. La respuesta de Google incluye el bloqueo mediante CRLSet para Chrome y Android; Mozilla ha descrito cambios en OneCRL y NSS, y está previsto retirar la raíz del Root Store de Chrome el 27 de octubre. Esos mecanismos pueden reducir la exposición de los usuarios cuyo software recibe las actualizaciones correspondientes del navegador o de la plataforma. No reescriben automáticamente todos los almacenes de confianza privados ni todos los paquetes de aplicaciones. Un cliente que no sea un navegador puede seguir confiando en una raíz obsoleta, y una aplicación que fija un certificado intermedio puede fallar —o seguir utilizando una suposición de confianza inaceptable— incluso después de que los navegadores principales hayan cambiado su comportamiento.\n\n El mismo problema se aplica a los sistemas operativos y las distribuciones de software que mantienen sus propios paquetes de confianza. La actualización del almacén de confianza de FreeBSD ilustra por qué los responsables de las plataformas y los administradores deben seguir el cambio por separado del estado de los navegadores. Por tanto, una organización puede observar resultados distintos en un mismo punto final: un navegador rechaza una conexión mientras un script, un agente de servicio, un dispositivo integrado o un entorno de ejecución empaquetado todavía la acepta; o, a la inversa, un cliente recién actualizado puede fallar porque una aplicación aún no se ha migrado a una cadena de reemplazo. El inventario debe cubrir ambos lados de esa frontera: los sistemas que podrían seguir confiando en la ruta afectada y los sistemas que podrían dejar de confiar en ella antes de que se actualice una aplicación.\n\n Una revisión práctica debería agrupar los hallazgos por dependencia, no por cantidad de certificados. Los puntos finales públicos, los servicios TLS internos, las API orientadas a clientes, las interfaces administrativas, las flotas de dispositivos y las herramientas de compilación o despliegue pueden tener responsables y mecanismos de actualización distintos. Para cada grupo, los equipos necesitan saber dónde se almacena el certificado, cómo se renueva, qué cadena se despliega y si los clientes utilizan el almacén del sistema operativo o un paquete personalizado. Esa información convierte un evento amplio relacionado con los almacenes de confianza en una lista de migración finita. Hasta que esas dependencias se identifiquen y prueben, un resultado limpio en un navegador solo demuestra cuáles son las decisiones de confianza actuales de ese navegador; no demuestra que la organización haya eliminado toda dependencia de la cadena afectada.\n\n ## Un plan defendible de migración y verificación\n\n La respuesta más segura consiste en tratar el incidente como un ejercicio de migración de certificados, no como un motivo para esperar a que los navegadores o los proveedores de sistemas operativos resuelvan el problema automáticamente. Empiece elaborando un inventario de todos los certificados externos e internos cuya ruta de confianza llegue a emSign ECC Root CA - G3. La comprobación debe utilizar la cadena completa presentada y las rutas que seleccionan los clientes reales, en lugar de basarse únicamente en el nombre del emisor mostrado para el certificado hoja. Un certificado puede servirse a través de un balanceador de carga, CDN, proxy inverso, dispositivo, contenedor, entorno de ejecución de Java o Python, aplicación móvil o servicio interno gestionado por separado de la plataforma web principal. Todas esas ubicaciones deben incluirse en la misma revisión.\n\n Para cada certificado identificado, registre el servicio, el propietario, el punto de despliegue, la fecha de expiración, la intermedia emisora, la ruta raíz y las poblaciones de clientes que dependen de él. Compruebe si el despliegue ofrece una ruta alternativa o con firma cruzada, y pruebe qué ruta seleccionan los navegadores, las bibliotecas TLS del sistema operativo, los entornos de ejecución de lenguajes y los clientes integrados. Una conexión aparentemente saludable en un navegador moderno no demuestra que todos los consumidores estén protegidos o sean compatibles. Las protecciones del navegador pueden llegar mediante cambios en CRLSet o en el almacén de confianza del navegador, mientras que un dispositivo antiguo, un almacén de confianza privado o una intermedia fijada pueden seguir aceptando una cadena que el navegador ya no considera fiable.\n\n El siguiente paso es obtener certificados de reemplazo de una cadena no afectada y desplegarlos de forma deliberada. Emitir los reemplazos no basta para dar por terminado el proceso: el nuevo certificado y sus intermedias deben instalarse en todos los lugares donde estaba presente la cadena antigua, incluidos los puntos finales menos visibles y las configuraciones de respaldo. Pruebe el resultado desde las principales categorías de clientes que utiliza la organización. Esto debe incluir navegadores actuales, bibliotecas TLS de los sistemas operativos, integraciones servidor a servidor, aplicaciones Java y Python, imágenes de contenedor, clientes móviles, dispositivos de red y cualquier sistema que utilice un paquete de CA personalizado. Cuando se emplee fijación de certificados o una intermedia incluida en el paquete, revise también la fijación y el paquete como parte de la migración, en lugar de suponer que bastará con actualizar normalmente el almacén de confianza.\n\n Los responsables del mantenimiento de los sistemas operativos y los equipos de aplicaciones también deben confirmar que sus paquetes de confianza reflejan los cambios de desconfianza pertinentes. Actualizar un host no actualiza necesariamente un paquete específico del lenguaje, una imagen base de contenedor, una imagen de firmware de un dispositivo o un almacén de confianza instalado por una aplicación. La misma distinción se aplica a la PKI privada: una organización puede haber copiado hace años una raíz o una intermedia pública en un paquete interno, dejando esa copia fuera de la ruta normal de actualización. El objetivo no es simplemente conseguir que funcione una URL de prueba, sino eliminar la confianza obsoleta allí donde la capacidad de firma comprometida pueda afectar a una conexión.\n\n La verificación debe continuar después del despliegue. Supervise los fallos TLS, los errores de negociación específicos de cada cliente, los diagnósticos de las cadenas de certificados, las comprobaciones de estado de los servicios y los informes del soporte, comparando los resultados entre los grupos de clientes probados antes del cambio. Vigile Certificate Transparency en busca de certificados inesperados asociados a los nombres de la organización e investigue las anomalías mediante el proceso habitual de incidentes. La supervisión de transparencia resulta útil para la detección, pero el análisis citado también deja claro que Certificate Transparency público no puede demostrar que no se haya creado ningún certificado sin registrar. Por tanto, debe complementar el inventario y la validación, no sustituirlos.\n\n El incidente también exige utilizar una redacción disciplinada. Las pruebas citadas no establecen una filtración generalizada de datos ni aportan evidencia verificada de una emisión pública fraudulenta de certificados. Estos límites importan: el compromiso de las claves privadas de una CA intermedia supone una pérdida grave del control de firma, pero por sí solo no demuestra que se haya accedido al tráfico o a los datos de una organización concreta. La conclusión defendible es más acotada y práctica. Debe identificarse cualquier certificado que dependa de la ruta de confianza afectada, reemplazarlo cuando sea necesario y probarlo con el software que realmente lo consume. Los cambios en los navegadores y en los almacenes raíz pueden reducir rápidamente la exposición, pero los responsables de la migración siguen siendo responsables de los clientes y paquetes a los que esos cambios no llegan.","available_translations":[{"language":"ar","title":"اختراق مفتاح CA الخاص بـ eMudhra يحوّل الثقة بالشهادات إلى موعد نهائي للترحيل","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=ar"},{"language":"de","title":"Die Kompromittierung des eMudhra-CA-Schlüssels macht das Zertifikat-Vertrauen zur Migrationsfrist","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=de","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=de","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=de"},{"language":"en","title":"The eMudhra CA Key Compromise Turns Certificate Trust Into a Migration Deadline","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=en","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=en","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=en"},{"language":"es","title":"El compromiso de la CA de eMudhra convierte la confianza en certificados en un plazo de migración","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=es","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=es","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=es"},{"language":"fr","title":"La compromission des clés d’AC d’eMudhra transforme la confiance envers les certificats en échéance de migration","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=fr"},{"language":"pl","title":"Kompromitacja klucza CA eMudhra zamienia zaufanie do certyfikatów w termin migracji","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=pl"},{"language":"ru","title":"Компрометация ключей УЦ eMudhra превращает доверие к сертификатам в крайний срок для миграции","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=ru"},{"language":"zh","title":"eMudhra CA 密钥泄露：证书信任变成迁移期限","html_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=es","html":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=es","canonical":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response?lang=es","markdown":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.md?lang=es","json":"https://publicasta.com/cybersecurity/emudhra_intermediate_ca_compromise_certificate_migration_response.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}