Certificado digital SUNAT para facturación electrónica: guía de compra y uso

Hay dos formas de descubrir que el certificado que compraste no sirve para facturar. La barata es leer sus campos antes de pagar. La cara es enterarte por un rechazo de SUNAT un lunes por la mañana, con los comprobantes del día sin emitir y un mensaje de error que no dice qué pasó.

Esta guía cubre tres cosas: lo que SUNAT exige de verdad, el certificado gratuito que la propia SUNAT entrega y que casi ningún vendedor menciona, y los siete códigos de rechazo que aparecen cuando el problema está en el certificado.

Antes de comprar nada: puede que no lo necesites

La primera pregunta no es qué certificado comprar, sino si te hace falta. Depende del sistema de emisión que uses, y son cuatro:

Desde el portal de SUNAT (SEE-SOL). Los comprobantes se generan y se firman en el propio portal, con el certificado de SUNAT. El emisor no necesita certificado propio y la emisión no cuesta nada. A cambio, se factura a mano y de uno en uno: sirve para volúmenes bajos, no para un comercio con caja ni para un sistema que emita solo.

Desde tus sistemas (SEE del contribuyente). Tu software genera el XML y lo firma. Aquí sí necesitas certificado propio, y es el caso que cubre el resto de esta guía.

Con el Facturador SUNAT. La aplicación gratuita que SUNAT entrega para instalar en tu equipo. Firma con tu certificado, así que también lo necesitas.

A través de un OSE o un PSE. Un tercero valida o emite por ti. Necesitas certificado propio, y si además te inscribes como operador o proveedor quedas fuera del certificado gratuito, como se ve más abajo.

Si estás en el primer caso y facturas veinte veces al mes, cierra esta página: no tienes que comprar nada.

Lo que exige la norma

El artículo 1 de la Resolución de Superintendencia 097-2012/SUNAT fija los requisitos técnicos del certificado con el que se firma el XML: X.509 versión 3, hash SHA-2 y RSA de 2048 bits. Un certificado emitido con SHA-1, o con una clave RSA de 1024 bits, no pasa.

Son tres datos que están dentro del archivo y se leen en diez segundos, antes de pagar o antes de instalarlo:

openssl x509 -in certificado.cer -noout -text | grep -E "Version:|Signature Algorithm|Public-Key"

La respuesta tiene que parecerse a esto:

        Version: 3 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
                Public-Key: (2048 bit)

Si tienes un .pfx en vez de un .cer, sirve igual:

openssl pkcs12 -in certificado.pfx -nokeys -clcerts | openssl x509 -noout -text | grep -E "Version:|Signature Algorithm|Public-Key"

Hay un cuarto requisito que no está en el artículo 1 y que produce la mitad de los rechazos del primer día: en el sistema de emisión desde los sistemas del contribuyente, el certificado se registra en SUNAT Operaciones en Línea antes del primer envío. Si firmas con uno distinto del registrado, el comprobante se rechaza aunque el certificado sea perfecto.

El certificado que SUNAT te da gratis

Vendemos certificados digitales, así que esto lo escribimos con todas las letras: si solo vas a firmar comprobantes electrónicos y cumples las condiciones de abajo, SUNAT te da uno sin costo y no tienes por qué pagarnos.

Se llama Certificado Digital Tributario (CDT). No lo emite SUNAT: lo emite RENIEC en su calidad de Entidad de Certificación para el Estado Peruano, mientras SUNAT actúa como Entidad de Registro o Verificación y asume el costo de emisión. El marco es el Decreto Legislativo 1370, que incorporó la Cuarta Disposición Complementaria, Transitoria y Final de la Ley 27269, y la Resolución de Superintendencia 038-2020/SUNAT, que regula su emisión y cancelación.

Se solicita desde SUNAT Operaciones en Línea, en Empresa › Comprobantes de Pago › Certificado Digital Tributario, y se descarga por un enlace que llega al buzón electrónico.

Las condiciones que el solicitante declara cumplir, según los términos y condiciones de uso del CDT, son estas:

• Estar afecto al impuesto a la renta de tercera categoría.
• No tener la condición de domicilio fiscal «No Habido».
• No estar en suspensión temporal de actividades ni en baja provisional o definitiva.
• No estar inscrito en el registro de Operadores de Servicios Electrónicos ni en el de Proveedores de Servicios Electrónicos.
• Haber tenido ingresos netos anuales iguales o menores a S/ 1 260 000.
• No tener ya un CDT vigente, ni haber obtenido más de dos.

La vigencia es de 3 años desde la emisión.

Cuándo el CDT no te alcanza

El término sexto de esas condiciones es el que decide la mayoría de los casos. El CDT sirve para firmar comprobantes de pago y otros documentos electrónicos emitidos por el sistema del contribuyente, el Facturador SUNAT y el sistema con OSE. Para nada más. Usarlo con otro fin habilita a SUNAT a pedir su cancelación a RENIEC.

Eso deja fuera cuatro situaciones frecuentes:

Firmar algo que no es un comprobante. Un contrato en PDF, un acta, una carta de renuncia, un expediente que se presenta a una entidad pública. Ahí necesitas un certificado de firma de propósito general, y la diferencia entre firmar con uno u otro no es de comodidad: es quién carga con la prueba si el documento acaba en un juicio.

Superar el límite de ingresos de S/ 1 260 000 anuales.

Estar inscrito como OSE o PSE, que quedan excluidos de forma expresa.

El calendario. La habilitación de SUNAT para operar como Entidad de Registro o Verificación del Estado fue prorrogada por el Congreso hasta el 31 de diciembre de 2027. A partir del 1 de enero de 2028 podrá seguir haciéndolo siempre que complete el procedimiento de acreditación ante INDECOPI. Si tu certificado gratuito vence después de esa fecha, conviene tener el plan B pensado con tiempo, no el día del vencimiento.

Un certificado de firma no es un certificado SSL

Este es el error caro, y se comete con toda la buena fe del mundo. Los dos son X.509, los dos los emite una autoridad de certificación, los dos cuestan parecido y las dos páginas de venta se parecen. No son intercambiables.

La diferencia está en dos extensiones del certificado, Key Usage y Extended Key Usage, que declaran para qué se puede usar la clave privada:

openssl x509 -in certificado.cer -noout -ext keyUsage,extendedKeyUsage

Si en la respuesta aparece TLS Web Server Authentication, tienes un certificado de servidor web. Si el Subject es un nombre de dominio en vez del RUC y la razón social, la confirmación es doble.

SUNAT no te va a decir que compraste el certificado equivocado. Te va a devolver un error de firma genérico, y desde ahí el diagnóstico puede llevarte una tarde entera revisando el XML, que es donde no está el problema. El caso completo, con las comprobaciones para confirmarlo en dos minutos, está en certificado de firma o certificado SSL: por qué SUNAT rechaza tu comprobante.

Los siete rechazos que apuntan al certificado

Cuando SUNAT rechaza un comprobante por algo relacionado con la firma, el código dice bastante más de lo que parece:

Código	Mensaje de SUNAT	Qué pasó en realidad
1059	El XML no contiene firma digital	El nodo ds:Signature no se generó, o quedó fuera del ExtensionContent donde SUNAT lo busca
2325	El certificado usado no es el comunicado a SUNAT	Firmaste con un certificado distinto del registrado en SOL. Típico tras una renovación
2326	El certificado usado se encuentra de baja	El emisor lo dio de baja
2327	El certificado usado no se encuentra vigente	Venció, o aún no empieza su periodo de validez
2328	El certificado usado se encuentra revocado	Se revocó antes de vencer, normalmente por compromiso de la clave privada
2335	El documento electrónico ingresado ha sido alterado	El XML cambió después de firmarse
2336	Ocurrió un error en el proceso de validación de la firma digital	Cajón de sastre: la firma no valida y SUNAT no precisa por qué

Los siete, uno a uno y con la causa real de cada mensaje, están en los 7 errores de SUNAT al firmar un comprobante. Tres de ellos merecen explicación aparte aquí, porque su causa real no es la que sugiere el mensaje.

El 2327 no siempre significa que el certificado venció. Un certificado tiene fecha de inicio y fecha de fin. Si el reloj del servidor que firma está adelantado respecto al del certificado recién emitido, el resultado es el mismo mensaje. Antes de llamar al proveedor, compara date -u en tu servidor con la salida de openssl x509 -noout -dates.

El 2335 casi nunca es una alteración maliciosa. Es la firma de un problema de canonicalización: el XML se firmó, y después algo lo volvió a serializar. Un formateador que indenta la salida, una librería que reordena atributos, un paso de log que reescribe el archivo. El contenido «se ve igual» y el resumen criptográfico ya no coincide. La regla práctica es que firmar sea la última operación sobre el XML antes de comprimirlo y enviarlo.

El 2336 es el que aparece cuando compraste un SSL. También aparece con una cadena de certificación incompleta, cuando el .pfx no incluye el certificado intermedio de la entidad emisora. Merece la pena comprobar la cadena antes de dar por buena cualquier otra hipótesis.

Si ya compraste el equivocado

Pasa, y tiene arreglo desigual según el caso.

Si compraste un certificado SSL creyendo que servía para firmar, no hay conversión posible: son certificados con extensiones distintas emitidas para propósitos distintos, y el emisor no puede reetiquetar uno como el otro. Lo que sí conviene es reclamar dentro del plazo de devolución del proveedor, que suele existir y suele ser corto.

Si compraste un certificado de firma correcto pero a nombre de la persona equivocada, la reemisión con los datos corregidos entra dentro de lo razonable pedir sin costo, porque la validación de identidad ya se hizo. Si el proveedor cobra la emisión entera otra vez, es información útil sobre ese proveedor.

Si el certificado es correcto y el rechazo persiste, antes de comprar otro comprueba las dos causas que no tienen nada que ver con el certificado: que esté registrado en SOL y que la firma sea la última operación sobre el XML.

Qué preguntar antes de pagar

Siete preguntas. Las respuestas se verifican todas, y ninguna requiere confiar en la palabra del vendedor.

1. ¿Está el emisor en el ROPS de INDECOPI? Se comprueba en cinco minutos, y hay un matiz que se presta a confusión: una empresa puede estar acreditada como Entidad de Registro y emitir los certificados otra. Lo explicamos paso a paso en cómo comprobar que un certificado digital está acreditado.
2. ¿Qué archivo me entregan? Para instalar el certificado en un facturador necesitas la clave privada, y eso significa un .pfx o .p12 con su contraseña. Si te entregan solo un .cer, no puedes firmar con él.
3. ¿A nombre de quién sale el Subject? Tiene que llevar el RUC y la razón social del emisor de los comprobantes. Si el certificado sale a nombre del contador, del gerente o del integrador, el problema aparece más tarde y es peor. Qué figura corresponde en cada caso, y por qué un proceso automático necesita otra distinta, está en qué certificado te corresponde.
4. ¿Qué vigencia tiene y qué pasa el día del vencimiento? Pregunta concreta: ¿avisan con antelación, y con cuánta?
5. ¿Responden OCSP y la CRL? Están en las extensiones del certificado y se prueban con curl. Si esas direcciones no responden, ningún validador estricto puede confirmar que el certificado sigue vivo.
6. ¿Incluye el registro del certificado en SOL? Es el paso que más se olvida y el que produce el error 2325.
7. ¿Cuánto cuesta la renovación? No siempre coincide con el precio de la primera compra.

La comprobación de cinco minutos, antes de emitir

1. Verifica versión, algoritmo y longitud de la clave RSA con openssl, como arriba.
2. Confirma que el Issuer corresponde a una entidad de la lista de confianza peruana.
3. Revisa Key Usage y descarta que sea un certificado de servidor.
4. Comprueba que el Subject lleva tu RUC.
5. Registra el certificado en SOL y emite un comprobante de prueba antes del primero real.

El quinto paso es el que separa un susto de una incidencia. Un comprobante de prueba rechazado es información; el primer comprobante real rechazado es un cliente esperando.

Nuestra recomendación, con su razón

Para un emisor con renta de tercera categoría que solo firma comprobantes y está por debajo del límite de ingresos, el CDT gratuito es la opción correcta y no hay mucho más que discutir. Tres años de vigencia y costo cero.

El certificado de pago empieza a compensar en tres casos concretos: cuando firmas documentos que no son comprobantes, cuando quedas fuera de alguna de las condiciones del CDT, y cuando necesitas que alguien conteste el teléfono el día que el certificado vence y las facturas no salen. Ese tercer caso no aparece en ninguna tabla comparativa y es el que más veces nos llaman para resolver.

Si tu caso es el primero, ya sabes qué hacer y no hace falta que nos escribas. Si es alguno de los otros dos, nuestro certificado para facturación electrónica SUNAT cumple los requisitos del artículo 1 y lo emitimos con la infraestructura que operamos nosotros.

Y si estás revisando ahora tu configuración de facturación, aprovecha para confirmar las fechas del Código de Producto SUNAT: se movieron a enero de 2027 y buena parte del sector sigue publicando la fecha derogada.

Fuentes

• Resolución de Superintendencia 097-2012/SUNAT, artículo 1 (PDF).
• Certificado Digital, portal de Comprobantes de Pago Electrónicos de SUNAT.
• Términos y condiciones de uso del Certificado Digital Tributario (PDF), en el marco de la Resolución de Superintendencia 038-2020/SUNAT.
• Prórroga de las funciones de SUNAT como entidad de registro digital hasta diciembre de 2027, Congreso de la República.
• Catálogo de errores de facturación electrónica: códigos y mensajes contrastados en mifact.net y appfact.pe.

Última revisión: 18 de agosto de 2026.