Integrar firma digital en tu sistema: PAdES, XAdES y las decisiones que no se pueden deshacer
Una integración de firma digital se parece poco a lo que promete la documentación. La parte de invocar una biblioteca y obtener un archivo firmado se resuelve en una tarde. Lo que cuesta es todo lo que se decide en esa tarde sin saber que se está decidiendo, y que aparece dos años después cuando hay cien mil documentos firmados y alguien pide verificar uno de 2024.
Son tres decisiones: qué formato, qué nivel y dónde vive la clave privada.
Formato: no es una preferencia, lo determina el archivo
Los formatos que el Estado peruano reconoce están escritos en el sitio del validador de Firma Perú, la plataforma de la Secretaría de Gobierno y Transformación Digital: «Puedes validar las firmas generadas con formatos estandarizados como PAdES, XAdES o CAdES. Otros formatos pueden dar resultados no concluyentes».
Esa última frase es el criterio de diseño. Si tu sistema produce algo que el validador oficial no reconoce, el documento no está roto pero sí queda fuera del circuito donde otros pueden comprobarlo sin fiarse de ti.
Los tres no compiten entre sí. Cada uno cubre un tipo de contenido:
| Formato | Para qué | Dónde queda la firma |
|---|---|---|
| PAdES | documentos PDF | dentro del propio PDF, que sigue abriéndose normal |
| XAdES | XML: comprobantes electrónicos, mensajes entre sistemas | dentro del XML o junto a él |
| CAdES | cualquier archivo binario: Word, Excel, imágenes, ZIP | en un archivo .p7s aparte o envolviendo al original |
La regla práctica: si el usuario va a abrir el archivo, PAdES. Un PDF con firma PAdES sigue siendo un PDF que cualquiera abre con doble clic y en el que el lector muestra el panel de firmas. Un PDF acompañado de un .p7s obliga a explicarle a cada destinatario qué es ese segundo archivo y por qué no puede perderlo.
Si el que va a leer es otro sistema y el contenido ya es XML, XAdES, que es lo que usa la facturación electrónica peruana.
Nivel: cuánto tiene que durar la verificación
Aquí es donde se equivocan casi todas las integraciones nuevas, porque el nivel más simple funciona perfectamente el día que se implementa.
Los perfiles baseline de ETSI definen una escala. En la práctica lo que hay que decidir son dos cosas: si la firma lleva sello de tiempo y si lleva dentro el material para validarse sola.
- Nivel básico (B-B). La firma y el certificado del firmante. Se verifica bien mientras el certificado esté vigente y la lista de revocación siga en línea.
- Con sello de tiempo (B-T). Añade una marca de tiempo de un tercero que acredita cuándo se firmó. Sin esto, un certificado que caducó el año pasado deja tus firmas del año pasado en un limbo: nadie puede demostrar que se firmaron cuando estaba vigente.
- Con datos de validación (B-LT) y con sello a largo plazo (B-LTA). Incrusta en el documento las cadenas de certificados y las respuestas de revocación del momento de la firma, y luego sella todo el conjunto. Es lo que permite verificar un documento dentro de diez años sin que dependa de que un servidor de la entidad certificadora siga respondiendo.
El sello de tiempo no es un accesorio del formato: en Perú es un servicio acreditable por sí mismo. El artículo 38 del D.S. 052-2008-PCM exige, para el nivel de seguridad Medio Alto, que un «Sistema de Sellado de Tiempo» presente «certificación internacional de calidad para la provisión de sus servicios». Contratar el sello con quien no lo tenga acreditado deja la firma con una fecha que no vale como prueba.
La recomendación, dicha claro: si los documentos tienen que sobrevivir a la vigencia del certificado —contratos, actas, expedientes, cualquier cosa con plazo de conservación—, empieza directamente en el nivel con datos de validación. Subir de nivel después obliga a re-firmar documentos que ya circularon, y eso suele ser imposible.
Dónde vive la clave privada
La tercera decisión es de infraestructura y la determina el volumen.
Si el proceso es automático, el certificado que corresponde no es el de una persona. El artículo 14 del reglamento contempla el caso: para certificados «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».
Traducido a arquitectura: nadie teclea un PIN por documento y la empresa responde por cada firma que salga de ese servidor. Qué opciones hay para custodiar esa clave privada y qué preguntar a un proveedor está en firma remota y HSM, y qué figura te corresponde según el caso, en qué certificado te corresponde.
Lo que no conviene hacer, aunque funcione: dejar el archivo .p12 con la clave privada en el repositorio, en una variable de entorno o en un bucket. Funciona igual de bien el primer día y convierte cualquier filtración en firmas atribuibles a la empresa.
Verificar es la mitad que casi nadie construye
Firmar es la parte fácil. Un sistema completo también recibe documentos de fuera y tiene que decidir si los acepta, y ahí hay cuatro comprobaciones distintas que suelen confundirse en una sola:
- La integridad. El resumen criptográfico coincide con el contenido. Esto es lo único que verifica la mayoría de las implementaciones caseras.
- La vigencia en el momento de la firma. No hoy: entonces. Sin sello de tiempo esta comprobación no se puede hacer con certeza.
- La revocación. Que ese certificado no estuviera cancelado, consultando la lista de revocación o el servicio OCSP de la entidad emisora.
- La cadena de confianza. Que el certificado cuelgue de una entidad acreditada dentro de la Infraestructura Oficial de Firma Electrónica. La lista oficial la publica INDECOPI en iofe.indecopi.gob.pe, con su fecha de emisión y su número de secuencia. El procedimiento manual está en cómo comprobar que un certificado digital está acreditado.
Saltarse la cuarta es el error con más consecuencias. Una firma técnicamente perfecta hecha con un certificado autofirmado pasa la comprobación de integridad sin problemas, y no tiene ningún valor jurídico en Perú.
Antes de escribir código, tres preguntas
¿Qué pasa el día que caduque el certificado con el que estamos firmando? Si la respuesta es «hay que renovarlo», falta la mitad. La otra mitad es qué ocurre con lo ya firmado.
¿Alguien va a verificar estos documentos fuera de nuestro sistema? Si sí, el formato tiene que ser uno de los tres que reconoce el validador del Estado, y conviene probarlo ahí antes de dar la integración por terminada.
¿Cuántas firmas por minuto en el pico? El número decide si esto es un token conectado a un servidor —que se convierte en punto único de fallo— o infraestructura de verdad.
Si estás en esa fase y quieres contrastar el diseño antes de construirlo, escríbenos. En CloudComputing operamos este tipo de integraciones y tenemos ISO/IEC 27001 certificada, así que la conversación empieza por lo que va a preguntar el auditor, no por la biblioteca.
Última revisión: 29 de agosto de 2026.