Ciao a tutti: ma oggi state rilevando problemi in ricezione fatture?
Il nostro canale funzionava regolarmente, sia in emissione che in ricezione, fino a stamattina ma, nella giornata di oggi, abbiamo rilevato una drastica diminuzione delle fatture ricevute e nei log del nostro server, per l’accesso ai nostri end point, sono presenti molti dei seguenti errori:
[error] Hostname proxyappl.finanze.it provided via SNI and hostname xxxxx.xxxxx.xx provided via HTTP are different
[error] Hostname proxyappl.finanze.it provided via SNI and hostname yyyyyy.yyyyyy.yy provided via HTTP are different
I nostri endpoint sono, appunto, xxxxxxx.xxxxxx.xx e yyyyyy.yyyyyy.yy.
Ciao, confermo che anch’io ho un blocco delle fatture ricevute dalle 15.40 circa. Nei log non ho trovato però errori; solamente non ho più avuto alcuna chiamata dello sdi verso l’endpoint di ricezione.
Ha fatto la prima comparsa dopo mezzogiorno. [Mon Apr 01 12:39:17.329320 2019] [ssl:error] AH02032: Hostname proxyappl.finanze.it provided via SNI and hostname mio.endpoint.it provided via HTTP are different
Il mio server risponde giustamente 400 Bad Request e non ho più nulla in ingresso. Chiaramente è un errore del loro client e spero lo risolvano presto. Per ora dirotto il traffico sul canale SDIFTP…
Sì chiaro… Io ne ho due, a cui fornisco un servizio platinum , e che mi hanno lasciato l’accesso al portale F&C. Tutti gli altri stanno su SDIFTP e si adeguano alle tempistiche del canale…
La cosa che veramente mi scoccia è che Sogei non ammetta i suoi errori, esattamente come per il crash dell’SDIFTP che avvenne tra l’8 ed il 9 gennaio.
Adesso gli apro un ticket con tanto di log, voglio vedere cosa mi rispondono…
Gentili signori, vi scrivo per segnalarvi un problema del vostro client nella connessione al mio endpoint di ricezione.
(Id SDI canale xxxxxxx).
Vi porto ad esempio il caso della fattura con IdSDI xxxxxxxxx: per i tre tentativi di consegna che sono stati effettuati:
-01/04/2019 12:40:24
-01/04/2019 18:56:07
-01/04/2019 23:09:14
Il mio server ha sempre risposto 400 Bad Request.
Come si evince dal file di log, il problema è dovuto ad un erroneo comportamento del vostro client nella fase di handshake ssl:
-[Mon Apr 01 12:40:24.889761 2019] [ssl:error] [pid 6009] AH02032: Hostname proxyappl.finanze.it provided via SNI and hostname mio.endpoint.it provided via HTTP are different
Tale comportamento anomalo è stato riscontrato anche da altri utenti del canale SDICOOP e se ne sta discutendo qui
https://forum.italia.it/t/hostname-proxyappl-finanze-it-provided-via-sni-and-hostname-xxxx-xxxx-xx-provided-via-http-are-different/9071
Cordiali saluti,
Federico Crepaldi
L’importante è segnalarglielo in massa, così che ne prendano contezza.
Se funziona come per il famoso crash dell’8/1-9/1 su SDIFTP negheranno qualsiasi problema lato loro asserendo che siano nostre configurazioni errate. Poi, come per incanto, il canale tornerà a funzionare
For outbound connections, after handling the initial
handshake, the SSL Channel will create the SSL Engine. If a
forward proxy is used, the engine might be created using the
proxy’s peer connection information instead of the proxy’s
endpoint connection information. This would lead to a TLS
error such as:
[23.08.16 13:27:13:800 CEST] 00000077 SystemOut O
WebContainer :
3, RECV TLSv1 ALERT: warning, unrecognized_name
con i miei colleghi della Metodo Srl abbiamo implementato un workaround che funziona.
Noi eravamo strutturati con un Apache con i certificati SSL presenti nella richiesta di accreditamento che fa da frontend (con proxypass) con la piattaforma che si occupa di macinare le fatture. Su questo Apache, che gestiva anche il gestionale, e un tot di altre cose, era configurato un VirtualHost.
Siccome il problema stava nel mismatch tra il nome dns e lo SNI ssl, ho bypassato il problema eliminando virtualhost, e quindi ho creato una macchina nuova con Apache con un IP dedicato che risponda senza virtualhost.
In questo modo non mi interessa con che nome entra l’agenzia delle entrate e inoltro correttamente le chiamate.
Sistemato il DNS (sto aspettando che si propaghi, ma nell’arco di un’oretta dovrebbe sistemarsi), tutto va a posto.
Non c’è altro modo che non disabilitare il VirtualHost. Infatti il controllo del nome/sni è cablato dentro Apache perché se disabilitato potrebbe portare al fatto che io entro con un certificato di un virtualhost su un altro virtualhost. La soluzione è NON avere virtualhost.
Il dramma ora sarà quello che è stato perso (per colpa dell’Agenzia), sia le fatture (che dovrebbero essere state messe a disposizione) che, soprattutto le ricevute.
Io ho un server con apache e virtual host, ma il mio problema è che il mio server indirizza le richieste a seconda dell’host richiamato: se si tratta dell’end point client, il codice gestisce la ricezione delle ricevute, se si tratta dell’end-point server, gestisce la ricezione delle fatture.
Infatti, per risolvere il problema attuale, avevo provato a modificare il file di configurazione in modo da accettare anche proxyappl.finanze.it come nome host in ingresso. Così il server riceve i dati dal SDI, ma il mio codice server non sa se si tratta di una chiamata per ricezione ricevuta o fattura e quindi non riesce comunque a gestire la chiamata. Voi come avete gestito la questione?
Innanzi tutto grazie dell’hint @andreaOcchi!!
Io continuo a sperare che sistemino il loro client: pur esistendo un workaround, quella di Sogei è un’implementazione che non segue le regole dell’https. Peraltro è un problema noto e già fixato da IBM nel gennaio 2017…
Io ho tutto sullo stesso server quindi per me è facile:
mio.endpoint.it/trasmissione/
mio.endpoint.it/ricezione/
Non potendo utilizzare virtualhost, nel tuo caso per applicare il workaround ti servirebbe un nuovo server a cui far puntare uno dei due endpoint…
Non è mia intenzione fare pubblicità ma se ti registri con Google Cloud, hai 300 dollari di credito gratuito da spendere entro l’anno. Ti fai una macchina semplicissima (alla fine deve tenere solo i log di Apache, 1 processore 4 gb di RAM e 10 GB di spazio) probabilmente finisce prima l’anno dei 300 dollari…
Tra creazione, installazione e configurazione ci abbiamo messo un’oretta. Più un’ora di propagazione del DNS e c.
Brutte notizie: per legge di Murphy, nel mio caso il workaround non funziona. [Tue Apr 02 22:29:15.680889 2019] [ssl:error] [pid 722] AH02032: Hostname proxyappl1.finanze.it provided via SNI and hostname mio.endpoint.it provided via HTTP are different
Nel remoto caso che qualche sysadmin di SOGEI stesse leggendo queste righe:
DOVETE IMPOSTARE
@andreaOcchi avete inserito qualche opzione particolare per ignorare il controllo da parte di mod_ssl? La mia configurazione del modulo è proprio basilare:
rispetto al tuo non ho SSLVerifYClient ne SSLVerifyDepth
Se non usi virtualhost non serve disabilitare nulla perché ad Apache non interessa più dei nomi.
Il punto è che se io ho il sito x e il sito y entrambi in https con un virtualhost, se non controllo che il nome con cui entro sia coerente con lo SNI di ssl potrei, dal sito y, fingermi il sito x o viceversa. E non c’è modo di disabilitare questa cosa senza disabilitare il VirtualHost. A questo punto i nomi sono tutti buoni.