Le diste el certificado digital a tu facturador: lo que el reglamento dice sobre quién puede tener tu clave privada
El alta en cualquier servicio de facturación electrónica termina en la misma pantalla. Un formulario con dos campos: «sube tu certificado digital» y «contraseña del certificado». Arrastras el archivo, escribes la contraseña, le das a guardar y ya puedes emitir. Toda la industria peruana funciona así y casi nadie se detiene a mirar qué acaba de pasar.
Lo que acaba de pasar es que la clave privada con la que se firma en tu nombre está ahora en un servidor que no administras, protegida por una contraseña que también le diste.
El archivo no es «el certificado»
Un .pfx o .p12 es un contenedor PKCS#12. Dentro van dos cosas distintas: el certificado, que es público y se reparte con cada comprobante que emites, y la clave privada, que es lo que hace la firma. Sin la clave privada el certificado no sirve para firmar nada; con ella, quien la tenga firma igual que tú. La contraseña del archivo protege la clave privada dentro del contenedor, así que entregar las dos cosas juntas equivale a entregar la capacidad de firmar. Si nunca has abierto el tuyo, en este artículo se explica cómo leer sus campos con openssl.
Esa distinción no es una sutileza técnica. Es la que usa el reglamento para repartir responsabilidades.
Lo que dice el reglamento, con artículo
El D.S. 052-2008-PCM, reglamento de la Ley 27269 publicado en El Peruano el 19 de julio de 2008, dedica su artículo 10 a las obligaciones del suscriptor, que es la persona natural responsable de la generación y del uso de la clave privada. Dos de las cinco vienen al caso:
b) Generar la clave privada y firmar digitalmente mediante los procedimientos señalados por la Entidad de Certificación.
c) Mantener el control y la reserva de la clave privada bajo su responsabilidad.
Y la quinta cierra el círculo: si la clave privada «quede comprometida en su seguridad», el suscriptor debe notificarlo de inmediato a la Entidad de Registro o Verificación, o a la Entidad de Certificación que emitió el certificado, «para que proceda a la cancelación del certificado digital». El artículo 15, que enumera las obligaciones del titular, repite la misma idea y añade tres palabras que conviene leer despacio: solicitar la cancelación en caso de que la reserva se haya visto comprometida, «bajo responsabilidad».
El artículo 9 explica por qué esas tres palabras importan. Dentro de la Infraestructura Oficial de Firma Electrónica, «la responsabilidad sobre los efectos jurídicos generados por la utilización de una firma digital corresponde al titular del certificado». No al que la ejecutó materialmente. Al titular. Si tu proveedor firma algo con tu certificado, el efecto jurídico se te imputa a ti y la discusión posterior con el proveedor es un asunto contractual privado que no borra la firma.
El único caso en que la norma admite que otro gestione la clave privada
El artículo 8 establece tres presunciones para los documentos firmados con certificados generados dentro de la Infraestructura Oficial. La primera, en su redacción vigente, dice esto:
a) Que el suscriptor del certificado digital tiene el control de la clave privada asociada, con un elevado grado de confianza, incluso cuando la misma es gestionada por un Prestador de Servicios de Valor Añadido acreditado en la modalidad de sistema de creación de firma remota.
La versión de 2008 no decía eso. Decía «control exclusivo de la clave privada», a secas. La frase larga la introdujo la Segunda Disposición Complementaria Modificatoria del reglamento aprobado por el D.S. 029-2021-PCM, publicado el 19 de febrero de 2021, y su motivo es evidente en cuanto se compara: con la clave privada dentro del módulo criptográfico de un proveedor, el «control exclusivo» de 2008 habría dejado la firma remota fuera de la presunción.
Aquí está lo que casi nunca se dice. Al reescribir ese literal, la norma tuvo que nombrar el supuesto en que otro gestiona la clave privada, y nombró uno solo: un Prestador de Servicios de Valor Añadido acreditado y en la modalidad de sistema de creación de firma remota. Ese es el caso previsto. Un servicio de facturación que guarda tu .pfx en su base de datos y lo carga en memoria para firmar no está en esa lista, salvo que además esté acreditado como tal ante INDECOPI, que es una condición comprobable y que casi ningún facturador reclama. Qué exige esa acreditación está en este otro artículo.
De ahí no se sigue que tus comprobantes sean inválidos. Se sigue algo más incómodo y más concreto: la presunción del artículo 8 a) está escrita sobre el supuesto de que la clave privada la controlas tú o la gestiona un acreditado, y tú has salido de los dos. Si algún día tienes que discutir la autoría de un documento firmado con ese certificado, el terreno en el que discutes no es el mismo.
Un segundo artículo que se pasa por alto: el 11
El artículo 11 declara que una firma digital generada bajo la Infraestructura Oficial carece de validez, además de por los supuestos civiles, cuando «es utilizada en fines distintos para los que fue extendido el certificado».
Eso tiene una aplicación inmediata en este país, y es el certificado digital tributario que SUNAT entrega gratis al amparo de la Resolución de Superintendencia 038-2020/SUNAT, vigente desde el 12 de febrero de 2020. La propia SUNAT dice en su página de certificado digital que debe usarse «exclusivamente para generar la firma digital en los comprobantes de pagos electrónicos». Firmar con él un contrato, un acta o un anexo de un expediente no es una infracción tributaria: es una firma que el artículo 11 deja sin validez. Y cuando el archivo vive en el panel de un tercero, quién lo usa y para qué deja de estar bajo tu vista. Las condiciones de ese certificado gratuito, con sus requisitos y su fecha de caducidad, están detalladas aquí.
Lo que SUNAT valida es otra cosa, y conviene no confundirlas
Quien defiende la práctica suele responder que SUNAT acepta los comprobantes sin problema. Es verdad, y no dice lo que parece decir.
Las reglas de validación de comprobantes de pago electrónicos, en su versión actualizada al 26 de agosto de 2026, tienen una hoja dedicada a la firma. Ahí, el error 2078 valida el campo cac:Signature/cac:SignatoryParty/cac:PartyIdentification/cbc:ID con esta condición: debe ser igual al RUC del emisor o al RUC de quien envía el comprobante. La propia validación de SUNAT contempla que quien firma y envía sea un tercero, y lo da por bueno.
Al lado, el error 2325 dice «El certificado usado no es el comunicado a SUNAT». Ese sí obliga a que el certificado esté registrado previamente, y es el motivo por el que cambiar de certificado sin avisar tumba la emisión de un día entero. Los demás rechazos de esta familia, del 2326 al 2328 y el 2335, están explicados uno a uno.
Son dos planos que no se tocan. SUNAT comprueba que el comprobante llegue firmado con un certificado que conoce y que el emisor esté identificado. El reglamento de firmas regula quién puede tener la clave privada y qué pasa cuando se pierde la reserva. Que el primero te acepte el XML no resuelve nada del segundo.
La salida que la norma sí prevé
El mismo artículo 9 la escribe, al final: tratándose de certificados digitales solicitados por personas jurídicas «para su utilización a través de agentes automatizados, las facultades de titular y suscriptor de dicho certificado corresponderán a la persona jurídica, quien asumirá la responsabilidad por el uso de dicho certificado digital».
Un certificado de agente automatizado está pensado exactamente para esto: un sistema que firma sin que haya una persona apretando el botón cada vez. No hay una persona natural suscriptora cuya obligación de reserva estés incumpliendo, porque las facultades las asume la empresa. Sigue habiendo un archivo que proteger y un proveedor al que exigirle cómo lo guarda, pero el reparto de responsabilidades deja de ser confuso. La diferencia entre los tres tipos de certificado y a quién le toca cada uno está en este artículo, y el reparto entre titular y suscriptor en una empresa, en este otro.
Las cuatro preguntas que valen para cualquier proveedor
Ninguna es teórica. Las cuatro tienen respuesta comprobable y las cuatro se pueden meter en un contrato:
- ¿Dónde está el archivo y cómo está cifrado en reposo? La respuesta útil menciona un módulo criptográfico o un servicio de custodia de claves privadas con su nombre. «Está cifrado en base de datos» no dice nada.
- ¿Quién del proveedor puede extraerlo? Si hay alguien que puede hacerlo, la operación entra en el régimen de tercerización con intervención humana del reglamento de protección de datos, que trae obligaciones propias y que está explicado aquí.
- ¿Está acreditado ante INDECOPI como prestador de servicios de valor añadido en firma remota? Es un sí o un no que se comprueba en el registro, no una opinión del comercial.
- ¿Qué pasa el día que se acaba el contrato? Quién borra el archivo, en cuánto tiempo y qué constancia te entrega.
Si la respuesta a la tercera es «no», que será casi siempre, la decisión sigue siendo tuya y puede ser razonable tomarla igual. Lo que no conviene es tomarla sin saber que se está tomando.
Qué hacer con esto
Para una empresa que emite cien comprobantes al mes desde un servicio en la nube, el riesgo real de que alguien abuse del .pfx es bajo y el coste de cambiar de arquitectura es alto. La recomendación defendible es más barata: usar para la facturación un certificado dedicado, de agente automatizado, distinto del que firma contratos y actas, y no mezclar nunca los dos. Así, el día que haya que cancelar uno de los dos por una sospecha, cancelas el que toca y el otro sigue trabajando.
En mifirmadigital.pe emitimos certificados dentro de la Infraestructura Oficial de Firma Electrónica, incluidos los de agente automatizado para sistemas que firman solos. Si quieres separar el certificado de facturación del que usas para firmar documentos, escríbenos con tu RUC y el volumen que emites al mes.