Certificado de firma o certificado SSL: por qué SUNAT rechaza tu comprobante
Un integrador compra un certificado para el servidor donde va a correr el facturador. Instala, configura, firma el primer comprobante de prueba y SUNAT responde con un error de validación de firma. Revisa el XML tres veces. El XML está bien. El certificado también está bien, técnicamente: es X.509 versión 3, con RSA de 2048 bits, emitido por una autoridad conocida y en vigor.
Lo que no está bien es para qué sirve.
Necesitas dos certificados distintos, y no son intercambiables
Es habitual pensar que en una instalación de facturación electrónica hay un certificado. Suele haber dos, con funciones que no se solapan.
El certificado TLS, que casi todo el mundo sigue llamando SSL, autentica una máquina. Dice «este servidor es de verdad el que dice ser» y cifra el canal. Lo necesitas si expones tu facturador por HTTPS, y el mismo mecanismo protege la conexión contra los servicios web de SUNAT, aunque ahí el certificado que se valida es el de SUNAT, no el tuyo.
El certificado de firma identifica a una persona o a una empresa. Vincula tu RUC y tu razón social con una clave privada, y con esa clave privada se calcula la firma del XML. Es el único que SUNAT acepta dentro del comprobante.
Un servidor y un contribuyente son cosas distintas, así que los certificados que los identifican también lo son.
Dónde está la diferencia, exactamente
En dos extensiones del certificado definidas por el RFC 5280: Key Usage, en el apartado 4.2.1.3, y Extended Key Usage, en el 4.2.1.12. Declaran los usos permitidos, y no son decorativas: los validadores las respetan.
| Certificado TLS/SSL | Certificado de firma | |
|---|---|---|
Subject | Un nombre de dominio (CN=facturas.miempresa.pe) | Nombre o razón social, con el número de RUC |
Key Usage | Firma digital y cifrado de clave simétrica | Firma digital, y no repudio |
Extended Key Usage | TLS Web Server Authentication (OID 1.3.6.1.5.5.7.3.1) | Protección de correo o firma de documentos (1.3.6.1.5.5.7.3.4 y 1.3.6.1.5.5.7.3.36) |
| Dónde vive | En el servidor web | En el equipo o el módulo que firma |
| Quién lo valida | El navegador o el cliente que se conecta | SUNAT, al recibir el XML |
| Vigencia habitual | Meses | Años |
Cómo saber cuál tienes, en treinta segundos
openssl x509 -in certificado.cer -noout -subject -ext keyUsage,extendedKeyUsage
Si en la respuesta aparece TLS Web Server Authentication, o si el Subject es un dominio en vez de tu RUC, tienes un certificado de servidor y no vas a poder facturar con él.
Con un .pfx, el rodeo es de una línea más:
openssl pkcs12 -in certificado.pfx -nokeys -clcerts | openssl x509 -noout -subject -ext keyUsage,extendedKeyUsage
Merece la pena hacerlo antes de pagar, con el certificado de muestra que cualquier emisor serio entrega sin problema.
Por qué la confusión es tan frecuente
No es descuido de quien compra. Hay cuatro razones que empujan al error, y ninguna es evidente desde fuera.
Los dos formatos son idénticos. Los dos son X.509 versión 3, los dos se entregan como .cer o .pfx, y los dos se abren con las mismas herramientas.
El nombre comercial es el mismo. «Certificado digital» sirve para vender los dos productos, y varias empresas del mercado peruano venden ambos desde la misma página.
El precio se parece. Un certificado de firma de un año y un TLS de un año cuestan cifras del mismo orden, así que el importe no avisa de nada.
Y el emisor puede ser el mismo. Una autoridad de certificación acreditada puede emitir los dos. Que el emisor esté en el registro de INDECOPI no dice nada sobre para qué sirve el certificado que te vendió, y esas son dos comprobaciones separadas: una es la acreditación del emisor y otra el uso declarado en el certificado.
Lo que SUNAT te va a responder
Nada parecido a «este certificado no sirve para firmar». Los mensajes son estos:
- 2336, «Ocurrió un error en el proceso de validación de la firma digital». El más habitual.
- 1059, «El XML no contiene firma digital», si la librería de firma rechazó el certificado antes de insertar el nodo.
Ninguno apunta al certificado equivocado, y ahí se pierden las tardes: el diagnóstico se va al XML, que es donde no está el problema. La comprobación de Extended Key Usage descarta esta causa en medio minuto y conviene hacerla al principio, no al final.
Si ya compraste el que no era
No hay conversión posible. Son certificados emitidos para propósitos distintos, con extensiones distintas firmadas por la autoridad emisora, y esa firma es justamente lo que impide reetiquetar uno como el otro. Cambiar el uso exige emitir uno nuevo.
Lo que sí puedes hacer es reclamar dentro del plazo de devolución del proveedor, que suele existir y suele ser corto. Y si el certificado es de firma pero salió a nombre equivocado, la reemisión con los datos corregidos es razonable pedirla sin costo, porque la validación de identidad ya se hizo.
El caso inverso también ocurre, aunque se detecta antes: instalar el certificado de firma en el servidor web. El navegador avisa de inmediato con un error de nombre, porque el Subject lleva un RUC y no el dominio.
Antes de pagar
Tres preguntas al vendedor, y las tres se verifican después con openssl:
- ¿Qué lleva el
Extended Key Usagedel certificado que me van a emitir? - ¿El
Subjectva a llevar mi RUC y mi razón social? - ¿Me entregan un
.pfxcon la clave privada, o solo el certificado público?
Si las respuestas son firma de documentos, sí y .pfx, sirve para facturar. El resto de la decisión —vigencia, soporte, renovación, y si te hace falta comprar algo— está en la guía del certificado digital para facturación electrónica SUNAT, que incluye el caso de quien no necesita comprar ninguno.
Fuentes
- RFC 5280, perfil de certificados X.509:
Key Usage(4.2.1.3) yExtended Key Usage(4.2.1.12). - RFC 9336, uso extendido de firma de documentos.
- Resolución de Superintendencia 097-2012/SUNAT, artículo 1.
- Catálogo de errores de facturación electrónica, códigos 1059 y 2336, contrastados en mifact.net y appfact.pe.
Última revisión: 20 de agosto de 2026.