Cifrar no es firmar: el keyUsage de tu certificado digital y por qué el de firma no sirve para cifrar
Imaginemos a Marco, abogado en Trujillo (el caso es inventado). Un cliente le dice: «mándame tu certificado y te envío el expediente cifrado». Marco tiene el .cer de su certificado de firma y se lo pasa. El cliente cifra con él, el programa no protesta y Marco descifra sin problema. Todo funcionó, y sin embargo el certificado no se emitió para eso. En este artículo vemos qué campo del certificado dice para qué sirve su clave pública, qué dice la normativa peruana y qué hace OpenSSL cuando se le pide cifrar con un certificado de solo firma.
Consultamos las fuentes el 24 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, que ya tiene una sección corta sobre este tema; aquí lo desarrollamos con la demostración.
Dos operaciones con el mismo par RSA
Un par RSA sirve en bruto para dos cosas. Con la privada se firma, y cualquiera verifica con la pública que está en el certificado. Con la pública se cifra, y solo el titular descifra con su privada. El pilar explica la primera. La segunda cambia lo que hay que cuidar: quien firma necesita su privada mientras el certificado esté vigente, y quien recibe información cifrada necesita conservar la suya mientras existan mensajes por abrir.
Esa diferencia práctica es una razón para separar los certificados. Si pierdes el de firma, se emite otro. Si pierdes la clave privada con la que te cifraron un archivo, el archivo no se recupera. Es nuestra lectura del problema, no una cita; el reglamento llega a algo parecido, como se ve más abajo.
Lo que escribe el certificado: Key Usage y Extended Key Usage
El certificado X.509 lleva dos extensiones que dicen para qué se puede usar la clave pública. La primera es Key Usage (keyUsage), definida en el apartado 4.2.1.3 del RFC 5280: una lista de bits. Los que importan aquí:
| Bit | Cuándo se activa, según el RFC 5280 |
|---|---|
digitalSignature | Verificar firmas digitales distintas de las de certificados y CRL, como las de autenticación de una entidad, de origen de datos o de integridad. |
nonRepudiation (en ediciones recientes de X.509, contentCommitment) | Verificar firmas que dan un servicio de no repudio: que el firmante no pueda negar después lo que firmó. |
keyEncipherment | Cifrar claves privadas o secretas, es decir, transporte de llaves. El RFC pone de ejemplo una clave pública RSA usada para cifrar una clave simétrica. |
dataEncipherment | Cifrar datos del usuario directamente, sin clave simétrica intermedia. |
keyAgreement | Acuerdo de llaves, por ejemplo con Diffie-Hellman. |
Sobre dataEncipherment el RFC es directo: su uso es «extremely uncommon» y casi todas las aplicaciones usan transporte o acuerdo de llaves para establecer una clave simétrica. Así se cifra en la práctica: el mensaje se cifra con una clave simétrica aleatoria, y esa clave simétrica se cifra con la pública del destinatario, que es el caso de keyEncipherment.
La segunda extensión es Extended Key Usage (extendedKeyUsage, apartado 4.2.1.12), una lista de propósitos con identificador: clientAuth para autenticación de cliente TLS, emailProtection para correo, codeSigning para código ejecutable. Si el certificado lleva las dos extensiones, el RFC dice que se procesan por separado y que «the certificate MUST only be used for a purpose consistent with both extensions».
Una advertencia antes de leer los perfiles de RENIEC: el RFC avisa de que combinar nonRepudiation con otros bits «may have security implications depending on the context», y deja a las políticas de certificación afinar la diferencia entre digitalSignature y nonRepudiation.
Lo que dice la norma peruana
El reglamento: el artículo 11 a)
El artículo 11 del D.S. 052-2008-PCM, «De la invalidez», dice que una firma digital generada bajo la Infraestructura Oficial de Firma Electrónica carece de validez cuando «Es utilizada en fines distintos para los que fue extendido el certificado». El texto que leímos es el publicado el 19 de julio de 2008 en El Peruano.
¿Lo modificó algo después? Leímos cinco decretos que tocaron el reglamento. El D.S. 070-2011-PCM (copia escaneada leída con OCR) modifica el artículo 16 y disposiciones. El D.S. 026-2016-PCM modifica los artículos 6, 26, 59, 61, 64 y 75 y dos disposiciones finales, e incorpora párrafos en los artículos 23, 34 y 45 y el 58-A. El D.S. 029-2021-PCM modifica los artículos 6, 8, 10, 15, 16, 29, 33, 35, 36, 45, 46, 47, 48, 57, 60 y dos disposiciones finales. El D.S. 155-2022-PCM (30 de diciembre de 2022) solo reescribe la octava disposición complementaria final, y el D.S. 082-2024-PCM (6 de agosto de 2024) modifica los artículos 27 y 46. Ninguno toca el artículo 11. No leímos el D.S. 105-2012-PCM ni tenemos un texto consolidado del reglamento. Nuestra lectura: el 11 a) sigue como en 2008, pero no podemos demostrarlo con todas las modificatorias.
Conviene leerlo con cuidado. El artículo habla de «fines distintos para los que fue extendido el certificado», no de bits concretos. Qué cuenta como «fin» lo define cada certificado, y para saberlo hay que mirar el propio certificado y la declaración de prácticas de la entidad.
Lo que dice INDECOPI: dos textos que no coinciden
El anexo 8 de la guía de acreditación de entidades de certificación (revisión 2018) fija, por nivel de seguridad, cuántos certificados debe tener un usuario final. Para el nivel medio, el artículo 10 c) dice que los certificados «deben ser generados de manera individual y separados para las siguientes funciones: cifrado y firma (no repudio) o autenticación», y añade que firma y autenticación «pueden ser realizadas con un mismo certificado». Para el medio alto, el artículo 12 c) pide separar las tres: «cifrado, firma (no repudio) y autenticación».
La tabla de niveles de la guía v4.1 (28 de agosto de 2019) dice otra cosa en el medio alto:
| Nivel | Anexo 8 (rev. 2018) | Tabla de la guía v4.1 |
|---|---|---|
| Medio | Cifrado aparte; firma y autenticación pueden compartir certificado (art. 10 c) | Igual |
| Medio alto | Los tres separados (art. 12 c) | Cifrado aparte; firma y autenticación pueden compartir certificado |
| Alto | No aparece en el anexo 8 | Los tres separados |
Las dos fuentes coinciden en el nivel medio y discrepan en el medio alto: el anexo pide tres certificados y la tabla, dos. No sabemos cuál prevalece ni si INDECOPI lo aclaró en otro documento, y no lo resolvemos aquí. Lo que sí coincide en todos los niveles es que el cifrado va en un certificado propio. Por eso este artículo trata esa separación y no la otra, la de firma frente a autenticación, que tiene su propio artículo.
Hay otra pista en el reglamento, en las obligaciones de la entidad de certificación (artículo 26 d): debe «No almacenar las claves privadas de los usuarios finales a menos que correspondan a certificados cuyo uso se limite al cifrado de datos». El texto es el de 2008 y el D.S. 026-2016-PCM lo reproduce igual al reescribir el artículo. O sea, el reglamento admite que se guarde una copia de la clave de cifrado y no la de la clave de firma. Casa con lo que vimos arriba: perder una clave de cifrado es perder datos. No hemos visto que alguna entidad acreditada ofrezca esa custodia; es lo que el artículo deja abierto, nada más.
Lo que publica RENIEC: un certificado por cada uso
La declaración de prácticas de la ECEP-RENIEC (versión 5.1, 4 de junio de 2026), en su numeral 1.4.1, dice que los certificados de entidad final «podrán ser utilizados únicamente para los propósitos indicados en las extensiones keyUsage (KU) y extendedKeyUsage (EKU)». Su anexo 2, bajo la jerarquía ROOT 3, trae perfiles separados para las tarjetas de la Class 2 (la del DNIe, como cuentan las versiones del DNIe):
| Perfil (anexo 2, ROOT 3) | keyUsage | extendedKeyUsage |
|---|---|---|
| Class 2 AUT hard (autenticación) | digitalSignature | clientAuth, smartcardLogon |
| Class 2 FIR hard (firma) | nonRepudiation | emailProtection |
| Class 2 CIF hard (cifrado) | keyEncipherment, dataEncipherment | emailProtection |
El perfil de cifrado se describe como «Certificado Digital Class 2 de cifrado en hardware». Dos detalles de la tabla. El certificado de firma lleva solo nonRepudiation, sin digitalSignature, y el de autenticación lleva solo digitalSignature. Y el de cifrado marca dataEncipherment además de keyEncipherment, aunque el RFC avise de que ese bit es rarísimo.
Bajo la jerarquía ROOT 5 (anexo 3) los perfiles de Class 2 que encontramos son AUT, FIR y un combinado FAU de firma y autenticación, con digitalSignature y nonRepudiation en el mismo certificado. No encontramos en la Class 2 de ese anexo un perfil de cifrado. En la Class 3, la de trabajadores de entidades públicas, la declaración dice que se emiten certificados «para los propósitos de Firma y Autenticación y para Cifrado», con un perfil CIF de keyEncipherment y dataEncipherment. El patrón se repite: el cifrado va en su certificado, y firma y autenticación pueden compartir uno, que es lo que admite el nivel medio en las dos fuentes de INDECOPI.
¿Y certificados reales públicos? La lista de confianza de INDECOPI (TSL, secuencia 25, copia del 22 de octubre) contiene 74 certificados de servicios y ninguno es de usuario final peruano. Leímos su keyUsage: 47 llevan solo Certificate Sign y CRL Sign, lo esperable en una CA; 15 añaden Digital Signature (uno de ellos es el de un sello de tiempo de una entidad extranjera); 10 no tienen la extensión; y dos son certificados de firma de código ya vencidos, uno con Digital Signature y otro con Digital Signature y Non Repudiation. No hay ahí un certificado de cifrado de una persona, así que la demostración usa certificados de prueba que generamos nosotros.
La demostración con OpenSSL
Generamos una CA de prueba y dos certificados RSA de 2048 bits: uno con keyUsage de firma y otro con keyEncipherment. Todo con OpenSSL 3.5.8, el 24 de octubre de 2026. Así queda el campo:
$ openssl x509 -in firma.pem -noout -subject -ext keyUsage,extendedKeyUsage
subject=C=PE, O=Prueba, CN=Titular Firma
X509v3 Key Usage: critical
Digital Signature, Non Repudiation
X509v3 Extended Key Usage:
E-mail Protection
$ openssl x509 -in cifrado.pem -noout -subject -ext keyUsage,extendedKeyUsage
subject=C=PE, O=Prueba, CN=Titular Cifrado
X509v3 Key Usage: critical
Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
E-mail Protection
Primero, lo que OpenSSL responde cuando se le pregunta por el propósito:
$ openssl x509 -in firma.pem -noout -purpose | grep -i "S/MIME"
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : No
S/MIME encryption CA : No
$ openssl verify -CAfile ca.pem -purpose smimeencrypt firma.pem
error 26 at 0 depth lookup: unsuitable certificate purpose
error firma.pem: verification failed
$ openssl verify -CAfile ca.pem -purpose smimeencrypt cifrado.pem
cifrado.pem: OK
El diagnóstico es el esperado: el certificado de firma no sirve para cifrar y el de cifrado sí. Ahora el intento real de cifrar con el certificado de solo firma:
$ openssl cms -encrypt -aes256 -in mensaje.txt -out cifrado-con-firma.cms -outform PEM firma.pem
(sin mensaje; código de salida 0)
$ openssl cms -decrypt -in cifrado-con-firma.cms -inform PEM -inkey firma.key -recip firma.pem
Mensaje confidencial de prueba
openssl cms -encrypt no comprobó el keyUsage. Cifró sin avisar, y la clave privada del certificado de firma descifró el resultado. Lo mismo pasó con openssl smime -encrypt y con openssl pkeyutl -encrypt sobre la clave pública extraída del certificado de firma (este último ni mira el certificado, solo la clave pública). Es lo que hizo OpenSSL 3.5.8 en estas pruebas. No sabemos si otras versiones o programas, como clientes de correo o visores de PDF, aplican otro criterio, y no los probamos.
La comprobación del uso sí aparece al otro lado. Firmamos con el certificado de cifrado, el que no tiene bit de firma, y verificamos:
$ openssl cms -sign -in mensaje.txt -signer cifrado.pem -inkey cifrado.key -nodetach -out firmado-con-cifrado.cms -outform PEM
(código de salida 0)
$ openssl cms -verify -in firmado-con-cifrado.cms -inform PEM -CAfile ca.pem -out /dev/null
CMS Verification failure
...Verify error: unsuitable certificate purpose
(código de salida 4)
$ openssl cms -verify -in firmado-con-cifrado.cms -inform PEM -CAfile ca.pem -noverify -out /dev/null
CMS Verification successful
Firmar sí se pudo. Con -noverify, que no valida el certificado del firmante, la verificación pasa. Cuando OpenSSL valida el certificado, lo rechaza por propósito inadecuado. Con el certificado de firma, la misma verificación completa dio «CMS Verification successful».
Nuestra lectura de lo que significa: en OpenSSL, la comprobación del keyUsage la hace quien valida, no quien produce. Quien cifra o firma puede hacerlo con cualquier clave privada que tenga a mano; quien recibe y valida decide si el certificado servía para lo que se hizo. Eso encaja con el artículo 11 a), que habla de la validez de la firma y no de que sea imposible producirla: se puede generar una firma con el certificado equivocado, y esa firma no vale. Para el cifrado, el reglamento no dice nada parecido. Lo que dicen los textos de INDECOPI y de RENIEC es que el cifrado va en un certificado aparte.
Cómo ver el keyUsage de tu certificado
Con un .cer o .pem (si falla por formato, añade -inform DER):
openssl x509 -in tu-certificado.cer -noout -ext keyUsage,extendedKeyUsage
openssl x509 -in tu-certificado.cer -noout -purpose
Si lees Non Repudiation o Digital Signature y nada de Key Encipherment, es de firma o de autenticación. Si lees Key Encipherment, es de cifrado. La guía para el resto de los campos está en abre tu certificado y léelo, y si lo que te rechazan es un comprobante de SUNAT, mira antes certificado de firma o SSL. Quién emitió ese certificado y por qué se confía en él lo cuenta el artículo sobre la cadena de confianza.
Lo que sale mal
- Envías tu certificado de firma para que te cifren documentos. La herramienta del otro lado puede aceptarlo (OpenSSL lo hizo), pero no es el uso para el que se emitió. Pide a tu entidad el certificado de cifrado.
- Firmas con el certificado de cifrado. Puedes producir la firma, pero quien valide el certificado la va a rechazar por propósito.
- Esperas un solo certificado para todo. En el DNIe son tres perfiles separados; en el nivel medio bastan dos, uno para cifrar y otro para firmar y autenticar.
- Pierdes el certificado de cifrado y habías cifrado archivos con él. Un certificado nuevo, con otras llaves, no abre lo cifrado con el anterior. Pregunta a tu entidad si guarda copia de esa clave privada; el reglamento lo admite solo para cifrado.
- Lees solo
extendedKeyUsagey concluyes que sirve. Si el certificado tiene las dos extensiones, se aplican las dos a la vez, y basta una incoherente para que no sirva.
Nuestra opinión
Mira el keyUsage antes de dar tu certificado a nadie. Si necesitas recibir información cifrada, pide el certificado de cifrado y no uses el de firma para eso aunque la herramienta lo acepte: que funcione no equivale a que esté permitido, y el reglamento ni siquiera prevé guardar copia de la clave de firma. Si no vas a recibir información cifrada, no necesitas el de cifrado; para firmar documentos y comprobantes basta con el de firma.
Lo que este artículo no afirma
- Que el artículo 11 a) del D.S. 052-2008-PCM siga igual. Leímos los decretos 070-2011, 026-2016, 029-2021, 155-2022 y 082-2024, que no lo tocan, pero no el D.S. 105-2012-PCM ni un texto consolidado.
- Cuál de los dos textos de INDECOPI manda en el nivel medio alto. El anexo 8 y la tabla de la guía v4.1 no coinciden y no lo resolvemos.
- Que cifrar con un certificado de firma sea ilegal. El artículo 11 a) habla de la validez de la firma digital. No encontramos una norma que diga qué consecuencia tiene cifrar con un certificado de firma.
- Que otros programas se comporten como OpenSSL. Probamos OpenSSL 3.5.8, con certificados nuestros, no con una tarjeta ni con el software de una entidad.
- Que las entidades acreditadas custodien claves de cifrado. El reglamento lo admite; no verificamos que alguien lo ofrezca.
- Qué nivel de seguridad tiene un certificado concreto. El
keyUsageno lo dice.
Fuentes
Consultadas el 24 de octubre de 2026. Copias locales en reports/redaccion-diaria/; la salida de los comandos y los scripts están en 2026-10-24-notas/fuentes/mfd-cifrar/.
- D.S. 052-2008-PCM, El Peruano, 19 de julio de 2008, artículos 11 a) y 26 d). Copia:
2026-10-17-notas/fuentes/mfd-ec/ds052_gobpe.txt. - D.S. 026-2016-PCM. Copia:
mfd-cifrar/ds026-2016-lectura.txt. D.S. 070-2011-PCM:mfd-cifrar/ds070-2011-ocr.txt. D.S. 029-2021-PCM, 19 de febrero de 2021:2026-10-17-notas/fuentes/mfd-ec/ds029_elperuano.txt. D.S. 155-2022-PCM:2026-10-24-notas/fuentes/mfd-cadena/ds155/2139650-1.txt. D.S. 082-2024-PCM:2026-10-24-notas/fuentes/mfd-cadena/ds082-2024.raw.txt. - INDECOPI, Guía de Acreditación de EC v. 4.1 y su anexo 8, artículos 10 c) y 12 c). Copias:
2026-10-17-notas/fuentes/mfd-ec/guia-ec.txt,2026-10-22-notas/fuentes/mfd-pilar11/ec-anexo8.txt. - IETF, RFC 5280, mayo de 2008, apartados 4.2.1.3 y 4.2.1.12. Copia:
2026-10-22-notas/fuentes/mfd-pilar11/rfc5280.txt. - RENIEC, Declaración de Prácticas de Certificación ECEP-RENIEC v. 5.1 (4 de junio de 2026), numeral 1.4.1 y anexos 2 y 3. Copia:
2026-10-19-notas/fuentes/mfd-dnie/cps-ecep-v5.1.txt. - INDECOPI, lista de confianza TSL, secuencia 25. Copia:
mfd-cifrar/tsl-pe-22oct.xml; resumen dekeyUsageenmfd-cifrar/tsl-ku-eku.txt. - Demostración (OpenSSL 3.5.8):
mfd-cifrar/demo-cifrar.shymfd-cifrar/demo-cifrar-salida.txt.
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.
Última revisión: 24 de octubre de 2026.