Validazione FE in errore su risorsa XMLSchema.dtd

Buongiorno a tutti
le routine di validazione delle FE su schema ministeriale che si poggiano sulle librerie MSXML 6.0 dallo scorso venerdì restituiscono l’errore OLE 80020009 accesso negato.
Errore durante l’elaborazione della risorsa “https://www.w3.org/2001/XMLSchema.dtd”.
L’URL della risorsa in questione risulta NON raggiungibile dal “vecchi” browser IE (11) mentre è raggiungibile dai browser moderni (es EDGE o SAFARI). Nel mio caso la routine viene eseguita in OS windows 2016 e 2019, sistemi con TLS 1.2 già abilitato, escludendo questa ipotesi quale causa del problema.
Ho tamponato salvando tutti i files referenziati dallo schema in locale e modificandoli per imporne la ricerca in locale. Vedo però che anche un sistema gestionale che oggi ha cercato di validare i file LIPE incappa sullo stesso identico problema.
Qualche idea in merito?
Grazie a tutti

Ho il tuo stesso problema, l’unica differenza è che a me esce l’errore in questo modo: Errore durante l’elaborazione della risorsa “http://www.w3.org/2001/XMLSchema.dtd”.
In pratica manca la “s” su “http”.
Posso chiederti di mostrare, se puoi, il codice che utilizzi per la validazione?
Che ci sia una qualche impostazione da fare nel richiamare la libreria msxml 6.0?

Grazie.

Scusa l’errore è lo stesso, ho copiato l’url che viene reindirizzato in https.
Dopo pranzo ti posto il codice!
Grazie

Poco prima di leggere il tuo messaggio avevo postato un mio messaggio che contiene il codice che utilizzo io ma, non capisco perché, il mio messaggio è stato “nascosto” perché qualcuno lo ha segnalato come spam :((

Adesso pare che sia stato ripristinato… il titolo è " Validazione xml F.E. non mi funziona più"

Grazie per l’aiuto che potremo darci a vicenda.

Ho appena letto sul sito www.w3.org che hanno cominciato a reindirizzare da http su https ed è certamente questo il nostro problema.

Adesso è necessario capire se e come impostare msxml6.0 affinché digerisca questi reindirizzamenti.

Anche a volerlo fare a mano modificando il file .xsd, francamente, non capisto dove questo punti alla risorsa XMLSchema.dtd (non trovo da nessuna parte una riga che lo contenga).

Grazie.

L’errore viene scatenato in validazione dello schema ministeriale, durante la risoluzione delle risorse esterne. Ho l’impressione queste librerie in qualche modo utilizzino le librerie di IE per la chiamata HTTP di recupero. In effetti se cerco di raggiungere il percorso del file DTD (https://www.w3.org/2001/XMLSchema.dtd) dalla versione di IE che è presente negli OS pre W11 il browser non ci riesce mentre EDGE, CHROME o FIREFOX non hanno problemi.

Per ovviare ho scaricato localmente
https://www.fatturapa.gov.it/export/documenti/fatturapa/v1.2.1/Schema_del_file_xml_FatturaPA_versione_1.2.1.xsd
https://www.w3.org/2001/datatypes.dtd
https://www.w3.org/2001/XMLSchema.dtd

Sul XSD ministeriale va tolto l’url e lasciato solo il nome del file sull’attributo schemaLocation:

<xs:import namespace=“XML-Signature Syntax and Processing” schemaLocation=“xmldsig-core-schema.xsd” />

Una cosa simile va fatta anche sul file xmldsig-core-schema.xsd dove però lo schema è dichiarato in modo differente:

DOCTYPE schema
PUBLIC “-//W3C//DTD XMLSchema 200102//EN” “XMLSchema.dtd”…

Il file datatype.dtd non ha bisogno di modifiche. Tutti i files dovranno essere presenti nel medesimo percorso ed i codice dovrà caricarli da percorso assoluto non più tramite url.

Alla fine si guadagna in velocità di esecuzione della validazione, ma con l’onere di manutenere manualmente i file in caso di modifiche allo schema ministeriale.
E’ probabile che le librerie NET non abbiano questo problema, dovrei fare un piccolo prototipo. Ovviamente sono in ambiente windows, probabile che java o altri linguaggi non cadano in questa situazione.

PS: non sono assolutamente un esperto in XML e XSD, e non vorrei nemmeno diventarlo…

Mi sono perso… Posso chiederti, per favore, se mi passi i tre files modificati oppure puoi postare solo le righe interessate dalle modifiche?

Ma il file xml continui a formattarlo come prima o come lo hai modificato, puoi postare le prime righe interessate dalle dichiarazioni per la validazione?

Grazie.

Ok, compreso le modifiche e … adesso tutto ok lavorando in locale.

Grazie.

Observations from our initial https redirection tests | W3C Blog

Ecco cosa sta accadendo realmente. W3.org sta iniziando una progressiva redirection verso https delle risorse esposte, “inviando” gli sviluppatori a creare dei cataloghi locali oppure a verificare “the ability to handle redirects” degli applicativi. Evidentemente MSXML questo non lo sta facendo bene.

Sono incappato nello stesso problema con le librerie Java (mi pare Xerces) il mese scorso.
Utilizzare un catalog locale è comunque la cosa migliore da fare, anche perché si evitano chiamate HTTP remote ogni volta che si deve validare un file di fattura (che poi diventano due se c’è un redirect di mezzo). Personalmente ho adottato questa soluzione.

Da qualche giorno il sito E3.org risponde come prima, hanno completato i test in una non ben definita finestra temporale. Il messaggio è comunque quello di correggere ove possibile le procedure perché gestiscano correttamente il redirect (cosa che non fa MSXML) oppure crearsi un repository locale.

Salve MicheleMaran
Avevo già adottato la stessa soluzione in java con Sax.
Nella versione Schema_VFPR12.xsd versione 1.2.2 apportando la modifica sax mi genera l’errore nella riga <xs:element ref=“ds:Signature” .
Dal momento che lo uso solo per l’invio delle fatture ho eliminato anche questa riga e funziona di nuovo tutto.
Per la ricezione, dove devo togliere la signature, eseguo il comando bash con openssl in questo modo l’applicazione riceve sempre il file xml ripulito.
Se puo interessare questo è il contenuto del file signature.sh:

#!/bin/sh 
insr=$1
outstr="${insr/$2/$3}"
outstr="${outstr/$3$3/$3}"
openssl cms -verify -in "$insr" -noverify -inform DER -out "$outstr" -no_attr_verify
if [ $? -eq 0 ]; then
  rm -f "$insr"
fi

quindi chiamo il comando:
./signature.sh “nomefile.xml.p7m” “.p7m” “.xml” >/dev/null 2> signature.log