La cadena de confianza de tu certificado digital: de la raíz del Estado peruano a tu certificado, y qué raíces trae cada programa
Imaginemos a Marco, contador en Piura (el caso es inventado, las salidas de abajo son reales). Le llega un documento firmado con un certificado de RENIEC y lo revisa en su laptop con Fedora. OpenSSL le contesta unable to get local issuer certificate. La firma no está rota. Al programa le falta una pieza de la cadena, o no tiene la raíz entre las que trae de fábrica, y las dos cosas dan el mismo mensaje.
En este artículo seguimos la cadena del Estado peruano de arriba abajo, con los certificados reales de la lista de INDECOPI, y después miramos si cuatro programas (Mozilla, Microsoft, Adobe y el almacén de Fedora) traen esas raíces. Consultamos todo el 24 de octubre de 2026. Donde concluimos nosotros, lo decimos con «nuestra lectura». El cuadro general de cómo se firma está en el pilar de esta serie; aquí solo hablamos de la cadena.
Qué hace un programa cuando valida una cadena
El RFC 5280 (mayo de 2008) describe el algoritmo en su sección 6. Empieza por una frase corta: «Valid paths begin with certificates issued by a trust anchor.» Un camino válido arranca en un ancla de confianza, y elegir el ancla es decisión de quien valida: «The selection of a trust anchor is a matter of policy». Esa política es, en la práctica, la lista de raíces que trae el programa o que tú le agregas.
Para cada certificado del camino, el apartado 6.1.3 exige que la firma se verifique con la clave pública del emisor, que el periodo de validez incluya la fecha actual, que no esté revocado y que el nombre del emisor coincida con el esperado. El apartado 6.1.4 añade las reglas de las intermedias: el certificado debe ser de una CA (basicConstraints con cA en verdadero) y respetar el largo máximo de camino. Esto último dice el RFC: «If the certificate was not self-issued, verify that max_path_length is greater than zero and decrement max_path_length by 1.»
Montamos una jerarquía de juguete, inventada, con una raíz de pathlen:2, una intermedia de pathlen:1, una clase de pathlen:0 y un titular. Con la raíz en el almacén y las dos intermedias a mano, valida. Quitando una pieza, o la raíz, falla con el mensaje de Marco. Y si la clase (que no debería emitir otras CA) emite una subclase y esa un titular, el camino se rechaza:
$ openssl verify -CAfile raiz.pem -untrusted nivel2.pem -untrusted clase.pem -untrusted subclase.pem titular2.pem
C=PE, O=PRUEBA, CN=clase
error 25 at 2 depth lookup: path length constraint exceeded
error titular2.pem: verification failed
La revocación se comprueba aparte, con CRL u OCSP; está en cómo comprobar que un certificado no está revocado, y aquí no la repetimos.
La cadena del Estado: ECERNEP, ECEP-RENIEC, clase, titular
La declaración de prácticas de ECEP-RENIEC (versión 5.1, 4 de junio de 2026) describe tres niveles. En su numeral 1.3.2 dice: «Las ECEP son Entidades de Certificación subordinadas a la ECERNEP que han sido acreditadas por la AAC». La ECEP-RENIEC tiene un certificado de nivel 2 que opera sin conexión y certificados de nivel 3, las clases, que operan en línea y emiten a los titulares.
El certificado de nivel 3 de la clase 2 bajo la raíz 5 está publicado en las direcciones que la propia declaración pone en sus perfiles, y la raíz 5 también (en cdn.www.gob.pe). Bajamos los tres y los leímos:
CN=ECERNEP PERU CA ROOT 5 (autofirmado) CA:TRUE, pathlen:2
CN=ECEP-RENIEC CA ROOT 5 emisor: ECERNEP ROOT 5 CA:TRUE, pathlen:1 válido hasta nov 2039
CN=ECEP-RENIEC CA Class 2 emisor: ECEP-RENIEC CA:TRUE, pathlen:0 válido hasta nov 2031
$ openssl verify -show_chain -CAfile raiz5.pem -untrusted ecep5.pem class2.pem
class2.pem: OK
depth=0: ... CN=ECEP-RENIEC CA Class 2 (untrusted)
depth=1: ... CN=ECEP-RENIEC CA ROOT 5 (untrusted)
depth=2: ... CN=ECERNEP PERU CA ROOT 5
Los pathlen bajan de 2 a 0, uno por nivel, y coinciden con el esquema de nivel 2 y nivel 3 de la declaración. No pudimos probar un certificado de titular porque no tenemos uno real a mano; el último eslabón es el que emite la clase 2. El camino de un titular tiene un escalón más.
Quién es la ECERNEP según la norma
El texto original del D.S. 052-2008-PCM (19 de julio de 2008), artículo 46 a), la define como «la encargada de emitir los certificados raíz para las Entidades de Certificación para el Estado Peruano que lo soliciten», y su artículo 48 a) dice que RENIEC «será la única Entidad de Certificación Nacional para el Estado Peruano». Eso cambió. El D.S. 029-2021-PCM (19 de febrero de 2021) designa a la Presidencia del Consejo de Ministros, a través de la Secretaría de Gobierno Digital, y su artículo 46 a) habla ya de «emitir los certificados subordinados». El D.S. 082-2024-PCM (6 de agosto de 2024) reescribe ese artículo 46 a): la ECERNEP «es responsable de gestionar los certificados digitales raíz de la Estructura Jerárquica de Certificación del Estado Peruano, y con ellos emitir los certificados digitales subordinados para todas las Entidades de Certificación para el Estado Peruano».
Hay una condición que conviene saber. La octava disposición complementaria final, tal como la deja el D.S. 155-2022-PCM (30 de diciembre de 2022), dice que la PCM puede prestar servicios como ECERNEP «sin encontrarse acreditada como tal ante la AAC» y fija el plazo «hasta el 31 de diciembre del 2023». La nota al pie de la declaración de RENIEC, de junio de 2026, sigue citando ese decreto. No encontramos en lo que leímos una norma posterior que fije otro plazo y no sabemos con qué amparo opera hoy. No lo damos por resuelto en ningún sentido.
Las raíces que lista INDECOPI
La lista de confianza (TSL) de INDECOPI, secuencia 25, emitida el 10 de agosto de 2026, trae 33 prestadores y 74 servicios. Del Estado hay tres raíces ECERNEP, autofirmadas y con pathlen:2:
| Raíz | Algoritmo y tamaño | Vigencia | Prestador en la lista |
|---|---|---|---|
| ECERNEP PERU CA ROOT 3 | RSA 4096, sha512WithRSAEncryption | ago 2017 a ago 2042 | «Registro Nacional de Identidad» (así escrito) |
| ECERNEP PERU CA ROOT 5 | RSA 4096, sha512WithRSAEncryption | jul 2022 a jul 2047 | Presidencia del Consejo de Ministros |
| ECERNEP PERU CA ROOT 6 | ECDSA P-521, ecdsa-with-SHA512 | sep 2022 a sep 2047 | Presidencia del Consejo de Ministros |
La declaración de RENIEC cubre las raíces 3 y 5, no la 6. Qué emite la 6 no lo sabemos. Bajo la raíz 5 la lista registra además dos autoridades de la ONPE (ECEP-ONPE CA ROOT 5 y ECEP-ONPE-ELECTORAL CA ROOT 5), con pathlen:1 y vigencia hasta agosto de 2038: son subordinadas de otra entidad del Estado, emitidas por la raíz. Además la lista conserva ocho servicios de la jerarquía de RENIEC de 2010: seis vencieron en 2020 y dos llegan a julio de 2030.
Un dato que ayuda a no confiar a ciegas: bajamos la raíz 3 de www.reniec.gob.pe y la raíz 5 de cdn.www.gob.pe, y las huellas SHA-256 coinciden con las de la lista. La raíz 5 empieza E3:3D:6A:09:35:2F en los dos sitios.
Qué raíces trae cada programa
Comparamos por huella SHA-256 los 74 certificados de la TSL contra cada lista, y además buscamos por nombre (ECERNEP, RENIEC, INDECOPI, Perú, país PE, Registro Nacional, Presidencia del Consejo). Probamos la búsqueda con un patrón que sí existe (Camerfirma, Chambers, GlobalSign) y encontró entradas en las cuatro listas.
| Lista (leída el 24 de octubre de 2026) | Certificados | Con nombre o país peruano | De la TSL, aparecen |
|---|---|---|---|
Mozilla: certdata.txt de NSS e informe CCADB | 169 | 0 | 4 |
| Microsoft: informe CCADB | 550 filas (316 incluidas, 205 desactivadas, 29 NotBefore) | 0 | 8 (7 incluidas, 1 desactivada) |
Adobe AATL: tl12.acrobatsecuritysettings | 311 | 0 | 4 |
Fedora: trust list | 396 | 0 | 6 |
Ninguna lista trae las raíces ECERNEP 3, 5 ni 6, ni la ECEP-RENIEC, ni las de la ONPE. Las coincidencias son raíces extranjeras que la TSL registra como servicio de un prestador peruano: GlobalSign, WISeKey, Firmaprofesional, emSign (eMudhra), Comodo, Certicámara y Camerfirma. La de Certicámara figura como Disabled en Microsoft y en Adobe con las marcas de raíz y de documentos certificados en 0.
El caso más claro es el de un prestador peruano privado, Camerfirma Perú. La TSL trae tres certificados de su cadena y OpenSSL los encadena así:
depth=0: C=PE ... O=CAMERFIRMA PERÚ S.A.C., CN=AC CAMERFIRMA PERÚ CERTIFICADOS - 2016
depth=1: C=ES ... CN=AC CAMERFIRMA PERÚ - 2016
depth=2: C=ES ... CN=GLOBAL CHAMBERSIGN ROOT - 2016
La raíz es GLOBAL CHAMBERSIGN ROOT - 2016. Microsoft la tiene como Included (propósitos: autenticación de servidor, de cliente y correo seguro). Adobe la trae en su AATL con la marca de raíz y de documentos certificados en 1. Mozilla no la trae, y el almacén de Fedora tampoco. En Fedora hay cinco entradas de ese emisor («Chambers of Commerce Root», «Chambers of Commerce Root - 2008», «CHAMBERS OF COMMERCE ROOT - 2016», «Global Chambersign Root» y «Global Chambersign Root - 2008»), pero no la «GLOBAL CHAMBERSIGN ROOT - 2016», que es la que encabeza la cadena peruana. Contra el almacén de Fedora esa cadena falla igual que la de RENIEC:
$ openssl verify -untrusted svc032.pem svc034.pem
C=ES, ... CN=AC CAMERFIRMA PERÚ - 2016
error 20 at 1 depth lookup: unable to get local issuer certificate
Nuestra lectura: la respuesta a «qué raíces trae cada programa» no es una, y no coincide con la acreditación peruana. Para varios prestadores privados la TSL registra raíces extranjeras que sí están en algunas listas. La raíz del Estado no está en ninguna de las cuatro, y de las cinco listas que miramos (con la de INDECOPI) solo esta la trae. Que no esté en la lista de un programa no vuelve inválida la firma: significa que ese programa no tiene el ancla de fábrica y hace falta que alguien se la dé, o que lea otra lista.
Dos advertencias sobre lo que medimos. Primero, la lista de Adobe es el archivo de ajustes de seguridad AATL que Adobe publica en trustlist.adobe.com; no sabemos qué más consulta el lector (almacén de Windows, listas de otros países, raíces agregadas a mano). Segundo, Fedora trae más entradas que el informe de Mozilla de hoy, y no investigamos por qué. El almacén de Fedora que leímos se extrajo el 15 de septiembre de 2026 (ca-certificates 2026.2.90).
Si necesitas que tu programa la reconozca
El camino es agregar la raíz tú mismo, y eso es una decisión de confianza: lo que importas pasa a ser ancla. Antes de hacerlo, compara la huella con dos orígenes. Lo que hicimos con la raíz 5:
$ openssl x509 -in cdn_ecernep5.crt -noout -fingerprint -sha256
sha256 Fingerprint=E3:3D:6A:09:35:2F:98:BA:5C:C9:E3:58:D4:4F:3E:D7:37:E8:C7:3F:29:E5:66:56:F9:6A:A0:5A:9D:34:DA:60
La misma huella sale del certificado de la TSL (svc061) y del archivo bajado del sitio del Estado. Para ver qué raíces trae tu Fedora, usa trust list, y filtra por nombre: trust list | grep -i -E 'label: .*(ecernep|reniec)' no devuelve nada hoy. Para ver el certificado que te llegó, la guía está en abre tu certificado y léelo.
La cadena no responde a si la entidad está acreditada. Eso lo responde la lista de INDECOPI, con la comprobación de cómo saber si un certificado está acreditado, y cómo lo hace el validador del Estado está en qué comprueba de verdad. Una cadena impecable ante un visor tampoco vuelve peruana una firma extranjera; eso lo cuenta el artículo sobre certificados extranjeros.
Nuestra opinión
Antes de que tu empresa dependa de un visor para validar firmas, decide con qué lista trabaja y escríbelo. Si tu visor te avisa de una raíz desconocida en una firma de RENIEC, no lo tomes por fraude ni por visto bueno: es el síntoma de arriba. Si vas a importar la raíz, hazlo en una política de la empresa, con la huella comparada contra la TSL, y no en el equipo de quien se queja primero. La acreditación se consulta en la lista de INDECOPI, no en el color del panel de un programa.
Lo que este artículo no afirma
- Que Adobe, Microsoft, Mozilla o Fedora «no reconozcan» una firma peruana. Solo decimos que las raíces ECERNEP no están en las listas que leímos. No probamos qué muestra cada programa con una firma real del Estado.
- Qué hace cada programa fuera de esas listas: almacén del sistema, listas de la Unión Europea u otras que Acrobat u otros lectores puedan consultar.
- Que la raíz 6 emita certificados, ni para quién. La declaración de RENIEC no la cubre y no encontramos otro documento.
- Con qué amparo opera la ECERNEP después del 31 de diciembre de 2023. No buscamos normas posteriores a la de agosto de 2024, y no sabemos si existe otra prórroga.
- Que el texto del D.S. 052-2008-PCM, artículos 46 y 48, siga hoy tal cual. Leímos las modificaciones de 2021, 2022 y 2024, no las que pudieran venir después.
- Qué cadena tiene el certificado de un titular concreto. Leímos los certificados de la jerarquía, no el de una persona.
- Que otro prestador tenga la cadena de Camerfirma Perú: no comprobamos las demás, y los certificados de la lista no son los de los usuarios finales.
Los artículos de esta serie
Esta página es la tercera de cinco que desarrollan el pilar. La primera es la longitud de la clave privada y el algoritmo y la segunda la huella del documento. La cuarta, publicada el mismo día, es cifrar no es firmar, y la quinta, qué pasa cuando un algoritmo deja de servir, sale próximamente.
Fuentes
Consultadas el 24 de octubre de 2026. Copias locales en reports/redaccion-diaria/2026-10-24-notas/fuentes/mfd-cadena/; los comandos y sus salidas están en demo-cadena.sh y demo-cadena-salida.txt, la comparación en comparar-programas.py, comparacion-programas.txt y detalle-coincidencias.txt, y la búsqueda por nombre en buscar-nombres.sh y busqueda-nombres.txt.
- INDECOPI, lista de confianza TSL, secuencia 25, emitida el 10 de agosto de 2026. Copia:
tsl-pe-22oct.xml; certificados extraídos ensvc/. - RENIEC, Declaración de Prácticas de Certificación ECEP-RENIEC v. 5.1, numerales 1.1, 1.3.1 y 1.3.2 y anexos 2 y 3. Copia:
cps-ecep-v5.1.txt. Certificados:reniec-crt/(descargados de las direcciones de los perfiles). - D.S. 052-2008-PCM, El Peruano, 19 de julio de 2008, artículos 46 y 48. Copia:
ds052_gobpe.txt. - D.S. 029-2021-PCM, El Peruano, 19 de febrero de 2021:
ds029_elperuano.txt. D.S. 155-2022-PCM, 30 de diciembre de 2022:ds155/2139650-1.txt. D.S. 082-2024-PCM, El Peruano, 6 de agosto de 2024:ds082-2024.raw.txt. - IETF, RFC 5280, mayo de 2008, sección 6. Copia:
rfc5280.txt. - Mozilla:
certdata.txtde NSS e informe CCADB de raíces incluidas. Microsoft: informe CCADB del programa de raíces. Adobe: lista AATL (el servidor la fecha el 16 de octubre de 2026). Copias enlistas/; Fedora,trust listy los paquetes extraídos,listas/fedora-*.
Si lo que necesitas es un certificado con el que firmar, en mifirmadigital.pe vendemos certificados digitales emitidos dentro de la Infraestructura Oficial de Firma Electrónica, y todo lo que se explica arriba lo puedes comprobar tú mismo sobre el tuyo.
Última revisión: 24 de octubre de 2026.