Para mandarle comprobantes a SUNAT no te autenticas con el certificado digital: la Clave SOL secundaria que casi nadie crea bien
La llamada llega siempre con la misma frase: «compramos el certificado digital y seguimos sin poder enviar facturas». A veces con una variante peor, que es «en pruebas funcionaba». Las dos tienen la misma causa y no está en el certificado.
Para emitir comprobantes electrónicos desde tu propio sistema hacen falta dos credenciales distintas, que se obtienen en sitios distintos, se guardan en sitios distintos y fallan de maneras distintas. Una firma el documento. La otra abre la puerta. Quien compra solo la primera se queda en la puerta.
Las dos credenciales, y qué hace cada una
El manual del programador del SEE - Del contribuyente, en la versión 2.1 de mayo de 2021, lo deja escrito en sus lineamientos generales del apartado 1.1. El punto 4 dice que el servicio web está protegido con un esquema de seguridad basado en WS-Security. El punto 5, que ese esquema usa el modelo UsernameToken y que «sólo se aceptará las credenciales de la Clave SOL de la SUNAT».
Ahí está todo el asunto. El certificado digital no viaja como credencial de acceso en ningún momento. Viaja dentro del XML, en la firma, y SUNAT lo mira cuando ya te ha dejado entrar.
| Certificado digital | Clave SOL | |
|---|---|---|
| Para qué sirve | firmar el XML del comprobante | autenticar la llamada al servicio web |
| Dónde aparece | dentro de ext:UBLExtensions, en la firma XMLDSig | en la cabecera SOAP, en wsse:UsernameToken |
| Quién lo emite | una entidad de certificación acreditada | la propia SUNAT |
| Qué pasa si falta | el comprobante se rechaza por firma | ni siquiera llega a procesarse |
| Caduca | sí, con fecha en el propio certificado | no, pero la contraseña se puede cambiar |
El apartado 3.2 del mismo manual describe dónde va la firma: en un elemento ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent, uno solo, y firmando el documento completo desde el elemento raíz. Cómo se construye ese bloque y los veintiséis rechazos que produce cuando se construye mal están en dónde va la firma dentro del XML de un comprobante.
El detalle que rompe las integraciones: tiene que ser un usuario secundario
El apartado 2.2 del manual explica cómo se mete la Clave SOL en una cabecera que solo admite dos campos. La Clave SOL tiene tres —RUC, usuario y contraseña—, así que se concatenan RUC y usuario en Username y la contraseña va en Password:
<soapenv:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>20100066603MODDATOS</wsse:Username>
<wsse:Password>moddatos</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
Y después vienen los dos requisitos que deciden si la integración funciona. El primero es que la Clave SOL sea de tipo secundaria. El segundo lo dice el manual con esta frase:
Tener asignado el perfil de "Envío de documentos electrónicos-Grandes emisores"
Los dos son fáciles de saltarse sin enterarse. El primero descarta la credencial con la que el gerente entra a SUNAT Operaciones en Línea: esa es la principal, y el manual no la admite. El segundo obliga a entrar al módulo de gestión de usuarios secundarios y marcar un perfil que no viene marcado por defecto.
Un usuario secundario recién creado, sin ese perfil, se autentica en el portal sin problema. Esa es la trampa: la credencial parece buena porque sirve para entrar a la web. Lo que no sirve es para el servicio web de emisión.
Por qué en pruebas funcionaba
El apartado 2.3 describe el servicio beta y dice una cosa que conviene leer dos veces:
Para el uso de este servicio no es necesario contar con un certificado digital registrado en SUNAT.
Las credenciales del beta son fijas y públicas: usuario [RUC]MODDATOS y contraseña MODDATOS, donde [RUC] es el número de RUC del emisor. Los endpoints viven en e-beta.sunat.gob.pe, separados de los de producción, que están en e-factura.sunat.gob.pe para facturas y resúmenes y en e-guiaremision.sunat.gob.pe para guías.
Resultado: en beta una integración pasa con un certificado autofirmado y con una contraseña que está escrita en un manual público. Todo verde. En producción faltan dos cosas a la vez, el certificado registrado y el usuario secundario con perfil, y el equipo de desarrollo busca el fallo en el código, que es el único sitio donde no está.
Si vas a montar el paso a producción, hazlo con esta lista y en este orden: usuario secundario creado, perfil de envío asignado, certificado registrado, endpoint cambiado. Cambiar solo el endpoint es lo que produce la tarde que todos hemos tenido.
Registrar el certificado también se hace con la Clave SOL
El apartado 3.1 del manual, en su punto b), dice cómo llega el certificado a SUNAT:
El certificado digital deberá previamente ser comunicado a SUNAT. Para ello se utilizará la opción de "Actualización de certificado digital" habilitada en el Menú SOL.
Es decir: la operación que da de alta el certificado se hace dentro del portal, autenticándote con la Clave SOL.
Y la exigencia de tenerlo registrado no vive solo en un manual. La Resolución de Superintendencia 117-2017/SUNAT, de 9 de mayo de 2017, la escribe como condición previa en su párrafo 32.1 para quien se incorpora al Sistema CRE y CPE: hay que tener registrado, o registrar a través de SUNAT Operaciones en Línea, «por lo menos, un certificado digital vigente que será(n) usado(s) para emitir». La misma resolución, en su numeral 1.17, define qué cuenta como firma digital a estos efectos y exige que el certificado que la genera lleve el nombre o razón social y el RUC del titular. La credencial que abre el portal es la que autoriza a declarar cuál es tu certificado. Esa asimetría explica por qué la Clave SOL principal es el activo que hay que proteger: con ella se cambia el certificado registrado, y con ella se crean y se borran los usuarios secundarios.
El mismo apartado 3.1 añade en su punto c) que el certificado «debe encontrarse vigente y no revocado, ya que el receptor de SUNAT valida estos dos requisitos». No es una recomendación: es una comprobación que corre del lado de SUNAT en cada envío. Qué significa exactamente que un certificado esté revocado, y cómo se comprueba eso desde tu propio sistema, está en comprobar que un certificado digital no está revocado.
Los requisitos técnicos del punto a) son los de siempre y uno que sorprende: formato X.509 v3, longitud mínima de clave privada de 1024 bits, identificación del titular con nombre, apellidos y DNI, y el número de RUC consignado en el campo OU del Subject Name. Los 1024 bits son el mínimo que fija ese manual de 2021. Ningún certificado comercial se emite hoy por debajo de 2048, así que el número no es un objetivo: es la constancia de que el documento lleva tiempo sin revisarse en esa línea.
La pregunta que llega después: a quién le doy qué
Cuando el envío lo hace un proveedor, hay que decidir qué se le entrega. Las dos credenciales tienen lecturas distintas.
El certificado contiene la clave privada del titular, y cederla tiene un problema de fondo que el reglamento trata en serio. Está desarrollado en le diste el certificado digital a tu facturador.
La Clave SOL secundaria se puede acotar. Es el motivo por el que el manual la exige secundaria y no principal: un usuario secundario tiene los perfiles que le marques y ninguno más. Si el proveedor solo va a enviar comprobantes, el usuario que le des solo debería llevar ese perfil. Y cuando el contrato termina, ese usuario se desactiva sin tocar nada más.
Una observación que conviene tener presente al revisar una integración ajena: en el modelo UsernameToken del ejemplo, la contraseña viaja en claro dentro del sobre SOAP. Lo que la protege es el transporte, no el mensaje; el propio manual remata el apartado diciendo que se usa SSL sobre HTTPS «con el cual la información que se transfiera desde el servidor del emisor electrónico hacia el servidor de SUNAT, viajará en forma cifrada». La consecuencia práctica es que esa contraseña acaba guardada en algún fichero de configuración del sistema que emite. Merece el mismo cuidado que el certificado, y casi nunca lo recibe.
Qué comprobar hoy, si tienes la duda
Tres comprobaciones rápidas, en orden de coste:
- Mira el
Usernameque usa tu sistema. Si tiene once dígitos y nada más, está mandando el RUC sin usuario y no va a entrar nunca. Tiene que ser RUC y usuario pegados, sin espacio ni separador. - Entra a SUNAT Operaciones en Línea y revisa el usuario secundario. Si el perfil de envío de documentos electrónicos no está marcado, la credencial sirve para el portal y no para el servicio web.
- Mira el endpoint. Si contiene
e-beta, estás en pruebas, y ahí ni el certificado ni la credencial son los de verdad.
Si las tres están bien y sigue fallando, entonces sí toca mirar el certificado: que esté registrado en el Menú SOL, que esté vigente y que lleve el RUC en el campo que SUNAT espera.
Y si todavía no has llegado a ese punto porque estás decidiendo qué certificado comprar, el recorrido entero está en la guía de certificado digital SUNAT para facturación electrónica.
Lo que se reduce a una frase
El certificado digital dice quién firmó. La Clave SOL dice quién envió. SUNAT quiere las dos respuestas y las pide en momentos distintos del mismo envío.
Si estás montando la emisión electrónica y necesitas la parte del certificado —el que sirve para firmar comprobantes, con el RUC en el campo correcto y emitido por una entidad acreditada—, en mifirmadigital.pe lo emitimos con el registro en SUNAT explicado paso a paso.
Última revisión: 15 de septiembre de 2026. Fuentes: manual del programador del SEE - Del contribuyente, versión 2.1 de 12 de mayo de 2021, apartados 1.1, 2.2, 2.3, 3.1 y 3.2, publicado en cpe.sunat.gob.pe.