Certificados y custodia: quién remite ante Hacienda
La parte de VeriFactu que no es técnica, sino jurídica: quién tiene derecho a hablar con Hacienda en nombre de quién.
Antes de nada: en VERI*FACTU no se firma cada registro
Es la confusión terminológica que más ruido genera, y conviene quitarla de en medio en el primer párrafo.
Los sistemas VERI*FACTU no están obligados a aplicar una firma electrónica explícita a cada registro de facturación. Lo que se exige es que el registro se remita a la AEAT, y esa remisión viaja por un canal autenticado con un certificado electrónico cualificado. La autenticación es del envío, no del registro.
La firma electrónica registro a registro es un requisito de los sistemas NO VERI*FACTU: como no remiten, necesitan otra manera de acreditar que el registro no se ha alterado. Junto con el registro de eventos, es una de las dos cargas que la modalidad VERI*FACTU te ahorra.
Dicho esto, sigue habiendo un certificado de por medio y sigue habiendo que decidir de quién es. De eso va el resto del artículo. Por comodidad de lectura hablaremos de «firmar el envío», que es lo que técnicamente ocurre en el TLS y en la cabecera del mensaje SOAP.
Ser el fabricante del software no te autoriza a nada
Es la confusión más cara de todas, y conviene dejarla clara antes de escribir una línea de código.
La declaración responsable dice quién fabrica el programa. El apoderamiento dice quién puede presentar en nombre de quién. Son dos papeles distintos, con dos trámites distintos, y tener el primero no te da el segundo.
Puedes tener tu declaración responsable impecable, tu XML perfecto y tu huella contrastada, y aun así ver cómo la AEAT rechaza el envío porque no consta que puedas presentar por ese contribuyente.
Las dos modalidades de remisión
En representación
Remites tú, con tu certificado, por cuenta de tu cliente. En la cabecera del mensaje va el
ObligadoEmision (tu cliente) y detrás el Representante (tú).
Requiere que el cliente haya otorgado un apoderamiento inscrito en la AEAT, o que tú actúes como colaborador social. Sin ese papel, la AEAT no te reconoce como presentador.
Ventaja: el cliente no necesita certificado digital ni sabe que existe todo esto. Para un SaaS de negocios pequeños es la diferencia entre que la funcionalidad se use o no se use.
En nombre propio
Remite el propio obligado, con su certificado. No hay bloque Representante en la
cabecera, ni apoderamiento que gestionar.
Ventaja: cero fricción jurídica, la relación con Hacienda es del cliente. Inconveniente: alguien tiene que custodiar y renovar ese certificado.
Tipos de certificado (y por qué cambia el endpoint)
- Persona física o representante — el caso habitual.
- Sello de entidad — pensado para procesos automatizados sin persona detrás.
Importa más de lo que parece: el servicio web de la AEAT expone puertos distintos según con qué firmes el TLS. Los certificados de sello van a un host distinto del de los certificados normales. Si te equivocas de puerto, no es que te rechacen el mensaje: es que ni siquiera llegas.
Custodiar el certificado de otro
Si eliges la modalidad de nombre propio y guardas el .p12 de tus clientes, asume lo
que eso significa: ese fichero es una llave que ante la AEAT sirve para casi todo,
no solo para VeriFactu.
El mínimo defendible:
- El fichero cifrado y fuera del árbol web. Nunca en la base de datos, nunca accesible por URL.
- La contraseña cifrada con una clave que no viva en la propia base de datos.
- Permisos de fichero restrictivos (
0600) y un.htaccessde negación como red de seguridad por si el directorio acaba dentro del webroot. - Leer el NIF de dentro del certificado y contrastarlo con el del cliente, para que nadie pueda subir el certificado de un tercero.
- Consentimiento informado explícito, y a ser posible reflejado en el contrato, no solo en una casilla.
Y avisa de la caducidad
Un certificado caducado no da un error elegante: da un fallo de TLS que, según cómo esté escrito tu cliente HTTP, puede parecer cualquier otra cosa. Guarda la fecha de caducidad al subirlo y avisa con semanas de antelación.