Un backend que emite contratos, actas, certificados o reportes en PDF llega tarde o temprano al mismo requerimiento: que el archivo salga firmado sin intervención humana y que cualquier visor lo reconozca como válido. Ahí entra PAdES, el perfil de firma electrónica avanzada diseñado específicamente para el formato PDF.
La experiencia de campo dice que casi ningún problema de integración viene de la criptografía. Viene del formato. Un PDF firmado mal armado abre bien, se imprime bien y falla en la validación; o peor, muestra la advertencia de documento modificado ante el cliente que lo recibió. Este artículo recorre lo que un equipo de desarrollo necesita entender antes de escribir la primera línea, con el contexto ecuatoriano en mente.
Qué es PAdES y por qué no basta con estampar una imagen
PAdES es la familia de especificaciones europeas (ETSI) que define cómo incorporar una firma electrónica avanzada dentro de un archivo PDF, apoyándose en el propio diccionario de firmas que el formato ya tenía. No es un formato paralelo: es un conjunto de reglas sobre cómo usar lo que el PDF ofrece para que la firma sea verificable a largo plazo.
Conviene fijar una idea desde el inicio: la imagen que se ve en la hoja no es la firma. La firma es una estructura binaria almacenada dentro del documento, en un objeto reservado para eso. La rúbrica visible es apenas una apariencia opcional. Un PDF puede estar perfectamente firmado y no mostrar nada, y puede mostrar una rúbrica preciosa sin tener firma alguna. Los equipos que confunden ambas cosas terminan investigando por qué la firma no aparece en el PDF cuando en realidad el problema es el inverso.
Los perfiles de PAdES: hasta dónde llegar
La especificación define niveles progresivos. Cada uno agrega elementos y responde a una pregunta distinta sobre el futuro del documento.
| Nivel | Qué agrega | Qué problema resuelve | Cuándo usarlo |
|---|---|---|---|
| B-B (básico) | Firma y atributos firmados mínimos | Autoría e integridad | Documentos de vida corta o de circulación interna |
| B-T | Sello de tiempo de una autoridad | Prueba de la fecha, independiente del reloj del servidor | Contratos, actas, documentos con plazos |
| B-LT | Certificados y respuestas de revocación embebidos | Validar sin depender de servicios en línea | Archivo documental, expedientes, auditoría |
| B-LTA | Sello de archivo sobre el conjunto | Conservación por muchos años | Custodia de largo plazo |
La decisión no es técnica sino documental: cuánto tiempo tiene que seguir siendo verificable ese archivo. Un comprobante de entrega interno no necesita lo mismo que un contrato de arrendamiento a diez años. Subir de nivel implica dependencias externas —el servicio de sellado de tiempo y las consultas de revocación— que hay que diseñar con timeouts y reintentos, porque si el proveedor no responde tu proceso de firma se detiene.
Cómo entra la firma en el archivo sin romperlo
Este es el punto donde fallan las implementaciones caseras. Un PDF firmado no se regenera: se le agrega contenido al final mediante una actualización incremental. El archivo original queda intacto byte a byte y la firma se anexa. Esa propiedad es la que permite firmas sucesivas sin invalidar las anteriores.
El flujo real, en cualquier librería seria, es de dos pasadas:
- Se reserva un espacio vacío dentro del documento para el contenido de la firma y se define el rango de bytes que quedará cubierto.
- Se calcula el resumen criptográfico de todo el archivo excepto ese hueco reservado.
- Ese resumen se firma con la clave privada, se arma la estructura de firma y se inserta en el espacio reservado, sin desplazar ni un byte del resto.
De ahí se derivan dos reglas prácticas. Primera: ningún proceso posterior puede tocar el PDF. Si tu pipeline comprime, optimiza, agrega metadatos o lo pasa por un conversor después de firmar, la firma queda rota y el visor lo dirá. Segunda: el espacio reservado debe alcanzar. Si vas a incrustar sellos de tiempo y cadenas de revocación, el hueco por defecto de algunas librerías se queda corto y el proceso falla al final, después de haber consumido el llamado al proveedor.
Firma visible, invisible y campos de formulario
Si el documento necesita rúbrica visible, se coloca sobre un campo de firma con posición, página y apariencia definidas. Tres criterios que ahorran retrabajo:
- Define la posición desde la plantilla, no con coordenadas calculadas a ojo. Si el PDF lo genera tu sistema, deja el campo de firma creado desde el inicio con nombre conocido.
- La apariencia es texto e imagen, nada más. No pongas ahí datos que no estén en el documento; si el nombre del firmante importa, que también conste en el cuerpo.
- Cuidado con los documentos de varias firmas: cada firmante necesita su propio campo. Reutilizar el mismo campo sobrescribe y confunde.
En documentos que circulan entre áreas, conviene además definir si la primera firma certifica el documento y bloquea cambios posteriores, o si permite firmas adicionales. Esa configuración se establece al firmar y no se puede cambiar después: es la diferencia entre un contrato que todavía debe recorrer un flujo de aprobaciones y uno ya cerrado.
Qué necesita el servidor para firmar
Del lado de la infraestructura hacen falta cuatro piezas: el certificado con su clave privada, la cadena completa de la entidad emisora, una librería que implemente PAdES y, si vas a nivel B-T o superior, acceso de red a los servicios de sellado y revocación.
La forma de custodiar la clave define el resto del diseño. Un archivo .p12 en el servidor es la vía más simple y exige disciplina de seguridad; un módulo de hardware o la firma en la nube desplazan la clave fuera del servidor de aplicación. Las precauciones concretas para el primer caso están en firmar en servidor con .p12.
Sobre el rendimiento: la operación criptográfica en sí es barata. Lo caro es leer y escribir archivos grandes en memoria y esperar respuestas de red. Si firmas cientos de documentos por lote, trabaja con flujos en lugar de cargar el PDF completo y saca el proceso del ciclo de la petición HTTP, como se explica en colas y workers para firma masiva.
PAdES y el SRI: lo que no aplica
Vale una aclaración que evita semanas perdidas. La normativa de facturación electrónica del SRI no exige PAdES. Lo que se firma y se envía al SRI es el archivo XML del comprobante, con el perfil XAdES que define su ficha técnica. El PDF que recibe el cliente es la representación impresa del documento electrónico y no requiere una firma propia para ser válido: su respaldo es el XML autorizado.
Firmar también el PDF es una decisión comercial legítima —queda más presentable y evita manipulaciones del archivo que circula por correo—, pero no es un requisito tributario. Si tu proyecto es de comprobantes, el camino correcto es XAdES para comprobantes del SRI. PAdES es para el resto de la documentación de la empresa: contratos, actas, informes, certificados, órdenes.
Fallas frecuentes en producción
- Documento modificado después de firmar: casi siempre un paso de post-proceso en el pipeline. Revisa el orden de las tareas.
- Cadena de certificación incompleta: el visor no encuentra la raíz de la entidad emisora. Hay que incrustar la cadena al firmar; el detalle está en el error de cadena de certificados.
- Reloj del servidor desfasado: sin sello de tiempo, la fecha de firma es la del contenedor. Sincroniza por NTP o usa nivel B-T.
- Certificado vencido a mitad del lote: verifica vigencia antes de procesar, no documento por documento.
- Fuentes no incrustadas en la apariencia visible, que hacen que la rúbrica se vea distinta en cada equipo.
Para cerrar el circuito, todo emisor debería tener también un verificador propio que revise sus salidas antes de entregarlas: un proceso que abra el PDF recién firmado, valide la firma y solo entonces lo publique. Detecta el 90% de estos casos antes de que llegue al destinatario.
Antes de escribir código
Un proyecto de firma en backend se define en tres preguntas: quién es el titular del certificado que firmará, qué nivel de PAdES exige la vida útil del documento y dónde va a residir la clave privada. Con eso resuelto, la integración es trabajo conocido; sin eso, se reescribe dos veces. La visión general del stack está en la guía técnica para desarrolladores.
Los certificados para el titular se emiten 100% en línea, en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube. Para valores por volumen y planes corporativos, revisa la página de precios.
Omnifox, para lo que pasa alrededor del documento
El mismo grupo desarrolla Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida. En proyectos de firma automatizada resuelve el tramo humano: avisar al cliente que su documento está listo, responder el "no me llegó" y dejar esa conversación registrada junto a la cuenta, en lugar del celular de quien atendió. Se conecta por API con el mismo backend que emite los documentos. Más información en omnifox.io.
Preguntas frecuentes
¿Puedo firmar un PDF que ya tiene otra firma?
Sí, siempre que la firma previa no haya certificado el documento bloqueando cambios. Cada firma se agrega como una actualización incremental y las anteriores siguen siendo verificables.
¿La firma visible es obligatoria?
No. La validez proviene de la estructura criptográfica, no de la rúbrica. La apariencia visible se usa por conveniencia de lectura y para que el receptor sepa a simple vista que el documento está firmado.
¿Necesito sello de tiempo en todos los documentos?
No en todos. Es recomendable cuando la fecha del acto tiene consecuencias —plazos, vencimientos, licitaciones— o cuando el documento debe conservarse por años. Para documentación operativa de vida corta, el nivel básico alcanza.
¿Qué pasa si el certificado del firmante vence después?
La firma no se invalida por el vencimiento posterior; lo que importa es que el certificado estuviera vigente al momento de firmar. Para poder probarlo años después conviene el nivel con sello de tiempo e información de revocación embebida.
¿Puedo firmar en el navegador en lugar del servidor?
Se puede, con firma del lado del cliente y armado del documento en el servidor. Es la opción cuando la clave debe permanecer en el equipo del firmante, aunque complica el despliegue. Si el flujo es desatendido, la firma en servidor o en la nube es más manejable.
Si tu equipo va a integrar firma de PDF en producción y necesita certificados para uno o varios firmantes, conversa con un asesor corporativo de Firmas.com.ec. Cotiza tu plan corporativo.