# P7m codificato

**URL:** <https://forum.italia.it/t/p7m-codificato/6470>\
**Category:** Fatturazione Elettronica\
**Created:** [17 Dicembre 2018, 11:21am UTC](https://forum.italia.it/t/p7m-codificato/6470 "2018-12-17T11:21:54Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sbraaaa](https://forum.italia.it/user_avatar/forum.italia.it/sbraaaa/32/2801_2.png) [@Sbraaaa](https://forum.italia.it/u/Sbraaaa)\
**Post date:** [17 Dicembre 2018, 11:21am UTC](https://forum.italia.it/t/p7m-codificato/6470/1 "2018-12-17T11:21:54Z")

</div>

Ciao,  
ho un problema con un p7m che non riesco a leggere ma non trovo nessun post che descriva il problema pertanto chiedo aiuto sperando qualcuno mi sappia dare le informazioni necessarie.  
Dispongo di diversi xml codificati con Cades che riesco a leggere eliminando l’incapsulamento della firma in formato PKCS#7 ma ne ho ricevuto uno che non riesco proprio a gestire: sembra sia salvato in binario anziché come banale testo.  
I vari software (dike, assoinvoice) lo leggono regolarmente e segnalano la firma come valida, a qualcuno è capitato di aver a che fare con file del genere?

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [17 Dicembre 2018, 1:59pm UTC](https://forum.italia.it/t/p7m-codificato/6470/2 "2018-12-17T13:59:59Z")

</div>

Cosa intendi con “sembra sia salvato in binario anziché come banale testo”?  
I file PKCS#7 sono tutti binari. Cosa fai esattamente per eliminare l’incapsulamento?

---

<div class="post-metadata">

**Author:** ![Sbraaaa](https://forum.italia.it/user_avatar/forum.italia.it/sbraaaa/32/2801_2.png) [@Sbraaaa](https://forum.italia.it/u/Sbraaaa)\
**Post date:** [17 Dicembre 2018, 2:07pm UTC](https://forum.italia.it/t/p7m-codificato/6470/3 "2018-12-17T14:07:12Z")

</div>

probabilmente non mi sto esprimendo nei termini corretti: da quello che leggo in rete un XML firmato CAdES è di fatto l’XML nativo al quale viene aggiunto in testa ed in coda un set di dati per incapsularne il contenuto.

es.

> 0ƒ+S \*†H†÷  
> a ƒ+C0ƒ+\>1  
> 0 `†He0ƒ$U \*†H†÷  
> a ƒ$Eƒ$@\<?xml version="1.0" encoding="UTF-8"?\>…

ed in questo caso identificare il contenuto del file è abbastanza semplice.  
Viceversa ho degli xml.p7m che contengono dati del tipo:

> MIIdqwYJKoZIhvcNAQcCoIIdnDCCHZgCAQExDzANBglghkgBZQMEAgEFADCCDeIG  
> CSqGSIb3DQEHAaCCDdMEgg3PPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0i  
> VVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+PD94bWwtc3R5bGVzaGVldCB0eXBlPSd0  
> ZXh0L3hzbCcgaHJlZj0nZmF0dHVyYXByX3YxLjIueHNsJz8+PHA6RmF0dHVyYUVs  
> ZXR0cm9uaWNhIHhtbG5zOnA9Imh0dHA6Ly9pdmFzZXJ2aXppLmFnZW56aWFlbnRy  
> YXRlLmdvdi5pdC9kb2NzL3hzZC9mYXR0dXJlL3YxLjIiIHhtbG5zOnhzaT0iaHR0  
> cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHZlcnNpb25l  
> PSJGUFIxMiI+PEZhdHR1cmFFbGV0dHJvbmljYUhlYWRlcj48RGF0aVRyYXNtaXNz  
> aW9uZT48SWRUcmFzbWl0dGVudGU+PElkUGFlc2U+SVQ8L0lkUGFlc2U+PElkQ29k  
> aWNlPjA1MDA2OTAwOTYyPC9JZENvZGljZT48L0lkVHJhc21pdHRlbnRlPjxQcm9n  
> cmVzc2l2b0ludmlvPmp1Y2VtMDAwNTk8L1Byb2dyZXNzaXZvSW52aW8+PEZvcm1h  
> dG9UcmFzbWlzc2lvbmU+RlBSMTI8L0Zvcm1hdG9UcmFzbWlzc2lvbmU+PENvZGlj  
> ZURlc3RpbmF0YXJpbz4wMDAwMDAwPC9Db2RpY2VEZXN0aW5hdGFyaW8+PFBFQ0Rl…

vedo che anche in quest’ultimo caso il file è di testo quindi il contenuto è evidentemente criptato.  
Come posso decrittarlo? Dike e Assoinvoice lo fanno senza problemi.  
E’ forse crittato con una chiave pubblica che non è la mia?

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [17 Dicembre 2018, 2:28pm UTC](https://forum.italia.it/t/p7m-codificato/6470/4 "2018-12-17T14:28:05Z")

</div>

Così a naso direi che quello è un file .p7m codificato in base64.  
Anzi, ho provato a decodificare il pezzo che hai postato ed è in effetti l’inizio di un file .p7m. Quindi devi fare la decodifica base64.  
Pensavo che un file del genere non fosse valido, ma ho appena provato a fare la verifica sul sito dell’agenzia delle entrate con un file .p7m codificato in base64 e mi dice che è valido, quindi mi sbagliavo.

A parte questo problema della codifica in base64, ti avviso che il sistema che stai usando è comunque sbagliato. I file .p7m non hanno semplicemente dei dati davanti e dietro al file xml. Il formato è più complesso di così. In alcuni casi il file xml può essere spezzettato in più blocchi con altri dati binari nel mezzo (per esempio Infocert li fa così). Ti consiglio vivamente di usare una libreria in grado di gestire i file PKCS#7 correttamente.

---

<div class="post-metadata">

**Author:** ![Sbraaaa](https://forum.italia.it/user_avatar/forum.italia.it/sbraaaa/32/2801_2.png) [@Sbraaaa](https://forum.italia.it/u/Sbraaaa)\
**Post date:** [17 Dicembre 2018, 2:33pm UTC](https://forum.italia.it/t/p7m-codificato/6470/5 "2018-12-17T14:33:13Z")

</div>

ok grazie per la dritta!  
mi confermi comunque che se estraggo i dati dal .p7m usando openssl dovrei ottenere un’estrazione valida?

es. openssl smime -verify -inform DER -in file\_originale.p7m -noverify -out file\_finale

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [17 Dicembre 2018, 3:08pm UTC](https://forum.italia.it/t/p7m-codificato/6470/6 "2018-12-17T15:08:06Z")

</div>

> [@Sbraaaa](#):
>
> mi confermi comunque che se estraggo i dati dal .p7m usando openssl dovrei ottenere un’estrazione valida?

Sì, ho appena fatto una prova e funziona correttamente.

---

<div class="post-metadata">

**Author:** ![sgardini](https://forum.italia.it/user_avatar/forum.italia.it/sgardini/32/1265_2.png) [@sgardini](https://forum.italia.it/u/sgardini)\
**Post date:** [12 Gennaio 2019, 2:52pm UTC](https://forum.italia.it/t/p7m-codificato/6470/7 "2019-01-12T14:52:58Z")

</div>

Ovviamente dal canale arrivano fatture in codifica base64. Sto cercando di capire se dal file xml si riesce ad individuarle in qualche modo, capire se sono codificate o meno. A quanto vi risulta possono essere codificate in base 64 anche fatture non firmate? Immagino di sì.

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [12 Gennaio 2019, 3:06pm UTC](https://forum.italia.it/t/p7m-codificato/6470/8 "2019-01-12T15:06:18Z")

</div>

Anche a noi sono arrivate fatture codificate in base64.

La nostra procedura per prima cosa verifica se il file è codificato in base64, ovvero verifica se la lunghezza è un multiplo di 4 e se tutti i caratteri sono caratteri base64 validi ([A-Za-z0-9+/=] dove ‘=’ può comparire solo come ultimo o come ultimi due caratteri). Se sì, allora esegue la conversione da base64 e poi procede come di consueto.

Non possono esserci dubbi, perché sia i file .p7m che i file xml contengono sempre caratteri non validi nella codifica base64.

---

<div class="post-metadata">

**Author:** ![sgardini](https://forum.italia.it/user_avatar/forum.italia.it/sgardini/32/1265_2.png) [@sgardini](https://forum.italia.it/u/sgardini)\
**Post date:** [12 Gennaio 2019, 3:59pm UTC](https://forum.italia.it/t/p7m-codificato/6470/9 "2019-01-12T15:59:18Z")

</div>

Grazie della dritta non ci avevo pensato in effetti.

---

<div class="post-metadata">

**Author:** ![sgardini](https://forum.italia.it/user_avatar/forum.italia.it/sgardini/32/1265_2.png) [@sgardini](https://forum.italia.it/u/sgardini)\
**Post date:** [14 Gennaio 2019, 5:45am UTC](https://forum.italia.it/t/p7m-codificato/6470/10 "2019-01-14T05:45:06Z")

</div>

Se può servire uso questa Regex  
^(?:[A-Za-z0-9+/]{4})\*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$  
oltre al controllo multiplo di 4, anche se probabilmente è pure di troppo

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [14 Gennaio 2019, 2:19pm UTC](https://forum.italia.it/t/p7m-codificato/6470/11 "2019-01-14T14:19:41Z")

</div>

Vi segnalo anche che il hash che c’è nel file dei metadati è del file che vi arriva, quindi se il file arriva codificato in base64, il hash corrisponderà a quello. Se lo decodificate e buttate via l’originale, non avrete più la corrispondenza con il hash nel file dei metadati.

---

<div class="post-metadata">

**Author:** ![Romolo\_Manfredini](https://forum.italia.it/user_avatar/forum.italia.it/romolo_manfredini/32/1934_2.png) [@Romolo\_Manfredini](https://forum.italia.it/u/Romolo_Manfredini)\
**Post date:** [14 Gennaio 2019, 7:57pm UTC](https://forum.italia.it/t/p7m-codificato/6470/12 "2019-01-14T19:57:26Z")

</div>

io prima verifico l’hash se l’hash non corrisponde per me è un’anomalia e la registro comunque  
per chi non lo sapesse visto che il tag HASH nel metadati non era (non ho fatto caso all’ultima documentazione) documentato, è l’sha256sum del file.

---

<div class="post-metadata">

**Author:** ![Romolo\_Manfredini](https://forum.italia.it/user_avatar/forum.italia.it/romolo_manfredini/32/1934_2.png) [@Romolo\_Manfredini](https://forum.italia.it/u/Romolo_Manfredini)\
**Post date:** [14 Gennaio 2019, 8:00pm UTC](https://forum.italia.it/t/p7m-codificato/6470/13 "2019-01-14T20:00:04Z")

</div>

> [@vbato](#):
>
> Anche a noi sono arrivate fatture codificate in base64.
> 
> La nostra procedura per prima cosa verifica se il file è codificato in base64, ovvero verifica se la lunghezza è un multiplo di 4 e se tutti i caratteri sono caratteri base64 validi ([A-Za-z0-9+/=] dove ‘=’ può comparire solo come ultimo o come ultimi due caratteri). Se sì, allora esegue la conversione da base64 e poi procede come di consueto.
> 
> Non possono esserci dubbi, perché sia i file .p7m che i file xml contengono sempre caratteri non validi nella codifica base64.

ti sono arrivati degli xml in base64 o degli xml.p7m ?  
Perchè se arrivano degli xml.p7m per la documentazione fornita da sogei va ancora bene, ma nella documentazione non c’è scritto da nessuna parte che la codifica base64 per i file dei flussi è accettabile. (o perlomeno non l’ho trovato scritto)

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [15 Gennaio 2019, 11:01am UTC](https://forum.italia.it/t/p7m-codificato/6470/14 "2019-01-15T11:01:28Z")

</div>

> [@Romolo\_Manfredini](#):
>
> ti sono arrivati degli xml in base64 o degli xml.p7m ?

Finora ho visto un solo file .p7m. È una casistica piuttosto rara.

---

<div class="post-metadata">

**Author:** ![ClaudioP](https://forum.italia.it/user_avatar/forum.italia.it/claudiop/32/5994_2.png) [@ClaudioP](https://forum.italia.it/u/ClaudioP)\
**Post date:** [15 Gennaio 2019, 12:19pm UTC](https://forum.italia.it/t/p7m-codificato/6470/15 "2019-01-15T12:19:18Z")

</div>

Ho riscontrato in p7m codificati in tutte le fatture emesse dalla SIAE.

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [16 Gennaio 2019, 9:44am UTC](https://forum.italia.it/t/p7m-codificato/6470/16 "2019-01-16T09:44:32Z")

</div>

Vi segnalo che i criteri sopra esposti per identificare i file codificati in base64 non vanno bene 😓  
Oggi abbiamo ricevuto un file (.p7m) codificato in base64 ma spezzato su più righe (come si usa negli allegati delle mail). Quindi nel verificare se sono dati base64 bisogna tirare via eventuali caratteri CR e LF (non so se altri tipi di spazi sono ammessi).

---

<div class="post-metadata">

**Author:** ![Marcx](https://forum.italia.it/user_avatar/forum.italia.it/marcx/32/2379_2.png) [@Marcx](https://forum.italia.it/u/Marcx)\
**Post date:** [16 Gennaio 2019, 10:17am UTC](https://forum.italia.it/t/p7m-codificato/6470/17 "2019-01-16T10:17:46Z")

</div>

Da quello che ho letto in giro i file codificati in CaDES possono essere in Base64…

Noi abbiamo risolto cosi, tentando la decodifica in b64 sempre se va bene teniamo il content nuovo, altrimenti quello vecchio:

```
public static byte[] removeP7MCodes(final String NOME_FILE, byte[] p7bytes) throws WSException {
	try {
		if (p7bytes == null || !NOME_FILE.toUpperCase().endsWith(".P7M")) {
			return p7bytes;
		}
		try {
			p7bytes = org.bouncycastle.util.encoders.Base64.decode(p7bytes);
		} catch (Exception e) {
			logger.debug("File P7m non in base64, tengo content standard" + e.getMessage());
		}

		CMSSignedData cms = new CMSSignedData(p7bytes);
		if (cms.getSignedContent() == null)
			throw new WSException("Impossibile trovare signed Content durante decodifica da P7M per file: " + NOME_FILE);    		

		ByteArrayOutputStream out = new ByteArrayOutputStream();
		cms.getSignedContent().write(out);
		out.flush();
		return out.toByteArray();
	} catch (CMSException | IOException e) {
		throw new WSException("Impossibile decodificare P7M per File: " + NOME_FILE, e);}
}

```

Con i vari flussi passivi ricevuti in produzione ci siamo accorti delle seguenti casistiche:

- File p7m in base64, gestisto con il check sulla decodifica.
- File p7m che decodificati contenevano il carattere BOM e che faceva fallire la fase di unmarshalling e abbiamo rimosso manualmente…

---

<div class="post-metadata">

**Author:** ![Romolo\_Manfredini](https://forum.italia.it/user_avatar/forum.italia.it/romolo_manfredini/32/1934_2.png) [@Romolo\_Manfredini](https://forum.italia.it/u/Romolo_Manfredini)\
**Post date:** [16 Gennaio 2019, 4:19pm UTC](https://forum.italia.it/t/p7m-codificato/6470/18 "2019-01-16T16:19:44Z")

</div>

Il mio criterio è il seguente:

1. file ricevuto inizia con \<?XML (dopo aver ripulito eventuali spazi iniziali allora è un file xml posso leggere i dati del destinatario ed inoltrarla.  
Se anche contiene dssignature, e quindi è uno xades sarà comunque il destinatario a verificare la firma, eventualmente in caso di PA inoltrerò le notifiche di scarto qualora il destinatario dovesse rifiutare la fattura per firma non valida: caso che non dovrebbe mai succedere dato che la verifica dovrebbe farla anche SDI.

2. il file ricevuto non inizia con xml provo la decompattazione con openssl (potrebbe trattarsi di un file xml mal nominato che in realtà è un .xml.p7m, ma SDI avrebbe dovuto scartarla) se la decompattazione fallisce acquisisco il file fra le anomalie, non sapendo a chi inoltrarlo, altrimenti prendo il file decompattato, leggo l’xml per trovare il destinatario e inoltro il p7m originale al destinatario.

Ad oggi dopo qualche migliaio di fatture trattate, non ho anomalie.

---

<div class="post-metadata">

**Author:** ![vbato](https://forum.italia.it/letter_avatar_proxy/v4/letter/v/3e96dc/32.png) [@vbato](https://forum.italia.it/u/vbato)\
**Post date:** [16 Gennaio 2019, 5:21pm UTC](https://forum.italia.it/t/p7m-codificato/6470/19 "2019-01-16T17:21:30Z")

</div>

Non hai mai ricevuto file codificati in base64?  
Non hai mai ricevuto file senza la dichiarazione xml (che iniziano direttamente con l’elemento `<FatturaElettronica>`)?

Noi abbiamo riscontrato entrambe le casistiche.

---

<div class="post-metadata">

**Author:** ![Romolo\_Manfredini](https://forum.italia.it/user_avatar/forum.italia.it/romolo_manfredini/32/1934_2.png) [@Romolo\_Manfredini](https://forum.italia.it/u/Romolo_Manfredini)\
**Post date:** [16 Gennaio 2019, 7:28pm UTC](https://forum.italia.it/t/p7m-codificato/6470/20 "2019-01-16T19:28:39Z")

</div>

non capisco come facciano a passare il controllo dell’xsd senza l’intestazione \<?XML  
p7m codificati base 64 si, ma xml codificati base64 no…  
per quello chiedevo precedentemente…

[Pagina seguente](https://forum.italia.it/t/p7m-codificato/6470.md?page=2)