Cuando una aplicación indica que una firma digital es válida, detrás de ese mensaje aparentemente sencillo pueden haberse realizado decenas de comprobaciones.

Un sistema profesional de validación no se limita a localizar un certificado dentro del documento ni a comprobar que la firma matemática sea correcta.

Debe responder a cuestiones como:

¿Los datos firmados siguen siendo los mismos?

¿La firma criptográfica corresponde realmente a esos datos?

¿Qué certificado se utilizó?

¿Quién emitió ese certificado?

¿Puede construirse una cadena de certificación de confianza?

¿El certificado estaba vigente cuando se realizó la firma?

¿Había sido revocado?

¿Existe una evidencia fiable de cuándo se realizó la operación?

¿El prestador que emitió el certificado tenía la condición correspondiente en ese momento?

¿Se dispone de toda la información necesaria para llegar a una conclusión?

Esta última pregunta es especialmente importante.

En validación de firmas digitales no siempre existen únicamente dos resultados posibles: válida o inválida.

Los estándares ETSI contemplan también situaciones en las que el sistema no dispone de evidencias suficientes para alcanzar una conclusión definitiva.

Entender estas comprobaciones es fundamental para diseñar procesos automáticos de validación en banca, seguros, Administraciones Públicas y cualquier organización que reciba documentación firmada electrónicamente.

Validar una firma no es ejecutar una única comprobación

La validación de una firma electrónica es un proceso compuesto por diferentes verificaciones relacionadas entre sí.

ETSI EN 319 102-1 establece procedimientos para la creación y validación de firmas electrónicas avanzadas y constituye una de las principales referencias técnicas europeas en esta materia.

El proceso puede analizar diferentes objetos:

• documento firmado;
• valor criptográfico de la firma;
• certificado del firmante;
• certificados intermedios;
• certificados raíz;
• información de revocación;
• sellos de tiempo;
• evidencias de existencia;
• algoritmos criptográficos;
• atributos firmados;
• políticas de validación.

Por tanto, cuando un sistema devuelve un resultado de validación está evaluando un conjunto de evidencias conforme a determinados criterios, no realizando una única operación binaria.

1. Detectar qué firmas contiene el documento

La primera tarea consiste en saber qué estamos validando.

Un documento PDF puede contener:

• una única firma;
• varias firmas sucesivas;
• firmas de diferentes personas;
• sellos electrónicos;
• sellos de tiempo;
• distintas revisiones del documento.

Un motor debe localizar todos estos elementos antes de comenzar la validación individual.

Esto resulta especialmente importante en PDF.

Un contrato podría seguir esta secuencia:

1. se genera el documento;
2. firma el cliente;
3. firma un representante de la empresa;
4. se incorpora un sello electrónico;
5. se añade posteriormente una evidencia temporal.

Decir simplemente que el PDF “está firmado” aporta poca información.

El sistema debe ser capaz de identificar cada firma y qué versión del documento protege.

En nuestra guía sobre cómo validar una firma digital en un PDF desarrollamos específicamente esta problemática desde el punto de vista del usuario.

2. Comprobar criptográficamente la firma

Esta es una de las verificaciones fundamentales.

Al generar una firma digital se calcula una huella criptográfica de los datos protegidos.

Esa información se procesa utilizando la clave privada asociada al certificado del firmante.

Durante la validación, el sistema utiliza la correspondiente clave pública para comprobar que la firma es coherente con los datos firmados.

Simplificando:

Documento → hash → firma criptográfica

y durante la validación:

Documento actual → nuevo hash → comprobación mediante clave pública

Si los valores no son coherentes, algo ha ocurrido.

Puede haberse alterado el documento.

Puede haberse dañado la firma.

O puede que la firma no corresponda a esos datos.

Por tanto, esta comprobación responde a una pregunta fundamental:

¿La firma criptográfica protege realmente estos datos?

3. Comprobar la integridad del contenido firmado

Esta comprobación está estrechamente relacionada con la anterior.

Una de las principales garantías de una firma digital es permitir detectar alteraciones del contenido protegido.

Si alguien cambia una cantidad contractual, sustituye una página o modifica información firmada, la huella criptográfica dejará de corresponderse con la que fue protegida por la firma.

Pero en documentos PDF existe una particularidad.

Un PDF puede contener revisiones sucesivas.

Por ejemplo:

• la primera persona firma;
• posteriormente otra persona añade su firma;
• después se incorpora un sello de tiempo.

Esto significa que el documento puede haber evolucionado legítimamente después de una determinada firma.

Un sistema profesional debe determinar:

qué versión protegía cada firma

y

qué modificaciones se produjeron posteriormente.

No basta con comprobar que el fichero actual es diferente del fichero existente en el instante de la primera firma.

4. Identificar el certificado del firmante

Una vez comprobado el valor criptográfico de la firma, el sistema necesita analizar el certificado utilizado.

Un certificado digital puede proporcionar información como:

• titular;
• emisor;
• número de serie;
• periodo de validez;
• clave pública;
• algoritmos utilizados;
• usos permitidos;
• extensiones;
• políticas de certificación.

Esta información permite responder a preguntas importantes sobre el firmante y sobre la infraestructura de confianza utilizada.

Sin embargo, existe una distinción esencial:

extraer correctamente un certificado no significa todavía que podamos confiar en él.

Para determinarlo es necesario analizar su cadena de certificación.

5. Construir la cadena de certificación

Los certificados digitales suelen formar parte de una PKI — Public Key Infrastructure.

El certificado utilizado por el firmante puede haber sido emitido por una autoridad intermedia, que a su vez ha sido certificada por otra autoridad.

Una cadena simplificada podría ser:

Certificado del firmante

↓

CA intermedia

↓

CA raíz

El motor de validación debe intentar construir una cadena válida hasta una fuente de confianza adecuada.

Durante este proceso puede comprobar, entre otras cuestiones:

• firmas criptográficas de los certificados;
• periodos de vigencia;
• extensiones;
• restricciones;
• usos de clave;
• políticas;
• estado de revocación.

Esto explica por qué una frase como:

“comprobar que la CA es fiable”

resulta demasiado simplificada.

La cuestión correcta es:

¿puede construirse una cadena de certificación válida hasta una fuente de confianza aceptada por la política de validación?

6. Determinar si el prestador y el servicio son de confianza

En Europa, eIDAS añade otro elemento especialmente relevante: las Trusted Lists.

Los Estados miembros mantienen listas que permiten identificar a los prestadores cualificados de servicios de confianza y los servicios cualificados que proporcionan.

La Comisión Europea mantiene a su vez la List of Trusted Lists — LOTL, que facilita el acceso a las listas nacionales.

Estas listas tienen una característica jurídica muy importante dentro de eIDAS:

la condición cualificada corresponde al servicio concreto que aparece con esa condición en la Trusted List.

No es suficiente que una empresa sea genéricamente un prestador conocido.

El validador puede necesitar determinar:

• qué prestador emitió el certificado;
• qué servicio concreto utilizó;
• cuál era el estado de ese servicio;
• qué condición tenía en el momento relevante.

Esta información resulta esencial cuando se pretende determinar si una firma o un certificado tienen carácter cualificado.

7. Comprobar cuándo era válido el certificado

Todos los certificados tienen un periodo de vigencia.

Normalmente contienen dos fechas:

Not Before

y

Not After

Pero un motor de validación no debería limitarse a comprobar si el certificado está vigente hoy.

Imaginemos:

• contrato firmado en 2022;
• certificado válido entre 2021 y 2024;
• validación realizada en 2026.

El certificado está actualmente caducado.

Sin embargo, eso no significa que la firma realizada en 2022 fuese inválida.

La cuestión relevante es:

¿podemos demostrar que el certificado era válido en el momento aplicable a la firma?

Para responder correctamente necesitaremos también información temporal y datos sobre revocación.

8. Comprobar la revocación mediante OCSP y CRL

Un certificado puede dejar de ser válido antes de su fecha de expiración.

Por ejemplo, porque:

• se ha comprometido su clave privada;
• se ha perdido el dispositivo que almacenaba la clave;
• el titular ha solicitado la revocación;
• el prestador ha revocado el certificado;
• se han producido cambios que justifican su retirada.

Para consultar esta situación existen principalmente dos mecanismos.

OCSP

Online Certificate Status Protocol permite consultar el estado de un certificado a un servicio del prestador.

De forma simplificada, el validador pregunta:

“¿Cuál es el estado de este certificado?”

y obtiene una respuesta firmada por el servicio correspondiente.

CRL

Las Certificate Revocation Lists son listas publicadas por las autoridades de certificación que contienen certificados que han sido revocados.

Ambos mecanismos permiten aportar información sobre el estado del certificado.

Sin embargo, aparece nuevamente la dimensión temporal.

No basta con saber que un certificado está revocado hoy.

Hay que determinar:

cuándo se revocó

y

cuándo se produjo la firma.

9. Determinar el momento relevante de la firma

Aquí comienza una de las partes más interesantes de la validación.

Supongamos que un certificado fue revocado el 10 de octubre.

Tenemos un documento que afirma haber sido firmado el 5 de octubre.

La pregunta es:

¿cómo sabemos realmente que la firma ya existía el día 5?

Una fecha almacenada por el propio software de firma no aporta necesariamente una evidencia temporal independiente.

El reloj del ordenador puede estar mal configurado o incluso manipulado.

Por eso los procesos de validación avanzada utilizan evidencias temporales.

10. Validar los sellos de tiempo

Un sello de tiempo incorpora una evidencia emitida por una TSA — Time Stamping Authority.

Esta evidencia permite demostrar que determinados datos existían antes de un instante concreto.

Pero el sello de tiempo también debe validarse.

El sistema puede tener que comprobar:

• firma criptográfica del sello;
• certificado de la TSA;
• cadena de certificación;
• estado del certificado;
• momento de emisión;
• algoritmo utilizado;
• correspondencia entre la huella sellada y los datos protegidos.

Es decir:

un sello de tiempo no elimina la necesidad de validar; añade nuevas evidencias que también deben ser validadas.

Esta relación entre validación y evidencia temporal será uno de los ejes del clúster.

edatalia opera un servicio de sello de tiempo cualificado y dispone de información específica sobre sus características y políticas.

11. Determinar si existe una prueba de existencia

Los estándares de validación utilizan un concepto especialmente interesante: Proof of Existence — POE.

En términos simplificados, una POE ayuda a demostrar que una determinada evidencia electrónica existía antes de un instante concreto.

Los sellos de tiempo son uno de los mecanismos que pueden aportar este tipo de evidencia.

Su importancia aparece claramente en validaciones realizadas mucho después de la firma.

Por ejemplo:

• un certificado ha caducado;
• posteriormente se ha revocado;
• una CA ha dejado de operar;
• determinado algoritmo ya no se considera seguro.

Si existen evidencias temporales adecuadas, podemos reconstruir qué situación existía antes de esos acontecimientos.

Esto es una de las bases de la validación a largo plazo.

12. Evaluar los algoritmos criptográficos utilizados

Los algoritmos criptográficos envejecen.

Un algoritmo considerado seguro hoy puede dejar de serlo dentro de varios años debido a:

• avances criptográficos;
• aumento de potencia computacional;
• descubrimiento de vulnerabilidades;
• nuevas recomendaciones regulatorias.

Un sistema de validación puede aplicar restricciones relacionadas con:

• algoritmo de hash;
• algoritmo de firma;
• longitud de claves;
• fecha hasta la que un algoritmo se considera fiable.

Este elemento es especialmente importante en documentos que deben conservarse durante muchos años.

La firma puede ser matemáticamente verificable y, sin embargo, utilizar un algoritmo que ya no cumpla los criterios establecidos por la política de validación.

13. Analizar el perfil de firma utilizado

Cuando hablamos de documentos PDF firmados aparece PAdES.

La nomenclatura actual de PAdES Baseline distingue perfiles como:

Esta evolución está directamente relacionada con el trabajo del validador.

Una firma PAdES-B-B puede depender de información disponible externamente en el momento de la validación.

PAdES-B-LT incorpora al documento datos de validación que facilitan posteriores comprobaciones.

PAdES-B-LTA va un paso más allá para afrontar escenarios de conservación prolongada.

En edatalia ya hemos abordado estos conceptos en nuestro contenido sobre firma digital de larga duración PAdES-LTV, y construiremos además un clúster específico sobre los distintos niveles actuales de PAdES.

14. Comprobar la política de validación

Este es uno de los conceptos menos conocidos y, sin embargo, uno de los más importantes.

Una firma no se valida en el vacío.

El motor aplica un conjunto de reglas o validation constraints.

Por ejemplo:

• qué fuentes de confianza se aceptan;
• qué algoritmos están permitidos;
• qué tamaños de clave son suficientes;
• qué evidencias temporales se requieren;
• cómo debe tratarse determinada información de revocación;
• qué tipo de certificado es aceptable.

Por eso dos sistemas de validación configurados con políticas distintas podrían no llegar exactamente a la misma conclusión sobre determinadas características de una firma.

La propia Comisión Europea advierte de que pueden existir diferentes políticas de validación según el contexto del receptor.

Esto introduce una distinción muy importante:

validar significa comprobar una firma conforme a unos criterios determinados.

Una firma no tiene únicamente dos posibles resultados

Es habitual representar la validación como:

válida

o

inválida.

Pero técnicamente la situación puede ser más compleja.

ETSI EN 319 102-1 contempla tres indicaciones principales de resultado:

Este último estado es especialmente importante.

¿Qué significa INDETERMINATE?

Imaginemos que la firma criptográfica es correcta.

El documento no ha sido alterado.

El certificado parece adecuado.

Pero no conseguimos obtener la información histórica necesaria para determinar si el certificado estaba revocado en el momento relevante.

¿Podemos afirmar que la firma es válida?

No necesariamente.

¿Podemos afirmar que es falsa o inválida?

Tampoco necesariamente.

El resultado puede ser:

INDETERMINATE

Es decir:

con las evidencias disponibles no es posible alcanzar una conclusión definitiva.

Esta diferencia es crucial en aplicaciones corporativas.

Un sistema no debería transformar automáticamente cualquier imposibilidad de validación en:

“firma falsa”.

TOTAL-FAILED tampoco significa necesariamente fraude

Una firma puede fallar una validación por diferentes motivos.

Por ejemplo:

• la integridad criptográfica ha fallado;
• el contenido protegido ha cambiado;
• una condición obligatoria de la política no se cumple;
• se ha demostrado que la firma se produjo después de una revocación relevante;
• el formato no cumple determinadas restricciones.

Pero un motor técnico no determina necesariamente:

“esta persona intentó cometer un fraude”.

Determina que la firma no cumple las condiciones de la política de validación utilizada.

La interpretación jurídica y de negocio puede requerir análisis adicional.

Validación técnica y validación de negocio

Esta es otra distinción fundamental.

La Comisión Europea explica expresamente que el resultado de una validación técnica debe complementarse con reglas de negocio que determinen si la firma resulta aceptable para el proceso concreto.

Un motor puede concluir técnicamente:

TOTAL-PASSED

Pero la aplicación puede necesitar además comprobar:

• si el firmante era la persona esperada;
• si tenía poderes de representación;
• si podía firmar ese contrato;
• si se exigía una firma cualificada;
• si el documento corresponde al expediente correcto;
• si la operación supera un determinado importe;
• si existe alguna regla sectorial adicional.

Por tanto podemos separar:

Validación técnica

¿La firma y sus evidencias cumplen los criterios técnicos?

de:

Validación de negocio

¿Esta firma es aceptable para esta operación concreta?

Esta separación resulta especialmente importante en banca, seguros y Administraciones Públicas.

Ejemplo: un documento firmado correctamente por la persona equivocada

Supongamos que una empresa espera recibir un contrato firmado por su administrador.

El PDF contiene una firma digital perfecta.

El certificado es válido.

La cadena de confianza es correcta.

No hay revocación.

Existe sello de tiempo.

El resultado técnico puede ser satisfactorio.

Pero el certificado pertenece a otra persona que no tiene poderes para representar a la sociedad.

El motor criptográfico no puede decidir por sí solo si esa persona tenía autorización suficiente.

La firma puede ser técnicamente válida y, sin embargo, no superar las reglas de negocio del proceso.

¿Qué información debería devolver un buen sistema de validación?

Una aplicación empresarial necesita bastante más que un simple:

"valid": true

Un resultado útil puede incluir:

• número de firmas detectadas;
• estado individual de cada firma;
• identidad contenida en cada certificado;
• certificado utilizado;
• certificado emisor;
• cadena de certificación;
• estado de revocación;
• evidencias temporales;
• sellos de tiempo;
• perfil PAdES;
• algoritmos utilizados;
• modificaciones posteriores;
• errores encontrados;
• advertencias;
• motivo de un resultado indeterminado;
• información técnica extraída de los certificados.

La Comisión Europea, por ejemplo, implementa en DSS diferentes niveles de informe: informe simple, informe detallado, datos de diagnóstico e informe de validación ETSI.

Esto ilustra una idea importante:

el verdadero valor de un motor de validación no es únicamente producir un semáforo verde o rojo, sino explicar por qué se ha alcanzado ese resultado.

Validación automática mediante API

Cuando estas comprobaciones deben realizarse sobre grandes volúmenes de documentos, la validación manual deja de ser viable.

Una arquitectura típica puede ser:

Documento recibido

↓

API de validación

↓

Motor de validación

↓

Resultado estructurado

↓

Reglas de negocio

↓

Continuar / revisar / rechazar

edatalia dispone de soluciones de validación de ficheros firmados digitalmente que pueden integrarse mediante webService y API REST.

El servicio puede recibir un archivo, localizar las firmas digitales existentes, realizar las correspondientes verificaciones y devolver información estructurada a la aplicación.

Entre otros elementos, pueden extraerse también los certificados digitales y las claves públicas implicadas en el proceso.

Esta capacidad permite incorporar la validación directamente dentro de aplicaciones corporativas y workflows documentales.

Ejemplo en banca

Una entidad financiera recibe un contrato firmado electrónicamente.

Su workflow podría analizar automáticamente:

1. si el documento contiene firmas;
2. cuántas existen;
3. si la integridad criptográfica es correcta;
4. quién figura como firmante;
5. qué certificado utilizó;
6. qué prestador lo emitió;
7. si la cadena es de confianza;
8. si el certificado estaba vigente;
9. si estaba revocado;
10. si existe sello de tiempo;
11. qué perfil de firma contiene;
12. cuál es el resultado de validación.

Después aplica reglas propias:

TOTAL-PASSED + firmante esperado → continuar

INDETERMINATE → revisión especializada

TOTAL-FAILED → detener o derivar el expediente

La decisión deja de depender de que un empleado abra manualmente cada PDF.

Ejemplo en seguros

Una aseguradora puede recibir documentos firmados procedentes de clientes, corredores, peritos, abogados o proveedores.

El motor puede realizar la validación técnica.

Después el sistema de negocio determina:

• si el firmante está autorizado;
• si corresponde a la póliza;
• si el documento exigía ese nivel de firma;
• si la documentación puede continuar automáticamente.

La validación se convierte así en una pieza del proceso documental, no en una herramienta utilizada de forma aislada.

Ejemplo en Administraciones Públicas

Las Administraciones Públicas reciben documentación electrónica de ciudadanos, empresas, profesionales y otras Administraciones.

La validación automatizada permite analizar las firmas antes de incorporar los documentos a expedientes o procesos administrativos.

En este entorno adquieren especial importancia:

• interoperabilidad;
• políticas de firma;
• certificados cualificados;
• Trusted Lists;
• sellos electrónicos;
• sellos de tiempo;
• validación a largo plazo.

Por ello la Administración electrónica ha sido tradicionalmente uno de los principales ámbitos de aplicación de los servicios automáticos de validación de firmas y certificados.

Validar hoy no siempre es suficiente

Existe una última cuestión fundamental.

Una firma puede ser perfectamente validable en 2026.

Pero quizá el documento tenga que conservarse hasta 2046.

Durante esos veinte años pueden ocurrir muchas cosas:

• caduca el certificado;
• desaparece una CA;
• dejan de publicarse determinadas CRL;
• cambia el estado de un servicio de confianza;
• un algoritmo criptográfico queda obsoleto.

Por eso la estrategia documental debe preguntarse:

¿necesitamos validar únicamente ahora o necesitamos garantizar que podremos aportar evidencias suficientes dentro de muchos años?

Esta pregunta conecta directamente la validación de firmas con:

PAdES-LT

PAdES-LTA

y

sellado de tiempo

que desarrollaremos específicamente en otros contenidos del clúster.

¿Y la firma digital manuscrita?

La firma manuscrita biométrica requiere un modelo de verificación diferente.

Cuando una persona firma sobre una tableta Wacom pueden capturarse datos dinámicos como:

• presión;
• velocidad;
• aceleración;
• coordenadas;
• secuencia temporal.

Estos datos pueden protegerse criptográficamente y vincularse al documento.

Pero validar una firma biométrica no consiste en construir la cadena PKI del certificado personal del firmante, porque la identidad no se acredita necesariamente mediante ese mecanismo.

Ante una controversia pueden intervenir:

• extracción controlada de datos biométricos;
• custodia de claves;
• firmas indubitadas;
• herramientas de comparación;
• análisis pericial.

Por eso dedicaremos un artículo independiente a validación de firma digital manuscrita, evitando mezclar dos mecanismos técnicos diferentes bajo el mismo concepto.

Un sistema de validación responde a muchas preguntas a la vez

Podemos resumir las principales comprobaciones de esta forma:

Por eso un motor de validación es mucho más que un simple comprobador de certificados.

Preguntas frecuentes sobre los sistemas de validación de firmas digitales

¿Qué comprueba un sistema de validación de firmas digitales?

Comprueba diferentes elementos relacionados con la firma, como la integridad de los datos, corrección criptográfica, certificado del firmante, cadena de certificación, revocación, evidencias temporales, algoritmos y criterios definidos por la política de validación.

¿Que una firma sea criptográficamente correcta significa que es válida?

No necesariamente. La comprobación criptográfica es solo una de las fases. También deben analizarse el certificado, la confianza, la revocación, las evidencias temporales y las condiciones establecidas por la política de validación.

¿Qué son las Trusted Lists?

Son listas publicadas por los Estados miembros de la UE que permiten identificar los prestadores cualificados de servicios de confianza y los servicios cualificados que proporcionan.

¿Qué diferencia existe entre OCSP y CRL?

Ambos mecanismos aportan información sobre revocación de certificados. OCSP permite consultar el estado de un certificado mediante un servicio en línea, mientras que una CRL es una lista publicada de certificados revocados.

¿Qué significa TOTAL-PASSED?

Indica que la firma ha superado las comprobaciones requeridas por la política de validación aplicada.

¿Qué significa TOTAL-FAILED?

Indica que existen comprobaciones determinantes que han fallado y permiten concluir que la firma no cumple los requisitos definidos por la política.

¿Qué significa INDETERMINATE?

Significa que las evidencias disponibles no permiten determinar definitivamente que el resultado sea satisfactorio o fallido. No debe interpretarse automáticamente como una firma falsa.

¿Por qué puede cambiar el resultado de una validación?

Porque la validación depende de diferentes entradas: momento de validación, información de revocación, certificados disponibles, evidencias temporales y política aplicada. La aparición de nuevas evidencias puede permitir resolver situaciones anteriormente indeterminadas.

¿Qué función tiene el sello de tiempo?

Permite aportar una evidencia independiente sobre la existencia de determinados datos en un momento concreto y resulta especialmente importante para establecer relaciones temporales entre firma, vigencia y revocación.

¿Por qué PAdES-LT facilita la validación futura?

Porque incorpora al documento material de validación, como certificados e información de revocación, reduciendo la dependencia de fuentes externas cuando la firma tenga que comprobarse posteriormente.

¿Qué diferencia existe entre validación técnica y validación de negocio?

La validación técnica comprueba firma, certificados y evidencias electrónicas. La validación de negocio determina si esa firma es aceptable para una operación concreta, por ejemplo comprobando poderes de representación, identidad esperada o requisitos particulares del proceso.

¿Puede automatizarse todo este proceso mediante API?

Sí. Un sistema corporativo puede enviar documentos a un motor de validación mediante API y recibir resultados estructurados que después se utilizan en las reglas de negocio de la aplicación.

Validar significa reconstruir la confianza

Una firma digital no debe considerarse válida simplemente porque un documento muestre un certificado o una marca gráfica.

La confianza se construye comprobando un conjunto de evidencias relacionadas:

contenido → firma → certificado → cadena → revocación → tiempo → política

Cuanto mayor sea la importancia del documento y mayor su periodo de conservación, mayor relevancia tendrá disponer de todas estas evidencias.

Por eso la validación se está convirtiendo en una pieza esencial de las arquitecturas documentales de bancos, aseguradoras, Administraciones Públicas y organizaciones que reciben grandes volúmenes de documentación electrónica.

Firmar un documento permite generar evidencias.

Validarlo permite comprobar si podemos confiar en ellas.