FirmaLocal
Firmar un PDF

Error SAF_09: «Error realizando la firma electrónica»

SAF_09: Autofirma ya tiene el certificado y falla la firma en sí. Clave privada inaccesible, controlador de tarjeta o tipo de clave. Cómo aislar la causa.

Actualizado el

«SAF_09: Error realizando la firma electrónica» es un código que da poca información y por eso desconcierta: no dice que falte el certificado, ni que falle la red, ni que la sede haya pedido algo raro. Dice que Autofirma llegó a intentar firmar y la operación falló. Es un error tardío: para verlo, la aplicación tuvo que arrancar, hablar con la sede, abrir el almacén y encontrar tu certificado. Todo eso funcionó. Lo que se rompió fue el último paso, el momento en que la clave privada tenía que calcular la firma.

Esa posición en la cadena es la mejor pista para resolverlo: las causas están en la clave privada, en el controlador que da acceso a ella o en la compatibilidad entre lo que la sede pide y lo que esa clave puede hacer. El resto de códigos, y a qué parte de la cadena corresponde cada uno, está en Todos los errores SAF de Autofirma.

Qué significa exactamente SAF_09

En el código fuente el error se llama ERROR_SIGNATURE_FAILED y se asocia a tres situaciones internas: un error desconocido durante la firma, un error al firmar por el puerto local y, la más concreta, un fallo en la firma PKCS#1, que es la operación matemática en la que la clave privada cifra el resumen del documento. Cuando esa operación falla, es porque la clave no está disponible, no responde o no admite lo que se le pide.

Es importante distinguirlo de sus vecinos:

  • Si Autofirma no encuentra ningún certificado, el código es SAF_19.
  • Si no puede abrir el almacén, es SAF_08.
  • Si la sede pide un formato o algoritmo que la versión instalada no conoce, la petición se rechaza antes y el código es SAF_03.

SAF_09 es lo que queda cuando todo lo anterior pasó el corte y aun así no salió una firma.

Las causas habituales

1. El certificado está, pero su clave privada no responde

El almacén muestra el certificado, Autofirma lo lista, tú lo seleccionas… y al pedirle a la clave que firme, el sistema devuelve un error. Pasa cuando la clave quedó en un contenedor que tu usuario actual no puede leer (típico tras cambiar de cuenta de Windows o restaurar un perfil), cuando la importación se hizo con la opción de Windows «Habilitar protección segura de clave privada» —que exige una confirmación que Autofirma no puede mostrar— o cuando el certificado se importó en un almacén de Mac cuya clave tiene el control de acceso restringido a otras aplicaciones.

2. El controlador de la tarjeta o el DNIe

Con DNIe o tarjetas criptográficas, la firma la calcula el chip, y entre Autofirma y el chip hay un lector, un controlador y, a menudo, la biblioteca JMulticard de la propia Autofirma. Un PIN bloqueado tras tres intentos, un controlador desactualizado, una tarjeta que se retiró y volvió a insertar con Autofirma abierta o un DNIe nuevo que la versión instalada aún no conoce producen exactamente este código. La incidencia #216 documenta un caso así con el DNIe de 2021 en Debian: la aplicación encontraba el certificado y fallaba al usarlo.

3. La sede pide un algoritmo que la clave no admite

La petición de la sede incluye el algoritmo de firma (por ejemplo, SHA256withRSA). Si tu certificado usa una clave de curva elíptica —cada vez más comunes— y la sede pide un algoritmo RSA, o si el Java que usa Autofirma no soporta ese tipo de clave, la operación falla en el último paso. En las versiones actuales existe un código específico para el tipo de clave (SAF_51), pero las sedes que usan el protocolo antiguo siguen viendo SAF_09. La solución es actualizar Autofirma y, en Linux, el Java del sistema.

4. Una instalación a medias

La FNMT recoge SAF_09 en su FAQ con una instrucción escueta: «para solucionar este error desinstale Autofirma» y vuelva a instalarla con permisos de administrador (menciona la versión de 32 bits; hoy lo razonable es la de 64 bits, que es la que publica el portal para los sistemas actuales). Detrás de ese consejo hay una realidad: un antivirus que puso en cuarentena parte del Java embebido, o una actualización que dejó bibliotecas de versiones distintas mezcladas, rompe justo las operaciones criptográficas y deja intacto todo lo demás.

Cómo aislar la causa en dos minutos

Antes de tocar nada, haz la prueba que separa los dos mundos:

  1. Abre Autofirma a mano, desde el menú de aplicaciones.
  2. Pulsa Firmar fichero, elige cualquier PDF, selecciona tu certificado y firma.

Si aquí también falla, el problema es tuyo: certificado, clave o controlador. Sigue con la lista de abajo. Si aquí funciona y en la sede no, la diferencia está en la petición de la sede —el algoritmo, el formato, una firma visible, una política—, y lo que toca es actualizar Autofirma y, si persiste, avisar al organismo con la fecha, la hora y la versión.

Cómo resolverlo, en orden

  1. Haz la prueba de Firmar fichero de arriba y quédate con el resultado.
  2. Comprueba la clave privada. En Windows, abre el certificado (Chrome/Edge → Configuración → Privacidad y seguridad → Seguridad → Gestionar certificados → Ver) y confirma el aviso «Tiene una clave privada correspondiente a este certificado». En Mac, en Acceso a Llaveros, despliega el certificado, haz doble clic en la clave y revisa Control de acceso.
  3. Vuelve a importar el .p12. Elimina la entrada e importa de nuevo el fichero original. En Windows, deja sin marcar la protección segura de clave privada. Si no conservas el .p12, tendrás que exportarlo desde donde funcione: Exportar certificado FNMT a .p12.
  4. Si usas tarjeta o DNIe: cierra Autofirma, retira y reinserta la tarjeta, comprueba que el PIN no está bloqueado y prueba con la casilla Habilitar JMulticard (en Herramientas → Preferencias) en la posición contraria a la actual. Actualiza el controlador del lector.
  5. Reinstala Autofirma: desinstala, reinicia, instala la última versión de 64 bits desde el portal oficial, con permisos de administrador. Antes, añade la carpeta de Autofirma a las exclusiones del antivirus.
  6. Prueba con otro certificado u otro equipo. Es la forma más rápida de saber si el problema viaja con el certificado o se queda en el ordenador.

Si sigue fallando: firmar sin pasar por el almacén del sistema

Muchos SAF_09 nacen de la capa que hay entre Autofirma y tu clave: el almacén de Windows, el Llavero, el controlador de la tarjeta. Si tu certificado es un fichero .p12 o .pfx —no una tarjeta—, esa capa se puede evitar.

Cuando lo que tienes que hacer es entregar un PDF firmado, FirmaLocal carga el .p12 directamente en el navegador, lee la clave privada del propio fichero y calcula la firma PAdES-B-B en tu equipo, sin almacén, sin controlador y sin Java. Si el fichero y su contraseña son correctos, la firma sale; ni el documento ni el certificado se suben a ningún servidor. Firma tu PDF ahora. Los límites, claros: no vale para firmar dentro de un formulario de la sede, no funciona con DNIe ni tarjetas, y hace una firma por documento, sin sello de tiempo.

Si el fallo de Autofirma se producía con un certificado de tarjeta, FirmaLocal no te sirve: necesitas que el controlador funcione o un certificado de la FNMT en fichero.

Comprobar que la firma vale

Con Autofirma o sin ella, comprueba el resultado antes de presentarlo. Sube el PDF a VALIDe y confirma que reconoce la firma y el certificado. Si quieres ver más detalle —el algoritmo usado, la cadena de confianza—, las tres formas de hacerlo están en Cómo saber si una firma digital es válida.

Fuentes

FirmaLocal genera firmas electrónicas avanzadas basadas en certificado cualificado (PAdES-B-B), la misma clase de firma que produce Autofirma con un certificado software. No sustituye a la firma con DNIe ni a la autenticación dentro de una sede electrónica. FirmaLocal no presta asesoramiento jurídico.