Claves comprometidas en la CA eMudhra: qué deben comprobar y corregir ya las empresas

El sábado 17 de octubre de 2026, un investigador de seguridad informó de que ocho autoridades de certificación intermedias gestionadas por eMudhra, una autoridad de certificación india, tenían claves privadas que cualquiera podía deducir a partir de los certificados públicos. Cada una de las claves era un número menor que 256. Una de ellas era el número 4. Seis de las ocho podían emitir certificados TLS en los que confían Apple, Google, Microsoft y Mozilla; las otras dos podían firmar software para Windows.

Chrome bloqueó las seis claves TLS una hora y cuarenta minutos después del aviso, y Firefox esa misma noche. Para quien navega por la web, el peligro había pasado antes de que terminara el sábado.

Para todo lo demás, no. Servidores, contenedores, aplicaciones Java, scripts de Python, integraciones de pago y dispositivos conectados comprueban los certificados contra su propia copia de la lista de autoridades de confianza, y la mayoría de esas copias solo cambian cuando alguien instala una actualización. Hasta entonces, un certificado para cualquier dominio firmado con una de estas claves pasa por auténtico, y las claves son públicas desde el 20 de octubre.

Esa misma semana, GoDaddy empezó a revocar 404.607 certificados porque la información de política que contenían no coincidía con sus propios documentos publicados. Sus clientes tuvieron que descargar e instalar ellos mismos los certificados de sustitución.

Esta guía es para quienes tienen que responder a «¿nos afecta?»: responsables de TI y de operaciones, CTO y fundadores cuyo negocio depende de un sitio web, una API o un producto conectado. Explica qué pasó, a partir de los registros del incidente que han publicado Mozilla, Google, eMudhra, GoDaddy y los proveedores de software; qué comprobar hoy; qué actualizar esta semana; y qué dejar preparado para que el próximo incidente de este tipo sea rutina. Todo lo que se dice aquí refleja la situación a 22 de octubre de 2026, y el incidente sigue abierto.

Qué pasó

eMudhra creó las ocho intermedias en una ceremonia de claves el 30 de abril de 2025. Su versión, publicada en el bug del incidente en Mozilla el 19 de octubre: una prueba de encapsulado y desencapsulado de claves (key wrap y unwrap), aprobada como desviación de su procedimiento habitual, tenía un fallo que generó en el módulo de seguridad hardware (HSM) un segundo juego de claves, débiles, junto a las previstas. Las etiquetas eran parecidas, las claves débiles se usaron por error para crear las solicitudes de certificado y la raíz de eMudhra las firmó. Las mismas solicitudes se enviaron a Sectigo, que el 14 de mayo de 2025 firmó de forma cruzada las ocho desde su raíz AAA Certificate Services. eMudhra dice que «aún no ha confirmado la causa raíz exacta».

Mozilla describió el resultado: «Las claves privadas P384 son enteros seleccionados al azar entre 1 y el orden del grupo. Las 8 claves afectadas usaban todas enteros menores que 256». Mozilla recibió el aviso a las 20:06 UTC y recuperó las claves por su cuenta a las 21:48, «sin conocer en absoluto el método que utilizó el autor original del aviso». El investigador dice que las encontró con paranoid_crypto, la biblioteca de código abierto de Google, «de serie». Las claves débiles llevaban casi 18 meses formando parte de cadenas de confianza pública.

Los ocho certificados:

Cada clave está en dos certificados. Uno lo emitió emSign Root TLS CA - G3 o emSign Root CS CA - G3, de eMudhra, que encadenan hasta emSign ECC Root CA - G3; el otro es el certificado cruzado de Sectigo desde AAA Certificate Services. La segunda ruta importa, porque algunos almacenes de confianza que nunca incluyeron una raíz de eMudhra siguen confiando en esa antigua raíz de Sectigo.

¿Hubo algún ataque?

Nadie ha informado de un uso indebido, y en el caso de los navegadores hay buenos motivos para pensar que no lo hubo. Chrome, como otros clientes que exigen Certificate Transparency (CT), solo acepta un certificado si figura en los logs públicos de CT. Google: antes de su bloqueo no figuraba en los logs ningún certificado TLS que encadenara a estas seis intermedias, así que «ningún certificado fraudulento emitido por estas CA podría haberse usado contra clientes que exigen CT».

Fuera del navegador, la situación es otra. La página del incidente de Mozilla: «muchos clientes fuera del ecosistema de los navegadores no exigen Certificate Transparency. No sabemos si hubo atacantes que aprovecharan la generación defectuosa de claves para atacar a estos clientes». Esa ventana se abrió en la primavera de 2025 y, para cada cliente, solo se cierra cuando se actualiza. eMudhra dice que no tiene constancia de ninguna prueba de que las claves se recuperaran antes de la divulgación, y Cloudflare dice que su revisión no encontró explotación activa en sus servicios.

Ahora que las claves son públicas, falsificar un certificado no requiere ninguna habilidad. La página del incidente de Mozilla enumera servidores de prueba que presentan certificados emitidos con las claves comprometidas, para que cualquiera pueda probar sus clientes contra ellos (los comandos están más abajo).

Qué permite un certificado falsificado: alguien que pueda interceptar el tráfico entre tu software y un servicio al que llama (en una red compartida, a través de un router comprometido o con una respuesta DNS envenenada) puede suplantar ese servicio, leer lo que envía tu software, incluidas claves de API y datos personales, y modificar lo que recibe. El software firmado con una de las dos claves de firma de código habría superado la comprobación de firmas de Windows hasta que el bloqueo de Microsoft llegara a la máquina.

A quién afecta

Hay tres problemas distintos, y una misma empresa puede tenerlos todos.

1. Software que sigue confiando en las claves comprometidas

Este lo tiene casi cualquier empresa: cualquier programa que haga llamadas HTTPS, cuyo almacén de confianza siga conteniendo emSign ECC Root CA - G3 o AAA Certificate Services y que no haya recibido un bloqueo para las ocho claves. Lugares típicos:

• Servidores Linux e imágenes de contenedor construidas antes del 20 o el 21 de octubre. Un Debian 12 sin parchear, por ejemplo, confía en las dos cadenas.
• Entornos de ejecución de lenguajes que traen su propia lista: Node.js, certifi de Python, el cacerts de Java, el bundle de Composer de PHP, webpki-roots de Rust.
• Las herramientas de línea de comandos de macOS. La página del incidente de Mozilla dice que las versiones de curl, git, python3, perl, ruby y openssl que trae el sistema comprueban los certificados contra /etc/ssl/cert.pem sin comprobar la revocación, y que Apple no ha actualizado ese fichero.
• Equipos Windows que no reciben las actualizaciones automáticas de Microsoft de su lista de certificados no permitidos, normalmente porque una directiva de grupo las desactiva o porque la red no tiene conexión.
• Appliances, dispositivos y software de terceros que incluyen su propio fichero de CA, como balanceadores de carga, pasarelas VPN, SDK y controladores embebidos.

Cada entorno de ejecución hay que comprobarlo por separado. En una prueba que hicimos el 22 de octubre, una máquina Debian 12 sin parchear con Node.js 24.18 aceptó la cadena que termina en la raíz de eMudhra y rechazó la que termina en la de Sectigo, mientras que Python, en la misma máquina, aceptó las dos.

2. Empresas cuyos propios certificados encadenan a la raíz retirada

Mozilla y las distribuciones de Linux han retirado emSign ECC Root CA - G3, y Chrome lo hará el 27 de octubre. Los certificados válidos bajo esa raíz dejan de funcionar en cada cliente a medida que este se actualiza. La instrucción de Google: los operadores de sitios web con esos certificados «deben obtener e instalar de inmediato un nuevo certificado TLS de otra jerarquía PKI incluida en el Chrome Root Store».

El 21 de octubre, Chrome contó en CT unos 30.800 certificados no caducados bajo esa raíz. De ellos, 30.791 procedían de dos intermedias de InCommon, el servicio de certificados que Internet2 gestiona para universidades e instituciones de investigación de Estados Unidos y que emite certificados ECC a través de CERTInext, la plataforma de eMudhra. Otros 18 procedían de las intermedias propias de eMudhra. eMudhra dice que hay que migrar unos 30.000 certificados, en torno al 97% de ellos emitidos mediante ACME, y que está emitiendo sustitutos desde otra jerarquía.

Si tu sitio está detrás de Cloudflare en modo Full (strict) y el origen presenta un certificado bajo esta raíz, Cloudflare dice que la retirada de confianza «provocaría fallos» y pide a sus clientes que «revisen sus certificados de origen personalizados y la configuración de sus servidores».

Los certificados RSA de la otra raíz de eMudhra, emSign Root CA - G1, no están afectados por ahora. Mozilla dice que no va a retirar esa raíz «por el momento»; Chrome está «investigando de cerca si se mantiene la inclusión de los demás certificados de CA de eMudhra». Si dependes de certificados de eMudhra o de CERTInext, del tipo que sean, ten preparada ya una segunda autoridad de certificación.

3. Clientes de GoDaddy

El caso de GoDaddy no tiene nada que ver con eMudhra, pero llegó la misma semana y afectó a muchos más sitios. El 15 de octubre, GoDaddy informó a Mozilla de que los certificados de sus jerarquías GoDaddy y Starfield contenían información de política de certificados (OID de política y enlaces a la CPS) que no coincidía con los perfiles de su propia CP/CPS, el documento en el que una autoridad de certificación declara qué emite. No es un fallo de seguridad de los certificados. Pero según los Baseline Requirements, las normas que sigue toda autoridad de certificación pública, sigue siendo motivo para revocarlos en un plazo de cinco días.

Se vieron afectados 404.607 certificados, 396.055 de ellos de validación de dominio. GoDaddy revocó 170.566 dentro del plazo, que vencía el 18 de octubre a las 23:45 UTC, y 227.422 a la mañana siguiente; su aviso a clientes dice que el resto se revocó el 21 de octubre. GoDaddy vuelve a emitir los certificados, pero instalarlos corre por cuenta del cliente: «los visitantes de tu sitio web pueden ver advertencias de seguridad, y tu sitio puede quedar inaccesible hasta que se instale un nuevo certificado».

Qué comprobar hoy

1. ¿Qué envían tus propios servidores? Para cada nombre de host público, enumera los emisores de la cadena que presenta:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Una línea que nombre a eMudhra, emSign, una de las autoridades EM ... G3B o G3C, o InCommon Intermediate CA - DVG3C, OVG3C o EVG3C significa que hay que sustituir el certificado antes del 27 de octubre. Que aparezca solo AAA Certificate Services es normal, ya que muchas cadenas corrientes de Sectigo todavía la incluyen. Para los servicios de correo y de directorio, añade -starttls smtp (o imap, ldap) y el puerto correcto. Incluye los hosts internos, los balanceadores de carga y los orígenes que están detrás de una CDN.

2. ¿Qué se ha emitido para tus dominios? CT recoge todos los certificados que una autoridad de certificación pública ha emitido para tus nombres, incluidos los que nadie en la empresa recuerda haber pedido:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

La salida también muestra qué autoridades de certificación usa realmente tu empresa, que es el punto de partida del inventario que se describe más abajo.

3. ¿Confían tus clientes TLS en las claves comprometidas? Los servidores de prueba de Mozilla presentan certificados emitidos con las claves comprometidas, así que un error de certificado es el resultado bueno. Prueba las dos familias: el primer host encadena a la raíz de eMudhra y el segundo a la de Sectigo, y un mismo almacén de confianza puede fallar en una y superar la otra.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl solo responde por curl. Ejecuta la misma petición a través de la pila TLS propia de cada aplicación, en el entorno donde se ejecuta la aplicación:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Las dos líneas de Python no son redundantes: urllib usa el almacén del sistema operativo y requests usa certifi. Repite cada línea con el host dv-g3b-aaa-emudhra. En Java, haz cualquier llamada HTTPS a los servidores de prueba desde la JVM en cuestión, y lista su almacén para ver si contiene alguna de las dos raíces (Java 9 o posterior; en Java 8 usa -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Que una raíz esté en un almacén no demuestra por sí solo la exposición, porque Go, Node.js, Deno y rustls-webpki de Rust ya bloquean las ocho claves diga lo que diga el almacén. Lo que zanja la cuestión son los servidores de prueba.

4. Parques de equipos Windows. Microsoft no ha publicado nada sobre el incidente, pero la lista de certificados no permitidos que Windows descarga automáticamente bloquea las ocho claves desde el 20 de octubre. Las excepciones son los equipos en los que una directiva de grupo desactiva la actualización automática de certificados raíz y las redes sin ruta hacia Windows Update; a esos hay que hacerles llegar la lista por otra vía. certutil -verifyCTL Disallowed muestra la copia que un equipo tiene en caché. La página del incidente de Mozilla ofrece un script para equipos sueltos y dice que «no se recomienda para dispositivos gestionados por empresas».

5. Certificados de GoDaddy. Comprueba qué certificado presenta realmente cada servidor:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Si el emisor es GoDaddy o Starfield, compara el número de serie con los certificados de tu cuenta de GoDaddy. Donde GoDaddy muestre «Install your new certificate» (instala tu nuevo certificado), el servidor todavía tiene el revocado.

Una regla en todo momento: no hagas desaparecer un error desactivando la verificación de certificados. En palabras de Cloudflare: «Es importante no resolver estos errores desactivando la verificación». Un cliente que no verifica confía en cualquier certificado falsificado, no solo en estos.

Qué actualizar esta semana

Hay dos tipos de corrección. Retirar las dos raíces cierra todas las vías para un cliente que use ese almacén, pero también rompe los certificados válidos que dependen de ellas. Bloquear las ocho claves por el hash de su clave pública, como hacen Go, Node.js, Deno, Electron, rustls-webpki, Composer y Windows, cierra el agujero y no rompe nada más. Donde tu plataforma ofrezca la segunda opción, elígela.

«Aún no» significa que no se había publicado nada a 22 de octubre. Vuelve a comprobarlo antes de hacer planes contando con ello.

Hay cuatro cosas que pillan a los equipos por sorpresa:

• Las imágenes de contenedor conservan la lista antigua. Una imagen construida antes del 20 o el 21 de octubre confía en las claves hasta que se reconstruye sobre una imagen base actualizada, y volver a descargar la misma etiqueta solo sirve cuando ya se ha reconstruido la imagen base. Reconstruye, vuelve a desplegar y pregunta a los proveedores cuyas imágenes ejecutas.
• Los procesos conservan lo que cargaron. Un programa lee su almacén de confianza al arrancar, así que reinicia los servicios de larga duración después de actualizar. Node.js añade que las sesiones TLS reanudadas de antes de la actualización no se vuelven a comprobar.
• Las aplicaciones llevan sus propios ficheros de CA. Los SDK y las aplicaciones suelen incluir un cacert.pem o un ca-bundle.crt propio. Búscalos en repositorios e imágenes, por ejemplo con find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, y cuenta con encontrar más de uno: pip, por ejemplo, lleva su propia copia de certifi.
• Los dispositivos esperan a su fabricante. Pregunta por escrito a cada fabricante qué almacén de confianza usa el producto y cuándo sale la actualización. Hasta que salga, el dispositivo confía en certificados falsificados para todos los servicios a los que llama, así que limita a qué puede acceder.

Si retiras AAA Certificate Services a mano, como hacen Debian, Ubuntu ESM, Fedora y la solución provisional de Red Hat, prueba después las conexiones a servicios con certificados de Sectigo: algunos servidores antiguos todavía envían una cadena que termina en esa raíz.

Qué dejar preparado antes del próximo incidente

Que una autoridad de certificación deje claves tan débiles es raro. Las revocaciones masivas no lo son. Estas son las grandes de 2026 registradas en el sistema de seguimiento de bugs de Mozilla:

Ninguna de estas cinco fue un fallo de seguridad. En todas, un certificado no coincidía con lo que decía el propio documento de la autoridad, y los Baseline Requirements (sección 4.9.1.1) exigen igualmente la revocación en un plazo de cinco días. Cuando una clave está comprometida, o no se puede confiar en la validación de dominio, el plazo es de 24 horas. Nadie puede ampliártelo. En la revocación de 83.267 certificados de DigiCert en 2024, el Chrome Root Program escribió que «no tiene autoridad para conceder excepciones»; un cliente obtuvo una orden judicial para detener la revocación de sus certificados, y la orden se anuló cuatro días después.

Cómo fueron las sustituciones dice mucho. En julio, HARICA usó ACME Renewal Information (ARI) para indicar al software ACME de sus clientes que renovara antes de tiempo, y volvió a emitir otros certificados por su cuenta; en la mayor de sus dos revocaciones, el 87% de los nombres afectados ya se había sustituido cuando llegó el plazo. GoDaddy, cuyos clientes descargan e instalan ellos mismos cada certificado de sustitución, había revocado el 42% de sus certificados afectados al vencer su plazo.

El ciclo de renovación se acorta de todos modos:

• Según la votación SC-081 del CA/Browser Forum, los certificados TLS públicos están limitados a 200 días desde el 15 de marzo de 2026. El límite baja a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029, cuando la validación de dominio solo podrá reutilizarse durante 10 días.
• Let's Encrypt pasa a emitir por defecto certificados de 64 días el 10 de febrero de 2027, y de 45 días un año después.
• Los certificados TLS públicos están perdiendo la autenticación de cliente. Let's Encrypt dejó de incluirla el 8 de julio de 2026, y el Chrome Root Program exige que los certificados emitidos a partir del 15 de marzo de 2027 sean solo para autenticación de servidor. Si usas certificados públicos como certificados de cliente para TLS mutuo, algo habitual en las integraciones de API entre empresas (B2B), esas conexiones necesitan una autoridad de certificación privada.

Con 100 días, y después con 47, instalar certificados a mano deja de ser una opción realista. Una empresa que automatiza pensando en ese calendario también está preparada para la próxima revocación masiva. Lo que hace falta:

1. Conoce lo que tienes, en los dos sentidos. Una lista de todos los certificados que sirves, con nombre de host, emisor, caducidad, método de renovación y responsable. Una segunda lista de todos los almacenes de confianza de los que depende tu software: el paquete del sistema operativo, cada bundle de lenguaje, cada fichero de CA dentro de una aplicación o un dispositivo. La búsqueda en CT de más arriba es el comienzo de la primera lista; una lista de materiales de software (SBOM) o un inventario de dependencias, el de la segunda.
2. Automatiza la emisión y la instalación. ACME allí donde pueda ejecutarse, con ARI (RFC 9773) para que una autoridad de certificación pueda indicar a tus clientes ACME que renueven antes de tiempo. Donde un dispositivo no pueda ejecutar ACME, usa la automatización del fabricante, o termina TLS delante de él en algo que sí pueda.
3. Ten lista una segunda autoridad de certificación. Una cuenta ACME operativa con una segunda autoridad, probada, y registros CAA en el DNS que permitan las dos. Cuando una autoridad pierde la confianza o revoca de forma masiva, pasar a la otra se reduce a un cambio de configuración.
4. Vigila CT para tus dominios. Recibe una alerta por cada certificado nuevo para tus nombres. Así te enteras de una emisión inesperada el mismo día en que se produce.
5. Trata los almacenes de confianza como dependencias. Actualízalos con los parches habituales, y reconstruye las imágenes con una periodicidad fija, no solo cuando cambia el código.
6. Escribe el runbook pensando en los dos relojes. 24 horas y cinco días: quién decide, quién tiene acceso a cada sistema, qué sistemas necesitan pasos manuales, cómo contactar con cada proveedor. Ensáyalo una vez al año cambiando el certificado de un servicio que pueda permitirse un error. Desde 2025, las autoridades de certificación públicas están obligadas a mantener y probar un plan propio de revocación masiva; sus clientes necesitan la otra mitad.

Si desarrollas productos que otros ejecutan

Si tu producto contiene un almacén de confianza (un dispositivo, una aplicación instalada, un SDK), tus clientes solo están protegidos cuando les llega tu actualización. Distribúyela, y di a los clientes qué versiones están corregidas. El consejo de Mozilla a quienes gestionan almacenes de confianza: bloquear las ocho intermedias si su software puede hacerlo y, si no, «valorar si es adecuado retirar la confianza en las raíces que firmaron estas intermedias».

El Reglamento de Ciberresiliencia (Cyber Resilience Act) se aplica aquí de dos maneras. Su obligación de notificación, en vigor desde el 11 de septiembre de 2026, cubre las vulnerabilidades activamente explotadas, y en este caso no se ha notificado ninguna explotación. Sus requisitos esenciales, que se aplican a partir del 11 de diciembre de 2027, incluyen que las vulnerabilidades puedan corregirse mediante actualizaciones de seguridad; un producto cuya lista de confianza no pueda actualizarse no los cumpliría. Los clientes sujetos a la Directiva NIS2 preguntarán a sus proveedores con qué rapidez gestionaron esto, y conviene tener la respuesta por escrito.

Qué sigue abierto

• La raíz restante de eMudhra. Chrome envió doce preguntas a eMudhra el 21 de octubre y no ha anunciado ninguna decisión sobre emSign Root CA - G1. Mozilla no va a retirarla «por el momento».
• La vía de migración de eMudhra. eMudhra dijo a Mozilla que trasladaría a sus clientes a su jerarquía G1 (RSA); su página de estado habla de «una jerarquía de CA alternativa, operada de forma independiente y de confianza pública». Chrome ha preguntado cuál.
• Microsoft y Apple. Ninguna de las dos ha publicado un comunicado ni ha retirado de su almacén ninguna de las dos raíces.
• Correcciones pendientes. Red Hat, Amazon Linux, Temurin y Corretto no habían publicado nada a 22 de octubre; la corrección de Bun estaba integrada, pero no publicada.
• La causa raíz. eMudhra no la ha confirmado, y ha dicho que volverá a verificar todas las ceremonias de claves que ha realizado.
• Sectigo. En un caso aparte, abierto desde el 5 de septiembre, Sectigo se ha negado a revocar certificados cuyo uso extendido de clave no coincidía con una frase de su CPS, alegando que la frase era ambigua. El 18 de octubre contaba unos 72 millones de ellos todavía activos. Algunos participantes en el debate público han pedido que se le retire la confianza; ningún programa de certificados raíz ha anunciado una decisión. Las empresas con certificados de Sectigo deberían seguir el caso.

Dónde conseguir ayuda

Un problema de certificados rara vez se presenta como tal. Aparece como una página de pago que deja de cargar, una integración que deja de sincronizar o un dispositivo que deja de enviar datos, normalmente en fin de semana. Ayudamos a las empresas a pasar semanas como esta sin una caída del servicio, y dejamos las cosas preparadas para que la próxima sea rutina:

• Una revisión de exposición. Localizamos dónde hacen o aceptan conexiones TLS tus sistemas, qué almacén de confianza usa cada uno y qué certificados sirves, incluidos contenedores, servicios Java, integraciones con bancos, proveedores de pago y de logística, y dispositivos.
• Las correcciones. Actualizaciones, imágenes reconstruidas, claves bloqueadas o certificados sustituidos, aplicados a través de tu proceso de cambios y confirmados contra los servidores de prueba de Mozilla.
• Automatización para 2027. ACME con ARI en servidores, balanceadores de carga y appliances, una segunda autoridad de certificación, registros CAA, vigilancia de CT y un runbook, listos para los certificados de 100 días a partir del 15 de marzo de 2027.
• Los sistemas que nadie quiere tocar. Para las aplicaciones Java antiguas, los appliances y los clientes embebidos con sus propios almacenes de confianza está nuestro servicio de mantenimiento de sistemas heredados y de código.

Si no tienes claro si te afecta, escribe a office@c9group.dev con los dominios y las plataformas que usas, o reserva una llamada. Te diremos qué comprobar primero.