menu di navigazione del network

Firma automatica File PA : Apache


(Mw Space Llc) #21

Carlo,

!! I certificati dello sdiCoop non firmano i file.

Con il comando :
openssl smime -binary -nodetach -sign -signer SDI-xxxxxxxxxxxxx.pem -inkey mykey.key -in ITxxxxxxxxxxxxxxxx_382.xml -out out.xml.p7m -outform DER

Stai firmando un file con un certificato server. NON HA SENZO!

Prima che impazzisci, i CERTIFICATI con cui devi firmare i file li Hai solamente accreditando il canale SDIFTP


(Carlo Zanatto) #22

infatti…immaginavo. Procedo accreditando anche questo.

Vediamo se, prima o poi, ne vado fuori. Grazie intanto


(Ephraim Pepe) #23

Mi metto in coda per capire meglio, perché l’argomento mi interessa molto.

Cosa intendi per “estrarre correttamente i certificati da un agglomerato”?
Noi siamo alle prime armi per quantori guarda la gestione di certificati, e abbiamo fatto fatica per comunicare con il SDI. Abbiamo provato anche a recuperare i certificati dalla smartcard, ma non abbiamo avuto fortuna, quindi per ora chiediamo al nostro cliente di fare il download dei file xml, firmarli e caricarli nuovamente sul loro portale che poi pensa a inviarli, ma la soluzione non ci piace…
La procedura è soggetta a errori umani e vorrei minimizzarli il più possibile.

Quindi vorrei capire quali certificati usare ed eventualmente come ottenerli.

Mi ero iscritto a Forum Italia proprio per fare questa domanda, ma esistendo già questo thread…

Grazie!!!


(Mw Space Llc) #24

Ciao Ephraim Pepe,

Per “Agglomerato”, Intendo PKCS#12 / PFX
Il formato PKCS#12 o PFX è un formato binario che permette di salvare in modo criptato sia il certificato server e quelli intermedi, che la chiave privata. L’estensione utilizzata è solitamente .pfx o .p12 . I file PFX sono di solito usati su macchine Windows per effettuare backup e migrazioni da un server all’altro di certificati con le loro rispettive chiavi private.

Per quanto riguarda i certificati, ti chiederei di attendere la nostra Uscita da FASE di Test a PRODUZIONE.

Non dovrebbero esserci problemi ma non vorrei aggiornare il Thread in maniera sbagliata. Voglio realmente verificare la firma anche in produzione.
Poi condividerò una piccola guida su come :

  1. Avvalersi di Certificati di Firma (NON Entratel)
  2. Estrazione e Compilazione dei formati .pem
  3. Firmare e creare (con OpenSSL) un .p7m firmato CAdES (php o unix)
  4. Estrarre (con OpenSSL) un file da .p7m firmato CAdES (php o unix)

AGGIORNEREMO IL TREAD IN PRODUZIONE.

**Per chi volesse proseguire autonomamente:

  1. Accreditare (SDIFTP)
  2. Compilare un modulo e preparare ambiante SFTP (Noi usiamo Debian)
  3. Ricevuti i file di firma, LEGGERE ATTENTAMENTE LA GUIDA DI SOGEI per firmare i file.
  4. Firmare una fattura di test (FRPA12)
  5. Verificarla sul sito o inviarla in Test a SDI

!!Attenzione. La guida è datata. I comandi non funzioneranno nelle nuove versioni di **OpenSSL**. Assicurarsi di riposizionare l'inserimento deli (argomenti) secondo la propria versione di OpenSSL


(Leonardo Secci) #25

Buongiorno a tutti,

fate attenzione perché quello che è stato esposto a mio avviso va in violazione di quanto previsto dalla specifica.

Sul punto se si tratta di FatturaElettronica verso PA (FPA12), la specifica 1.2.1 (https://www.fatturapa.gov.it/export/fatturazione/sdi/Specifiche_tecniche_del_formato_FatturaPA_v1.2.1.pdf) prevedono che:

 La fattura elettronica è intesa come un documento informatico non contenente
codice eseguibile né macroistruzioni; su di esso può essere apposta:
- firma digitale (obbligatoria nei casi di fattura destinata ad una Pubblica
Amministrazione) che garantisce autenticità dell’origine e integrità del
contenuto;
- firma XAdES con certificato di firma CA Agenzia delle Entrate (il cosiddetto
“sigillo” apposto dal sistema “Fatture e Corrispettivi”), che garantisce la sola
integrità del contenuto (ammesso nei soli casi di fattura destinata a privati).

Le specifiche 1.6 del sistema di interscambio (https://www.fatturapa.gov.it/export/fatturazione/sdi/Specifiche_tecniche_SdI_v1.6.pdf) invece dettagliano meglio che:

Il SdI accetta come fattura elettronica un documento informatico che:
- se destinato ad una pubblica amministrazione (art.1, comma 211, legge 24
dicembre 2007 n. 244), sia provvisto di un riferimento temporale e firmato
elettronicamente tramite un certificato di firma elettronica qualificata, non
contenente macroistruzioni o codici eseguibili tali da attivare funzionalità che
possano modificare gli atti, i fatti o i dati nello stesso rappresentati;
- se destinato ad un soggetto diverso da pubblica amministrazione (art. 1,
comma 2, decreto legislativo 127/2015), sia firmato o secondo la modalità
precedente, oppure in formato XAdES con certificato di firma CA Agenzia
delle Entrate.
Nel primo caso, il certificato di firma elettronica qualificata deve essere rilasciato da
un certificatore accreditato, presente nell’elenco pubblico dei certificatori gestito
dall’Agenzia per l’Italia Digitale così come disciplinato dall’art. 29, comma 1, del
DLGS 7 marzo 2005 n. 82 e successive modifiche. I formati ammessi per firmare
elettronicamente la fattura sono i seguenti:
- CAdES-BES (CMS Advanced Electronic Signatures) con struttura aderente
alla specifica pubblica ETSI TS 101 733 V1.7.4, così come previsto dalla
normativa vigente in materia a partire dal 1 settembre 2010;
- XAdES-BES (XML Advanced Electronic Signatures), con struttura aderente alla
specifica pubblica ETSI TS 101 903 versione 1.4.1, così come previsto dalla
normativa vigente in materia a partire dal 1 settembre 2010;

Conseguentemente se la FatturaElettronica va a una PA la firma può essere CAdES o XAdES ma il certificato di firma dovrà essere necessariamente qualificato.

Parrebbe inoltre che se dovesse essere possibile utilizzare il certificato non qualificato “CA Agenzia delle Entrate” il formato di firma non potrebbe che essere XAdES (sigillo).

Quest’ultima cosa però sembrerebbe andare in contraddizione con quanto previsto dalle specifiche 1.3 per la FE tra privati (FPR12) ( https://www.agenziaentrate.gov.it/wps/file/Nsilib/Nsi/Schede/Comunicazioni/Fatture+e+corrispettivi/Fatture+e+corrispettivi+ST/ST+invio+di+fatturazione+elettronica/ST+Fatturazione+elettronica+-+Allegato+A/Allegato+A_Specifiche+tecniche+vers+1.3.pdf) infatti in questo caso:

Il SdI gestisce sia fatture elettroniche prive di firma elettronica che fatture
elettroniche alle quali sia apposta firma elettronica.
Nel caso si scelga di apporre la firma elettronica, il SdI verifica che le fatture
elettroniche siano:
- firmate digitalmente con certificato di firma elettronica qualificata
rilasciato da un certificatore accreditato, presente nell’elenco
pubblico dei certificatori gestito dall’Agenzia per l’Italia Digitale così
come disciplinato dall’art. 29, comma 1, del DLGS 7 marzo 2005 n.
82 e successive modifiche. I formati ammessi per firmare
elettronicamente la fattura sono i seguenti:
o CAdES-BES (CMS Advanced Electronic Signatures) con
struttura aderente alla specifica pubblica ETSI TS 101 733
V1.7.4, così come previsto dalla normativa vigente in materia
a partire dal 1 settembre 2010;
o XAdES-BES (XML Advanced Electronic Signatures), con
struttura aderente alla specifica pubblica ETSI TS 101 903
versione 1.4.1, così come previsto dalla normativa vigente in
materia a partire dal 1 settembre 2010;
- firmate in formato CAdES con certificato di firma elettronica rilasciato
dall’Agenzia delle Entrate. Il certificato è rilasciato agli utenti del
Servizio Entratel e utilizzato sui propri sistemi ovvero sul proprio PC
attraverso Desktop telematico o Entratel Multifile. Si ricorda che
l’Agenzia delle Entrate non è una Certification Authority qualificata e
che, pertanto, la verifica di una firma elettronica basata sulle chiavi
pubbliche di firma e cifratura rilasciate dall’Agenzia delle Entrate
evidenzierebbe che la CA non è affidabile. E’ quindi opportuno che
chi appone tale tipo di firma elettronica sulle fatture che emette renda
consapevoli i propri clienti di questa circostanza e del fatto che la
verifica di questo tipo di firma può essere fatta solo utilizzando il
servizio di verifica di Agenzia delle Entrate
(https://telematici.agenziaentrate.gov.it/Abilitazione/IVerificaFile.jsp).

Conseguentemente in questo caso è possibile o no firmare la FE sia con certificato qualificato (CAdES o XAdES) che con “CA Agenzia delle Entrate” ma solo come CAdES (sigillo).

Concludendo, se è vero che per FE verso PA, occore la firma digitale (ovvero con certificato qualificato) si potrebbe anche scegliere di usare OpenSSL a patto che:

  1. Sia in grado di costruire una firma CAdES-BES, e ad oggi questo è possibile solo con delle patch (es. https://www.blia.it/firmadigitale/)
  2. Si disponga di un dispositivo sicuro di firma con un certificato qualificato istallato (Smartcard, HSM, forse anche Firma Remota)

OBIEZIONE: Ma lo SdI me lo accetta, allora va bene…
RISPOSTA: Evidentemente il servizio di verifica dello SdI non implementa completamente la specifica, con tutte le contraddizione che si palesano non mi sembra che questo sia il problema più rilevante


(Mw Space Llc) #26

Bene leonardo!
Grazie per averci informato di “COSE CHE SAPPIAMO”

:man_technologist: Riporterò ulteriori aggiornamenti in fase di produzione

INFO:
Da quanto riportato nei tuoi lunghi testi, si precisa infine CHE:

  • firmate in formato CAdES con certificato di firma elettronica rilasciato
    dall’Agenzia delle Entrate. Il certificato è rilasciato agli utenti del
    Servizio Entratel e utilizzato sui propri sistemi ovvero sul proprio PC
    attraverso Desktop telematico o Entratel Multifile.

RISPOSTA:
(LO SDI TI RILASCIA I CERTIFICATI PER LAVORARE IN SFTP, CHE FACCIO LI BUTTO ?:joy:)

  • Si ricorda che
    l’Agenzia delle Entrate non è una Certification Authority qualificata e
    che, pertanto, la verifica di una firma elettronica basata sulle chiavi
    pubbliche di firma e cifratura rilasciate dall’Agenzia delle Entrate
    evidenzierebbe che la CA non è affidabile. E’ quindi opportuno che
    chi appone tale tipo di firma elettronica sulle fatture che emette renda
    consapevoli i propri clienti di questa circostanza e del fatto che la
    verifica di questo tipo di firma può essere fatta solo utilizzando il
    servizio di verifica di Agenzia delle Entrate
    (https://telematici.agenziaentrate.gov.it/Abilitazione/IVerificaFile.jsp).

RISPOSTA:
(Mi sembra che c’è scritto come verificare comunque i certificati)

INFINE:
La nostra è stata una scoperta casuale, e pertanto ribadisco che non sappiamo ancora se in fase di produzione funzioni, ma gli Sviluppatori sono LIBERI di utilizzare le procedure che ritengono più opportune. Chi vuole, può installare la Pach openssl, Chi vuole firmare con smart card, è libero di farlo. Il nostro post NON vuole creare scompiglio, ma condividiamo con altri le nostre esperienze.
Detto ciò, torno a inviare fatture allo SDI con la tua fantastica OBIEZIONE: Ma lo SdI me lo accetta, allora va bene…
:grin::grin:


(Claudio Pizzillo) #27

Confermo quanto sopra scritto da Leonardo Secci,

con certificato Entratel è possibile firmare digitalmente solo in Cades le fatture b2b.

Le fatture b2B in firmate in Xades con certificato Entratel vengono rifiutate (CA non valida).

Le fatture alle PA solamente con certificato di firma qualificata.


(Romolo Manfredini) #28

Nel caso di fattura PA serve obbligatoriamente la firma qualificata.
Personalmente ho trovato il modo di automatizzare la firma tramite tokens usb e openssl 1.1.1 con una patch per il cms cades. (Patch portata da openssl 1.1.0) ed expect.
La patch è quella postata da Leonardo Secci, parte di quella patch è già stata integrata nell’ultima versione di openssl ma parte no.


(Federico Crepaldi) #29

A livello di velocità come funziona? Io avevo fatto dei test ma riuscivo a firmare sulle 25 fatture al minuto: troppo lento per le mie necessità.
Sarebbe figo forzare la smartcard ed estrarre la chiave privata ma non è questo il luogo più adatto per discuterne. :grimacing:


(Romolo Manfredini) #30

In media 60 fatture al minuto per singola chiavetta, ma ho parallelizzato per arrivare a 240 fatture al minuto che sono di più di quelle PA che fanno i miei clienti. Firmo solo le PA, le B2B finché non mi obbligano non le firmo.


(Leonardo Secci) #31

Ciao Federico,

  1. a titolo esemplificativo perché la cosa dipende da molte variabili e in special modo dal dispositivo di firma sicuro e dall’implementazione del PKCS11 che si interfaccia con l’ENGINE di openssl. Le smartcard sono sicuramente le più lente come dispositivo di firma e sinceramente non ho fatto test a riguardo, ma usando openssl con HSM, si può passare da 1-1,5 sec/sign a 0.13-0.4 sec/sign in funzione dell’HSM o della modalità di mantenimento della sessione del PKCS11.
  2. non puoi nemmeno immaginare di esportare la chiave privata da una smartcard accreditata per l’utilizzo per la firma qualificata, se fosse possibile cascherebbe la catena del trust e tutto il paradigma PKI, le smartcard e gli HSM accreditati fanno solo quello, ovvero proteggono la chiave privata in esso contenuta

Dubbio mio, ma davvero la tua applicazione deve firmare più di 25 fatture al minuto tutte dirette alla PA? Se così fosse le smartcard, come dispositivo sicuro di firma, sono poco appropriate, dovrai pensare più a un cluster di HSM con rilascio di un certificato qualificato per la firma di scopo o di soluzioni dedicate per la firma massiva.


(Leonardo Secci) #32

Ciao Romolo,

ho delle curiosità, se non vuoi/puoi rispondere non fa niente.

Su quale CA vi hanno rilasciato certificati per la firma digitale sulle delle chiavette USB?
Sono per firma di scopo/massiva?
Quale durata hanno i certificati?
Sai quanto possano costare?

Grazie mille


(Federico Crepaldi) #33

Ciao Leonardo!
1_Io ho testato una smartcard PostCert, ma ho abbandonato immediatamente per via della lentezza, quindi una smartcard di Aruba con la quale arrivavo in media a 25 fatture/minuto. In realtà l’idea era di firmare tutto, anche le FPR12. Per ora ho abbandonato l’idea, se in futuro renderanno obbligatoria la firma anche su quelle, mi dovrò attrezzare.
2_ Lo so che sono progettate perchè non sia possibile farlo e che da specifica così dev’essere… Però se si potesse avrei risolto in modo indolore il problema di cui al punto 1… :grimacing:


(Leonardo Secci) #34

Ciao Federico,

Valutare se è opportuno o no firmare con certificato qualificato per come la vedo io è un problema di assessment del processo nel suo complesso e la cosa è particolarmente critica se giochi nel ruolo di intermediario.

In special modo per la FPA12, se sei intermediario, non firmerei tanto alla leggera perché per la PA quella firma implica l’irripudiabilità ed è condizione necessaria per il pagamento per cui l’intermediario si prende una responsabilità non banale. Sarà lui a dover dimostrare che anche i dati della fattura forniti dal cedente sono irripudiabili. Se l’assessment non dovesse coprirmi da rischi chiederei al cedente di far firmare direttamente a lui la fattura così se ne prende anche tutte le responsabilità.

Per l’FPR12, a maggior ragione senza firma, di fatto non ci sono troppi problemi perché il processo di per se non è contrattualmente vincolante né per il cedente né per il cessionario al più ci potranno essere degli accertamenti da parte dell’Agenzia delle Entrate.


(Romolo Manfredini) #35

Per il punto 1 sono perfettamente d’accordo, l’agreement fra cliente ed intermediario deve prevedere manleve di responsabilità riguardo al contenuto della fattura e specificare che l’apposizione della firma digitale è solo finalizzata al completamento del processo di trasmissione qualora il documento inviato dal cliente non sia firmato.

Per il punto 2 allo stato attuale eviterei l’apposizione di una qualsiasi firma.

Rimane il punto che apporre una firma automaticamente richiede particolare cautela soprattutto se la firma non ha limiti di utilizzo.


(Leonardo Secci) #36

Ciao Federico,

Certamente contrattualmente puoi declinare ogni responsabilità su aspetti non inerenti l’accordo di servizio, ma in caso di controversie devi essere comunque in grado di dimostrare senza ogni ragionevole dubbio che il servizio si è comportato conformemente.
In caso di FPA12 la PA assume l’irripudiabilità della fattura sulla firma digitale apposta,
e su questo sistema costruisce anche il suo regolatore (centro dei costi) e l’erogazione dei pagamenti, l’irripudiabilità implica che il soggetto certificato (firmatario) non può negare di aver prodotto quel dato (integro).
Ora se il firmatario è l’intermediario deve mettersi nella condizione di ribaltare la certificabilità del soggetto cedente e l’integrità di quel dato altrimenti in caso di controversie tra cedente e PA l’intermediario rimarrebbe col cerino in mano.
Per FPR12 non essendoci a monte un castello come per la PA non si rischia molto, al più la fattura può essere considerata come una scrittura su un registro senza validità fiscale tant’è che in questo caso non hanno previsto neppure la Notifica Esito Committente.


(Mw Space Llc) #37

Buongiorno, :man_technologist:

Aggiorno intanto il thread per chi vorrebbe continuare a trovare un sistema di firma automatico (Apache) :v:

Come fatto presente da leonardo.secci, il sistema di firma tramite certificati SDIFTP. potrebbe comportare delle non conformità in fase di produzione alla verifica della firma. (NON CONFORME CADeS)

!!Ancora da scoprire il perchè il LA FATTURA (in fase di test) viene esitata e non scartata.

!FIRMARE LEGALMENTE DOCUMENTI CON APACHE IN REMOTO :
Se avete ormai costituito un servizio su APACHE o NGIX o ALTRO…
Vi basterà contattare una CA e chiedere un Metodo di firma remota tramite (Web Services)
Quindi poi non vi resterà altro che cambiare l’algoritmo che firma il file in una chiamata al WS del vostro partner, e salvare e/o inviare il file come era precedentemente.

-Questa mattina sto configurando con un partner la firma remota con SOAP (già configurato ormai per lo SDI).

Vantaggi **

  1. Scegliamo in che formato firmare CAdES-BES o XAdES-BES
  2. Abbiamo aggiunto poche righe di codice al nostro Applicativo
  3. Siamo a norma e non abbiamo problemi di verifica firma
  4. I tempi di firma sono i tempi di connessione (Come per le fatture)
  5. Abbiamo tutto il nostro ambiente configurato Equamente

Svantaggi **

  1. Ovviamente chi vi mette a disposizione il WS vorrà essere pagato.

Ovviamente resterà il fatto che se non volete spendere denaro per firmare il file, Non cè altra scelta che i metodi che conoscete.

IO personalmente per chiudere questo progetto ormai aperto da un mese non faccio altro che optare perla prima scelta.

!!I CONTRATTI DI FIRMA, SE SIETE INTERMEDIARI, LI FAREI ADOC (COME RIPORTATO DA leonardo.secci)


(Tomato Codes) #38

Buongiorno, posso chiederle che partner è riuscito a trovare che mette a disposizione un servizio di firma tramite SOAP?

Abbiamo chiesto sia ad Aruba che a InfoCert, ma cadono dal pero

Grazie


(Vladan Bato) #39

Sul sito di Aruba offrono due servizi (sotto le “Soluzioni business”), uno chiamato “Firma Digitale Remota”, l’altro chiamato “Firma Automatica Massiva”. C’è solo una breve descrizione, ma così a occhio mi sembra che entrambi offrano delle API remote. Purtroppo per sapere di più (inclusi i costi) bisogna parlare con un commerciale.

InfoCert invece, nella sezione “Soluzioni Enterprise” offre anch’esso il servizio di “Firma Remota Enterprise”. Ci sono anche “Firma Automatica” e “Digital Sign Server”.

Qualcuno sa come funzionano questi servizi e se qualcuno di essi permette di firmare le fatture elettroniche via API remote, senza intervento umano?

C’è qualche altro prestatore di servizi qualificato che offre questo tipo di servizio?


(Mw Space Llc) #40

Le soluzioni proposte possono essere utilizzate per Firma Remota (con CONFERMA) o per Firma Automatica (senza CONFERMA).

Il nostro è un WS SOAP (JAVA) e utilizzeremo XADES + Firma Automatica :man_technologist:

Per i partner, bè, ce ne sono tanti. Io proverei a fare qualche telefonata :female_detective: