Hostname proxyappl.finanze.it provided via SNI and hostname xxxx.xxxx.xx provided via HTTP are different

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.

Qualcuno sa di cosa si tratta?

Ciao, confermo anche io che abbiamo lo stesso problema.

Ho chiamato l’assistenza, che sostiene non ci sia alcun disservizio.

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… :frowning:

@fednikx ma i codici destinatario non sono associati ad un singolo canale? Come hai fatto a dirottare il traffico su SDIFTP?

Ho accesso al portale F&C come delegato

1 Mi Piace

L’errore da me ha fatto la sua comparsa ieri alle 10.40.
Primo aprile.
Pesce.

Fortunato te che hai una sola ditta. Noi ne abbiamo 1500 ed è totalmente impensabile.

1 Mi Piace

Sì chiaro… Io ne ho due, a cui fornisco un servizio platinum :smiley:, e che mi hanno lasciato l’accesso al portale F&C. Tutti gli altri stanno su SDIFTP e si adeguano alle tempistiche del canale… :grimacing:
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…

Ticket aperto… Vediamo se/che cosa mi rispondono :joy:

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
1 Mi Piace

Io ho aperto il ticket ieri pomeriggio presto e ancora mi devono rispondere…… :disappointed_relieved:

1 Mi Piace

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 :smiley:

1 Mi Piace

A quanto pare è un known issue di IBM Websphere:

http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PI70810

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

1 Mi Piace

Known issue chiusa nel 2017. Tutto ciò è bellissimo! :joy:

ciao a tutti

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.

Vediamo che mi dicono.

Buon lavoro a tutti
Andrea Occhi

1 Mi Piace

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!! :slight_smile:
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
:face_with_symbols_over_mouth::face_with_symbols_over_mouth::face_with_symbols_over_mouth:

Nel remoto caso che qualche sysadmin di SOGEI stesse leggendo queste righe:
DOVETE IMPOSTARE

  1. Application Servers > {Server Name} > Process definition >
    Java Virtual Machine > Custom properties
  2. com.ibm.ws.websvcs.transport.useProxyEndpointInformation --> true
    (oppure) com.ibm.ws.webservices.transport.useProxyEndpointInformation --> true

COME DESCRITTO QUI http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PI70810

@andreaOcchi avete inserito qualche opzione particolare per ignorare il controllo da parte di mod_ssl? La mia configurazione del modulo è proprio basilare:

        SSLCertificateFile /certificati/MIO.ENDPOINT.IT_server.pem
        SSLCertificateKeyFile /certificati/chiave.key
        SSLVerifyClient optional
        SSLVerifyDepth 5
        SSLCACertificateFile /certificati/CA.cer
        RewriteEngine On
        RewriteCond   %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
        RewriteRule  .* - [F]

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.

1 Mi Piace