Proteger el certiticado digital

[wilecoyote]

Buenas:


Soy nuevo en el foro, y antes que nada: menos mal que he encontrado un sitio en castellano donde intercambiar información técnica sobre este tema.


Al grano: la aplicación de facturación que estoy desarrollando/manteniendo para mi cliente es una aplicación 100% web, y me encuentro con que para conectar con la AEAT, necesito instalar en dicha web el certificado digital del cliente (o el mío, si actúo como colaborador social). La verdad es que me da terror la idea de dejar subido un certificado digital en un hosting web, por las razones obvias que se puede imaginar cualquiera si un tercero consigue hacerse con él.


Existen diversas formas técnicas de proteger un certificado en estos casos:

• Poner el certificado en un directorio fuera del webroot (no accesible desde la web).
• Capar los permisos del archivo para que solo pueda ser accesible por el proceso web.

Etc., etc., pero al final, no me acabo de fiar.


Se me ha ocurrido una solución, pero no sé si será posible, y esa es la razón por la que escribo aquí: ¿sería posible contratar un certificado digital que no fuera el de la FNMT, de forma que solo sirviera para autenticarse ante la AEAT para esto de Verifactu, pero no sirviera para otros fines? En otras palabras, un certificado que no le sirviera a un tercero para presentar documentos a la Adm. Pública, ni acceder a la Seguridad Social, ni..., sino únicamente para esto de Verifactu. ¿Existe semejante cosa?

He visto que en la web de la AEAT hay listados varios proveedores de certificación, además de la FNMT. ¿Hay algún otro que cumpla esa condición?



En su defecto, aquellos que estéis desarrollando aplicación de facturación que corran también en entorno web, ¿cómo lo hacéis para proteger el certificado digital?


Gracias.

[CarlosArjonomia]

Yo lo estoy solucionando haciendo un servidor en local con python que me firma en local (no hace falta subir ningún certificado a tu servidor), y luego envío al servidor remoto el xml ya firmado y procedo a enviar a verifactu.

Si tienes dudas plantéale el tema que te he comentado a chatGPT y te dará muy buenas soluciones para adaptarlo a tu sistema.

[wilecoyote]

Ya, pero el tema es que hace falta un certificado digital en el cliente SOAP para conectar con el servidor de la AEAT. No se trata ya de firmar, es que el cliente que conecta con la AEAT tiene que tener certificado.

[dec]

Hola a todos,

Sin ser un experto, yo creo que ya estás enfocando el asunto de forma correcta. Si guardas el archivo / certificado fuera del "directorio público", en principio, nadie podrá acceder a ese archivo, salvo quien tenga acceso al propio servidor. Pero, entiendo ahora (según escribo esto) que acaso pueda preocuparte incluso el acceso a ese archivo por parte de quien gestione el servidor... supuesto que este sea un servidor "compartido".

No sé realmente cómo se utiliza el archivo / certificado en cuestión, esto es, ¿podría acaso cifrarse el archivo y descifrarse únicamente cuando se vaya a utilizar? Supongo que estamos hablando de un sitio web al que se accede mediante usuario y contraseña, entonces, acaso podría usarse como contraseña para cifrar el archivo la propia contraseña del usuario: la idea es que la contraseña no esté disponible para nadie en el servidor, pues, estaríamos en las mismas que con el propio archivo.

En fin, no sé si lo dicho te sirve de algo, puesto que, como me parece que enfocas bien el tema, seguramente, ya has pensado en la posibilidad que yo estoy sugiriendo.

[delphiGar]

Si el certificado lo tienes protegido con contraseña, que es lo mas normal, aunque el archivo te lo cojan no les servira para nada si no saben esa contraseña necesaria para poder utilizarlo en cualquier sitio.

[dec]

Hola a todos,

Empezado por delphiGar

Si el certificado lo tienes protegido con contraseña, que es lo mas normal, aunque el archivo te lo cojan no les servira para nada si no saben esa contraseña necesaria para poder utilizarlo en cualquier sitio.

Esa es la idea de cifrar el archivo, aunque, una cosa no quite la otra: el archivo para mí no debería ser público... sólo debería poderse acceder al mismo desde el servidor, lo que pasa es que, por si se considerase que eso mismo también pudiera ser un problema, de ahí el hecho de sugerir su cifrado, para que así, incluso si alguien accediese al archivo, desde el servidor, no pudiera realmente acceder a su contenido.

Por otro lado, aunque sea más o menos banal, dicho archivo podría estar guardado en alguna carpeta y con un nombre que tratase también de no indicar de qué tipo de archivo se trata. Dicho al contrario, no guardar el archivo en una carpeta tal que "certificado" y con un nombre tal que "certificado-cliente.crt". Se trata de ofuscar un poco el emplazamiento del archivo, el nombre del propio archivo e incluso su extensión, evitando dar pistas sobre su función.

[wilecoyote]

Normalmente los certificados están cifrados, sí. El problema es que, para que el software pueda usarlo, hace falta que éste "conozca" la clave para descifrarlo.

Una solución sería la que propones: que cada vez que haya que emitir una factura, el usuario final tenga que meter la clave... ¿pero qué pasa si, por ejemplo, hay una tarea automatizada que se dedica a enviar automáticamente las facturas que han quedado pendientes de enviar? (por errores técnicos, incidencias, caída de Internet... lo que sea). El software tendría que guardar la clave en algún sitio (no vamos a pedirle la clave al usuario cada minuto...).

Al final, se me ocurren pocas cosas más que la mencionada antes: asegurar lo máximo posible el servidor, tomar las precauciones habituales en entornos web y rezar mucho.

[dec]

Hola a todos,

Respecto de la pedir la contraseña al usuario cada minuto... claro... es que depende de cómo está "montado" el asunto: ciertamente, puede ser problemático, puesto que, la idea de pedirle la contraseña al usuario, es no utilizar ninguna "guardada", por supuesto, tampoco el "hash" de la contraseña guardado en la base de datos: se trata de pedírsela para que nadie más que el usuario pueda conocerla.

Quizás, en algún caso, pueda bastar con guardar la contraseña en la sesión de usuario (hablando de PHP, en la variable $_SESSION), pero, como digo, es cierto que esto puede no ser suficiente en todos los casos... puede que complique el asunto para algunas tareas como las que mencionas: lo que está claro es que guardar la contraseña en el servidor, sería casi como decirle al "malo" cómo descifrar el archivo del certificado.

[bmfranky]

Empezado por dec

Hola a todos,

Respecto de la pedir la contraseña al usuario cada minuto... claro... es que depende de cómo está "montado" el asunto: ciertamente, puede ser problemático, puesto que, la idea de pedirle la contraseña al usuario, es no utilizar ninguna "guardada", por supuesto, tampoco el "hash" de la contraseña guardado en la base de datos: se trata de pedírsela para que nadie más que el usuario pueda conocerla.

Quizás, en algún caso, pueda bastar con guardar la contraseña en la sesión de usuario (hablando de PHP, en la variable $_SESSION), pero, como digo, es cierto que esto puede no ser suficiente en todos los casos... puede que complique el asunto para algunas tareas como las que mencionas: lo que está claro es que guardar la contraseña en el servidor, sería casi como decirle al "malo" cómo descifrar el archivo del certificado.

Hola, simplemente usa la contraseña de inicio de sesión del mismo usuario, para des proteger el certificado, mientras dure la sesión operativa , puedes tener en una variable el certificado , en modo array de bytes y des encriptarlo usando como clave el password + usuario, el certificado lo puedes cargar y guardar en un arreglo de bytes, en la carpeta personal del usuario, así lo tienes fácil para acceder al mismo, cuando este caducado, lo actualizas, al estar encriptado , es mas difícil que aunque puedan acceder al fichero , puedan hacer algo con el, aunque seguridad 100% ninguna, siquiera en una aplicación de escritorio.

[raulgov]

Hola todos,

No tengo tan claro que podamos almacenar los certificados digitales de nuestros clientes así de fácil en la base de datos o en directorios del servidor, etc, aunque los encriptemos. Me refiero a entornos SaaS (alguno comenta PHP y doy por supuesto que será web/cloud) y no aplicaciones de escritorio.

Lo digo por el tema del reglamento eiDAS que requiere de gestión de certificados digitales bajo hardware HSM y cosas así, o eso tengo entendido.

Nosotros estamos ahora buscando posibles proveedores para la gestión externa de certificados y firma de documentos sin que tengamos que almacenar nosotros los certificados. Pero entre tanto proveedor con precios opacos, disparatados o nada claros, se nos hace un mundo este tema.

Sé que hay algunos programas (incluso en modo SaaS) que hacen doble encriptado y cosas así pero los almacenan en su base de datos/servidor y ya no cumple estrictamente con el eiDAS (o eso creo).
No creo que pedir la contraseña del certificado pueda ser viable para facturar, ya que eso es darle muchos privilegios a cualquier empleado que facture (pensad simplemente en simplificadas).

Se nos va a hacer muy costoso si no podemos almacenar nosotros los certificados digitales de nuestros clientes aunque los encriptemos por separado la clave privada y la contraseña para:
- firmar registros de facturación (en modo No Verifactu),
- comunicarnos con AEAT con el certificado del cliente,
- o firmar logs de auditoria de elementos prefacturables (pedidos, albaranes, cobros, etc como dicen en los webinars el técnico de Hacienda para los requisitos que garanticen los principios de Integridad, Inalterabilidad, Trazabilidad, Accesibilidad, Legibilidad y Conservación de la ley Antifraude).

No digamos ya cuando tengamos que firmar facturas digitales sí o sí con la Ley Crea y Crece. Estoy hablando de miles de euros al año en costes para pagar a proveedores eiDAS que gestionen externamente los certificados y que casi todos cobran a razón de documento/registro firmado. Imaginad un cliente que facture fácilmente 15.000 facturas lo que puede costar.

He visto que se puede mandar firmar con la aplicación AutoFirma mediante el protocolo afirma:// y que se abre la aplicación AutoFirma, se firma y devuelve el doc firmado a una URL de nuestro servidor con el documento firmado, pero no lo he probado (quizá sea invento de chatgpt) y no valdrá para procesos automatizados o incluso que cualquier currito sin el certificado de la empresa instalado en el PC no podrá facturar.

Decidle a vuestros clientes que por cada factura que emitan van a pagar ahora X,XX€... ya sé donde nos mandarán.

¿Cómo lo veis vosotros?
¿Alguien que haya indagado el tema eiDAS y sepa con certeza la posibilidad de almacenar en servidor (principalmente SaaS) certificados de nuestros clientes sin todo el tema eiDAS?

A ver si estamos aquí todos luchando con el nuevo invento de Verifactu y nos vamos a meter en un marrón con el eiDAS.

[dec]

Hola a todos,

Empezado por raulgov

Hola todos,

No tengo tan claro que podamos almacenar los certificados digitales de nuestros clientes así de fácil [...]

Creo que el compañero ha tocado puntos muy importantes. En efecto, acaso ya no es intentar conseguir algo "más o menos" (cosa que, por cierto, no hemos aclarado al final cómo conseguirlo), sino que, desafortunadamente, lo "conseguido" no cumpla con ningún estándar de seguridad, y, que esto, pueda realmente no ser válido, incluso legalmente... Ojo que esto puede ser un verdadero problema: acaso no si "nada falla", pero, en caso de que alguien pueda acceder a los certificados... no será posible "escudarse" en que ha "fallado" ningún estándar, sino, nuestro propio sistema de seguridad, y, tal vez esto signifique pagarlo muy caro...

[[newtron]]

Yo creo que estamos enredando demasiado con este tema. ¿La cosa no se soluciona firmando un contrato de "envío por terceros" con el cliente y haciendo el envío con el certificado de la empresa proveedora del software?


Saludos.

[raulgov]

Empezado por newtron

Yo creo que estamos enredando demasiado con este tema. ¿La cosa no se soluciona firmando un contrato de "envío por terceros" con el cliente y haciendo el envío con el certificado de la empresa proveedora del software?


Saludos.

Está claro que es necesario un contrato con el cliente para que nos autorizase a enviar por terceros, pero además de eso es preciso un Apoderamiento o ser Colaborador social ante la AEAT si se quiere hacer las cosas bien.

En principio no vale con que mi cliente me autoriza y yo firmo con mi certificado digital sus facturas.
Que se haga no quiere decir que esté bien hecho desde el punto de vista normativo. Sobre todo cuando entra en la fórmula el eiDAS dichoso.

Por otro lado está la controversia de que el cliente no quiere que aparezca en sus facturas una empresa de software que sus clientes verán cuando reciban el PDF firmado de la factura y vean quien firma (esto nos puede pasar también con las empresas que ofrecen APIs externas de Verifactu tipo fiskaly). Entonces aquí te obliga a firmar con su certificado digital.

Por otro lado seguimos teniendo el mismo problema de guardar un certificado digital en un servidor remoto, aunque sea el nuestro propio. El tema de la gestión externa de certificados es precisamente para que no puedan robarte el certificado (no sale del hardware HSM por así decirlo y queda una auditoría de uso) porque luego a ver cómo demuestras que no has sido tú el que ha firmado XX cosa.

Hacerlo se puede hacer, eso está claro y de hecho casi todos los SaaS de facturación que hagan FacturaE lo estarán haciendo ahora mismo. Pero la cuestión no es que se pueda, es que sea legal y que cumplas la normativa eiDAS que ha venido (ya hace tiempo) para terminar de rematarnos y tocar las narices.

Estoy pensando en las asesorías que tienen 1000 certificados de sus clientes instalados en 8 ordenadores de la asesoría y que toquetea todo el mundo que pasa por allí.
Que lo hacen, sí, que deban hacerlo sin registro y auditoría, no.

Si no, el día que llamen a tu puerta con una inspección te puedes encontrar un pastel muy gordo sin poder reaccionar, sobre todo cuando no eres una multinacional y que te sancionen signifique el cierre de la empresa.

Este hilo trata de proteger el certificado digital, y ya que debatimos, entiendo que todos queremos protegernos al máximo teniendo en cuenta toda normativa que le afecte y no solo a nivel técnico del proceso de firmar en sí, ya sea en delphi, PHP o lo que sea. Eso cualquiera de los aquí presentes podrá hacerlo fácilmente, pero ¿será legal como lo estamos haciendo?

También se puede hacer y cruzar los dedos .

[dec]

Hola a todos,

Empezado por raulgov

[...] También se puede hacer y cruzar los dedos .

Uno diría, que, si existe una forma de hacerlo legalmente, así tiene que ser como debe hacerse, ¿no? Ojo, no sólo porque sea lo legal, sino también lo más conveniente para todos: entiendo que si un certificado se usa maliciosamente, esto puede ser muy gravoso para nuestro cliente y para nosotros mismos.

Entonces, si existe una forma legal, acaso implementando la normativa eiDAS nosotros o mediante un servicio de terceros que la implemente por nosotros, pues eso será lo que hay que hacer: tenga el coste que tenga, que, por supuesto, el cliente tendrá que asumir, proporcionalmente.

Pero el cliente en todo momento estará informado del precio a pagar por todo esto, o sea, el cliente debe comprender que se trata de la forma legal, para que su certificado y/o el nuestro, así como todo el proceso de firma, cumplan con la legalidad. Claro que tendrá un coste, pero, es como cualquier otra cosa, si se piensa: se paga mucho para mantenerse uno en la legalidad.

Así la cosa, y, si lo que digo tiene alguna lógica, tal vez en este hilo debería poder aclararse cuál es la forma legal de hacer lo que se necesita hacer, independientemente de su coste, cuál es la manera de cumplir con la normativa para que tanto el cliente como nosotros estemos cumpliendo con todo lo necesario para llevar a cabo estas tareas tan delicadas.

Lamentablemente, ahí no puedo decir ni mú... vaya que no sé cuál es la forma ni su costo ni nada de nada... (tal vez algo apuntó raulgov arriba)...

P.D. Al cliente siempre se le podrá decir que el coste tiene su razón de ser: que por supuesto puede optar por un software más barato, pero, que se atenga a las posibles consecuencias... que puede tener unas consecuencias mucho más gravosas que lo que se ahorre con el software que no cumple con la legalidad.

[wilecoyote]

Buenas:

He estado leyendo con atención lo que comentáis, y me he planteado una pregunta quizá temeraria: ¿hasta qué punto es necesario cumplir de verdad con la normativa eiDAS? ¿Qué es lo que dice la normativa eiDAS?

Como soy un ignorante en el tema legal, le he subido la orden ministerial del Verifactu a ChatGPT y le he estado preguntando. Si hay errores aquí abajo (que es ChatGPT, después de todo), por favor corregidme.

"eIDAS establece requisitos estrictos de seguridad para el almacenamiento de certificados digitales cualificados, especialmente cuando estos son gestionados por un Prestador Cualificado de Servicios de Confianza (PCSC) (...) Las claves privadas asociadas a certificados cualificados de firma electrónica deben ser generadas y almacenadas en dispositivos seguros, llamados QSCD (Qualified Signature Creation Devices). (llaves USB seguras, tarjetas criptográficas...)


Es decir, tal como lo entiendo yo, si el certificado es cualificado, la clave que lo protege no puede estar guardada por ahí en ningún sitio: tiene que estar en un dispositivo seguro y no salir de ahí.

Ahora bien, el certificado digital que tenemos instalado todos para entrar por ejemplo en la Seguridad Social, ¿es cualificado?

"Por defecto, los certificados FNMT emitidos a través del navegador no incluyen un QSCD, por tanto permiten firma avanzada, pero no cualificada (...) Con él, estás haciendo una firma electrónica avanzada (FEA), no cualificada.
Sigue siendo legal y válida, y muchas administraciones la aceptan (de hecho, la mayoría de los trámites en España se hacen así). Pero no tiene la presunción legal de equivalencia con la firma manuscrita que tiene la firma electrónica cualificada (FEQ).
(...)
Para obtener un certificado cualificado de verdad, Tienes varias opciones: 1) Solicitar el certificado FNMT en tarjeta criptográfica (y usar un lector). La clave privada no es exportable, y el dispositivo está certificado como QSCD.
2) Usar firma en la nube cualificada (firma remota) con prestadores como Camerfirma, Firmaprofesional, etc. La clave se guarda en un HSM certificado, y tú te autenticas cada vez con doble factor (OTP, app, etc.)
"


Lo que me lleva a la pregunta: en el caso de Verifactu, ¿es obligatorio usar un certificado cualificado, o basta con usar uno "avanzado", es decir, en la misma modalidad en la que usamos el certificado en el navegador?

"Artículo 14. Firma electrónica de los registros de facturación y de evento.
En todo caso, la firma electrónica deberá ser generada con una clave privada asociada a un certificado electrónico cualificado de firma electrónica en vigor. "
(...)
Artículo 5. Para remitir los registros de facturación a la sede electrónica de la Agencia Estatal de Administración Tributaria, los sistemas informáticos deberán presentar ante esta la correspondiente identificación electrónica del remitente mediante el uso de los certificados electrónicos válidos en cada momento en la sede electrónica de la Agencia Estatal de Administración Tributaria. Además, dichos certificados electrónicos deberán ajustarse a las condiciones que se establezcan en la normativa vigente en cada momento en relación con los atributos mínimos que deben incluir los certificados electrónicos cualificados y los mecanismos que permiten verificar su vigencia y contenido en el ámbito de las Administraciones Públicas."


Tal como lo entiendo yo, para enviar las facturas a la AEAT, nuestro software no necesita un certificado cualificado (aunque puede usarlo). Sin embargo, para firmar los XML y guardarlos localmente sí es necesario.

Ahora bien: si nuestro SIF funciona solamente en modo Verifactu, no es obligatorio guardar los registros de facturación localmente ni firmarlos ni nada, con lo cual no necesitarías el certificado cualificado.

(Esto explicaría cómo funcionan esas empresas que ofrecen APIs externas para integrar con Verifactu: como dicen ellos mismos en las FAQs de sus webs, presentan las facturas a la AEAT con su certificado de colaborador social, pero luego ellos no las guardan ni las firman...).

Repito que lo de arriba es la interpretación que me ha dado ChatGPT. Agradezco correcciones.

[emailesc]

Nosotros en las pruebas estamos utilizando un certificado de representante de la empresa de la FNMT. Por lo que he estado mirando con ChatGPT es certificado cualificado, y mientras esté en el almacén de certificados de Windows vamos mas o menos bien, al menos para enviar registros propios. La cosa se complica con los certificados de los clientes, ya no solo por el almacenarlos, si no por el obtenerlos: lo de navegar por los proveedores para obtener un sello de empresa, que parece lo más adecuado es una auténtica gincana: identificaciones por videoidentificación que no funciona (Izempe, y pasan de ti cuando les llamas), necesidad de de generar CSR (FNMT, explicáselo a un cliente), páginas en las que cada uno le llama de una manera, cincuenta tipos de certificados (y ahora además lo de cualificados y no cualificados), faltan enlaces, no ponen precios, sin documentación del proceso, y precios que triplican y cuatriplican los de otros y lo que ya es el despiporre, proveedores de certificados digitales que no te permiten identificarte con un certificado de representante, hay que ir a la videoidentificación... Es para nosotros y al final he desistido por ahora del sello... explicárselo a un cliente que no tengo conocimientos de estos temas va a ser complicado. Yo me estoy planteando dos escenarios: lo del colaborador social (lo mas probable), ya que la final respondemos para la parte técnica del envío y en esa tenemos responsabilidad de todas maneras (además podemos pedirles a los cliente que obtengan un sello de empresa para sus firmas, y así valorarán mas el servicio de enviárselo nosotros), o bien instalar un componente en un ordenador del cliente y que desde este consulte con nuestra base de datos y desde allí (su ordenador del cliente) envíe y firme los documentos. Ya usamos algo parecido para otras cosas y funciona bien. Y si los precios de los Prestadores Cualificados de Servicios de Confianza con custodia de clave fuese barato pues también sería una opción.