La longitud de la clave privada y el algoritmo de tu certificado digital: qué exige INDECOPI y cómo ves el tuyo
Imaginemos a Lucía, contadora en Arequipa (el caso es inventado). Un cliente le pregunta si su certificado «es de 1024 o de 2048». Ella busca y encuentra las dos cifras en documentos de INDECOPI, las dos en un texto oficial, y ninguna respuesta. Es un tropiezo habitual: las cifras de la normativa salen de documentos distintos y de años distintos, y ninguno dice qué algoritmo debes tener.
En este artículo ponemos cada cifra con su documento, mostramos lo que declara RENIEC y leemos el campo en certificados reales con OpenSSL. Consultamos las fuentes el 23 de octubre de 2026. Cuando la norma calla y concluimos algo nosotros, lo marcamos como «nuestra lectura». El cuadro general de cómo se firma está en el pilar de esta serie; aquí solo hablamos de dos campos del certificado.
Dos campos, dos preguntas distintas
Un certificado X.509 lleva dos datos que se confunden. La clave pública del titular tiene una longitud (por ejemplo, 2048 bits en RSA). Y el certificado lleva la firma de la entidad que lo emitió, hecha con un algoritmo (por ejemplo, sha256WithRSAEncryption). El primero describe la clave pública del titular; el segundo, cómo firmó la entidad. En la salida de OpenSSL aparecen como Public-Key y Signature Algorithm. El hash en sí (SHA-1 o SHA-256) es el tema del siguiente artículo de la serie y aquí no lo desarrollamos.
Lo que dice cada texto de INDECOPI
La guía de acreditación de entidades de certificación (EC) tiene su versión 4.1 fechada el 28 de agosto de 2019 (la 4.0 es del 21 de enero de 2019). Su tabla de niveles dice, en los tres, que la longitud mínima es de 2048 bits, con renovación máxima cada tres años en el nivel medio, cada dos en el medio alto y anual en el alto. El literal es:
«La longitud de clave privada mínima debe ser de 2048 bits y el certificado debe ser renovado como máximo cada tres (3) años.»
Esa frase aparece igual en el artículo 10 b) del anexo 8 de la misma guía (nivel medio, revisión 2018). El artículo 12 b) del anexo 8, para el medio alto, dice 2048 bits y renovación «cada dos (2) años».
La cifra de 1024 viene de otro documento: el anexo 7, que es el reglamento específico de las entidades de registro (ER), con revisión «03/23-02-2007». Su artículo 9 b), para el nivel medio, dice:
«La longitud de clave privada mínima debe ser de 1024 bits y el certificado debe ser renovado como máximo anualmente.»
El artículo 11 b) del mismo anexo, medio alto, ya dice 2048. Nuestra lectura: el 1024 es una cifra de 2007 que quedó en un anexo; la guía de ER (versión 4.0) lleva en su propia tabla 2048 para el nivel medio, así que dentro del mismo paquete los textos no coinciden. El piso vigente para el usuario final, según la guía de EC, es 2048.
Del algoritmo, la guía dice poco. Pide, en su apartado de ingeniería criptográfica, «algoritmos criptográficos de reconocimiento internacional de tamaño y seguridad criptográfica suficiente», y que las claves criptográficas y los algoritmos sean seguros «durante el tiempo de duración del certificado». No nombra ningún algoritmo ni ninguna función hash. Buscamos SHA, RSA, MD5, DSA y ECDSA en la guía y en los anexos 1, 5, 7 y 8 y no hay exigencia por nombre; solo aparece la sigla SHA en la lista de acrónimos de la guía.
Hay una pista más, en el reglamento. El D.S. 052-2008-PCM (19 de julio de 2008), artículo 48 c) en su texto original, manda a la Entidad de Certificación Nacional para el Estado Peruano y a las entidades para el Estado a observar los lineamientos de la autoridad administrativa «en relación al grado de seguridad adecuado en la selección del algoritmo, en la longitud de la clave, en el medio de almacenamiento de la clave privada». O sea, el reglamento remite la decisión a lineamientos de INDECOPI, no la fija. Aplica a las entidades del Estado, no a toda la IOFE. El D.S. 029-2021-PCM (19 de febrero de 2021) modificó el artículo 48 y su texto muestra «(…)» donde estaba ese literal c). Nuestra lectura: no lo tocó, pero no revisamos las normas posteriores a ese artículo y no lo damos por vigente con certeza.
Lo que declara RENIEC, y una raíz que no está en el documento
La declaración de prácticas de ECEP-RENIEC (versión 5.1, 2026) dice en su apartado 1.1 que opera «bajo el nivel de seguridad establecido como “medio” en la Guía de Acreditación de Entidades de Certificación EC». Su numeral 6.1.5, tabla 8, fija:
| Nivel | Algoritmo de firma | Tamaño de llaves RSA |
|---|---|---|
| ECEP-RENIEC offline | sha512WithRSAEncryption | 4096 bits |
| ECEP-RENIEC online | sha512WithRSAEncryption | 4096 bits |
| Entidades finales | sha256WithRSAEncryption | 2048 bits |
El perfil de certificado de la tarjeta, por ejemplo «Class 2 AUT hard», pone la misma pareja en campos separados: firma Sha256WithRSAEncryption, clave RSA de 2048 bits y vigencia de 4 años. Además, la entidad rechaza la solicitud «Si la longitud de la llave es menor a 2048 bits.» El numeral 6.1.6 dice que se verifica la llave pública del CSR: 2048 bits, RSA.
Dos cosas que conviene saber. La primera: la declaración cubre las jerarquías «ECERNEP PERU CA ROOT 3» y «ROOT 5». En la lista de confianza de INDECOPI (secuencia 25, copia del 22 de octubre) hay un certificado llamado «ECERNEP PERU CA ROOT 6», y ese no es RSA. Abajo está la salida. Esa raíz no aparece mencionada en la declaración que leímos y no sabemos qué emite.
La segunda: los 4 años de vigencia de los perfiles de la tarjeta se leen al lado de la frase de la guía que liga 2048 bits a una renovación máxima de tres años en el nivel medio. No sabemos cómo concilia INDECOPI esos dos números, ni si «renovado» tiene aquí otro sentido, y no afirmamos que haya incumplimiento. Lo dejamos anotado porque quien lea las dos fuentes por separado verá la diferencia.
Cómo ver el tuyo
Con OpenSSL (3.5.8, 23 de octubre de 2026) hace falta un archivo .cer o .pem. Si abre con error, prueba la opción -inform DER, que es el formato binario habitual de los .cer. Para el ejemplo usamos certificados reales de la lista de INDECOPI (los archivos svcNNN.pem de abajo son los extraídos de ella), que no son de usuario final pero muestran los mismos campos: convertimos uno a DER y lo leímos.
$ openssl x509 -inform DER -in firma-profesional.cer -noout -text | grep -E "Signature Algorithm|Public-Key"
Signature Algorithm: sha256WithRSAEncryption
Public-Key: (2048 bit)
Signature Algorithm: sha256WithRSAEncryption
Signature Algorithm sale dos veces: la primera dentro del cuerpo del certificado y la segunda al final, con la firma. Deben coincidir. La longitud se puede leer también desde la clave pública sola:
$ openssl x509 -in svc026.pem -noout -pubkey | openssl pkey -pubin -noout -text | head -1
Public-Key: (2048 bit)
La raíz 5 de RENIEC, la que menciona su declaración, sale así:
$ openssl x509 -in svc061.pem -noout -subject -dates
subject=C=PE, O=Entidad de Certificación Nacional para el Estado Peruano, CN=ECERNEP PERU CA ROOT 5
notBefore=Jul 7 19:47:47 2022 GMT
notAfter=Jul 1 19:47:46 2047 GMT
Signature Algorithm: sha512WithRSAEncryption
Public-Key: (4096 bit)
Coincide con lo que dice la tabla 8 para las raíces: sha512WithRSAEncryption, 4096 bits. La raíz 6 no es igual:
$ openssl x509 -in svc060.pem -noout -text | grep -E "Signature Algorithm|Public-Key|ASN1 OID|NIST CURVE"
Signature Algorithm: ecdsa-with-SHA512
Public-Key: (521 bit)
ASN1 OID: secp521r1
NIST CURVE: P-521
Es una clave pública de curva elíptica, y sus 521 bits no se comparan con los de RSA: es otra familia de algoritmos. Si tu certificado muestra id-ecPublicKey o una curva, la regla de «2048» no se aplica tal cual y hay que preguntar a tu entidad qué política sigue.
Para ver cómo sale una solicitud de certificado (CSR) antes de enviarla, generamos dos claves privadas de prueba:
$ openssl req -in c1024.csr -noout -text | grep -E 'Public-Key|Signature Algorithm'
Public-Key: (1024 bit)
Signature Algorithm: sha256WithRSAEncryption
$ openssl req -in c2048.csr -noout -text | grep -E 'Public-Key|Signature Algorithm'
Public-Key: (2048 bit)
Signature Algorithm: sha256WithRSAEncryption
El campo Public-Key es el que RENIEC dice comprobar. Nótese que los dos CSR están firmados con SHA-256; la longitud y el hash se eligen por separado. La guía para leer los demás campos está en abre tu certificado y léelo.
Qué hay en la lista de confianza
El archivo de la lista (TSL) de INDECOPI, secuencia 25, emitida el 10 de agosto de 2026, trae certificados de los servicios de cada prestador. Extrajimos los 74 y leímos su algoritmo y su longitud. No son certificados de usuario: son los de entidades, raíces e intermedias, algunas extranjeras. Con esa salvedad:
| Clave pública | Cantidad |
|---|---|
| RSA 4096 | 43 |
| RSA 2048 | 26 |
| RSA 1024 | 3 |
| RSA 2047 | 1 |
| ECDSA P-521 | 1 |
De ellos, 56 están vigentes al 23 de octubre de 2026 y 18 vencidos. Los cuatro con menos de 2048 bits están vencidos: los tres de 1024 vencieron en 2013 y 2019, y el de 2047 en diciembre de 2023. Por algoritmo de firma hay 42 con sha256WithRSAEncryption, 19 con sha1WithRSAEncryption, 8 con sha512WithRSAEncryption, 4 con sha384WithRSAEncryption y 1 con ecdsa-with-SHA512. Los 19 con SHA-1 son 13 vencidos y 6 vigentes, y los 6 vigentes están firmados por ellos mismos (raíces autofirmadas). Qué significa eso para la validación es una pregunta de hash y la dejamos al artículo siguiente.
El 2047 merece una línea porque es fácil de pasar por alto:
$ openssl x509 -in svc035.pem -noout -text | grep -E "Signature Algorithm|Public-Key"
Signature Algorithm: sha1WithRSAEncryption
Public-Key: (2047 bit)
OpenSSL cuenta los bits reales del módulo. Un módulo que no llena el último bit sale como 2047, y entonces el número no alcanza el «2048» de la guía. Este es un certificado de Camerfirma ya vencido y no sabemos con qué nivel de seguridad se acreditó. Si el tuyo muestra 2047, pregunta por escrito a tu entidad.
Y SUNAT
Para firmar comprobantes importa lo que pida SUNAT, y no coincide con la guía. El manual del programador del SEE (versión 2.1, mayo de 2021), apartado 3.1 a), pide estas condiciones al certificado:
«Longitud mínima de clave privada de 1024 bits»
La Resolución de Superintendencia 097-2012/SUNAT define en su artículo 2 la firma digital a efectos del sistema y exige que el certificado tenga, literalmente, «Tener, por lo menos, un nivel de seguridad medio.» Nuestra lectura: un certificado de 1024 bits no cumple el nivel medio de la guía vigente, por mucho que el manual de SUNAT acepte esa cifra. Para elegir, vale la más alta de las dos. Qué hash acepta SUNAT en el XML está en el artículo siguiente.
Lo que sale mal
- Un anexo dice 1024 y alguien te lo cita para vender un certificado de 1024. El anexo 7 es de entidades de registro y de 2007; la tabla de la guía vigente dice 2048 en los tres niveles.
- Lees
Public-Key: (2047 bit). No llega a la cifra literal de 2048 de la guía. - Pasas un
.cera OpenSSL y falla por formato. Usa-inform DER. - Tu certificado es de curva elíptica y la regla del 2048 no se aplica sin más. Pide la declaración de prácticas.
Nuestra opinión
Antes de pagar, pídele a tu entidad el numeral de su declaración de prácticas donde consta el tamaño de las llaves y compara con la tabla de la guía v4.1, no con un anexo. Si la entidad te contesta con «1024» o te manda a un anexo, desconfía. Y cuando recibas el certificado, ejecuta el comando de arriba: tarda diez segundos y evita discutir después con quien lo valide. La guía exige 2048 como piso, y tu entidad puede ofrecer más; una longitud mayor no la pide INDECOPI ni hace falta para cumplir.
Lo que este artículo no afirma
- Cuándo deja de ser segura una longitud. No encontramos plazo ni regla de transición de INDECOPI y no citamos estimaciones externas. Que 2048 sea el piso de la guía no significa que sea suficiente.
- Que otras entidades acreditadas hagan lo que RENIEC. Solo leímos la declaración de ECEP-RENIEC, y la TSL muestra certificados de servicio, no los de usuario final.
- Qué emite la raíz 6 de ECERNEP, ni si la declaración de prácticas la cubre en otra versión.
- Cómo concilia INDECOPI los 4 años de los perfiles con los 3 de la guía.
- Que la Resolución 097-2012/SUNAT fije 2048 bits o SHA-2. La leímos entera (copia escaneada, OCR) y no encontramos esas cifras; sí el nivel medio. Otros textos nuestros lo atribuyen a su artículo 1 y hay que revisarlos.
- Que el artículo 48 c) del D.S. 052-2008-PCM siga vigente tal cual. Leímos la modificación de 2021, no las posteriores.
- Qué nivel de seguridad tiene acreditado cada entidad, que la TSL no muestra.
Los artículos de esta serie
Esta página es la primera de cinco que desarrollan las piezas del pilar. El pilar, enlazado arriba, ya está publicado y la huella o hash es el siguiente. Después vendrán la cadena de confianza, el uso del certificado y qué pasa cuando un algoritmo deja de servir (próximamente).
Fuentes
Consultadas el 23 de octubre de 2026 (las normas de INDECOPI y RENIEC, del 17 al 22). Copias locales en reports/redaccion-diaria/; las citas literales con su línea están en citas-literales.txt, dentro de la subcarpeta de este artículo en 2026-10-23-notas/fuentes/.
- INDECOPI, Guía de Acreditación de EC v. 4.1 (28 de agosto de 2019) y su anexo 8. Copias:
2026-10-17-notas/fuentes/mfd-ec/guia-ec.txt,2026-10-22-notas/fuentes/mfd-pilar11/ec-anexo8.txt. - INDECOPI, Guía de Acreditación de ER v. 4.0 y su anexo 7. Copias:
mfd-ec/guia-er-v4.txt,mfd-ec/anexo7.txt. - D.S. 052-2008-PCM, El Peruano, 19 de julio de 2008, artículo 48. Copia:
mfd-ec/ds052_gobpe.txt. D.S. 029-2021-PCM, 19 de febrero de 2021:mfd-ec/ds029_elperuano.txt. - RENIEC, Declaración de Prácticas de Certificación ECEP-RENIEC v. 5.1 (4 de junio de 2026), numerales 1.1, 6.1.5, 6.1.6 y perfiles de la clase 2. Copia:
2026-10-19-notas/fuentes/mfd-dnie/cps-ecep-v5.1.txt. - INDECOPI, lista de confianza TSL, secuencia 25. Copia del 22 de octubre:
2026-10-22-notas/fuentes/mfd-pilar11/tsl-pe-22oct.xml. Extracción y conteo (subcarpeta de este artículo):extraer-tsl.py,resumen-tsl.sh,tsl-servicios-algoritmos.txt. - SUNAT, Resolución de Superintendencia 097-2012/SUNAT, 2012. Copia escaneada leída con OCR:
rs097-2012-ocr.txt, misma subcarpeta. - SUNAT, manual del programador del SEE, versión 2.1 (mayo de 2021), apartado 3.1. Copia:
2026-10-23-notas/fuentes/mfd-hash/manual_programador.txt. - Salida de los comandos (OpenSSL 3.5.8, 23 de octubre de 2026):
demo-longitud.shydemo-longitud-salida.txt, misma subcarpeta.
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: 23 de octubre de 2026.