Test Interscambio SDI

ciao a tutti,

sto provando ad accreditarmi su fatturepa. Ho fatto tutta la pratica, ho messo online gli endpoint di test e gia qua avrei una prima domanda: quando parlano di endpoint di ricezione e trasmissione cosa intendono? Quello di ricezione mi sembra ovvio sarà la URL alla quale il mio servizio risponde quando gli viene inviata una fattura da SDI. Ma quello di trasmissione?

Comunque quando poi lancio i test il servizio non prova nemmeno a contattare il mio endpoint. Fallisce con un errore Java generico: java.io.IOException: Async IO operation failed (3), reason: RC: 107 Transport endpoint is not connected

Qualcuno che lo ha fatto sa aiutarmi?

L’endpoint di trasmissione è quello a cui ti inviano le notifiche relative alle fatture che hai trasmesso.

Per quanto riguarda l’errore, potrebbe essere un problema coi certificati. È la cosa che di solito dà maggiori problemi.

Sistemando i certificati sono riuscito a farmi chiamare ma ora mi dicono questo:

org.apache.axis2.AxisFault: WSWS7093W: The HTTP response redirected the target resource to a new location: https://proxyaps.finanze.it:80
Qualcuno ne ha esperienzA?

Per chi verra dopo di me ho risolto importando nella chain dei certificati anche la CA e ora funziona tutto

1 Mi Piace

Ciao Giovanni, avrei bisogno di un consiglio in quanto ricevo errore sui certificati in ricezione delle notifiche in test, ho configurato il server nginx e risponde con certificati validi sia con dominio che con IP, e creato una chain di certificati mettendo tutto sia quelli di prod che quelli di test, ma nulla. Mi daresti la chain giusta da mettere, ho visto che tu hai risolto ? sto letteralmente impazzendo

Io per un NGINX che fa da reverse proxy e terminator SSL faccio cosi’:

nella config del vhost ho:

   ssl_certificate      /etc/nginx/mycerts/prod/chainprod.pem;
   ssl_certificate_key  /etc/nginx/mycerts/server.key;

   ssl_prefer_server_ciphers on;

    ssl_verify_client on;
    ssl_verify_depth 3;
    ssl_client_certificate /etc/nginx/mycerts/prod/caentrate.cer

e NON definisco i dhparam

la chain dei certificate la creo così:

  1. prima converto da der a pem cioè da binario a testo b64
openssl x509 -inform der -in SDI-NN-server.cer -outform pem -out SDI-NN-server.pem

openssl x509 -inform der -in testservizi.fatturapa.it.cer -outform pem -out testservizi.fatturapa.it.pem

  1. faccio un BUNDLE dei certicati AdE e AdE CA unico, questi sono quelli di TEST !

cat caentrate.cer CAEntratetest.cer testservizi.fatturapa.it.pem > morecert.pem

  1. quindi faccio il chain finale contente il mio cert server E ANCHE il bundle qui sopra

cat SDI-NN-server.pem morecert.pem > chain.pem

  1. carico il chain.pem in un editor di testo e sistemo a mano i separatori se serve (le righe con i “—–BEGIN”, “—-END” ) in modo che siano separati

Ale

Ci proverò, grazie Alessandro

Buongiorno. Abbiamo un problema serio per l’accreditamento del canale WS. Riusciamo ad inviare le fatture, ma non riceviamo le notifiche, a causa di un errore HTTP500. Abbiamo un sistema SAP S/4 e le notifiche vengono ricevute dal SAP cloud

Aggiungo dettagli:

Generale:

  • la società lavora con due providers
    • Edicom, per le fatture di trasport o
    • SAP DRC per le fatture non di trasporto
  • Se inviamo le fatture dal DRC, ci aspettiamo le notifiche pure verso il DRC e non verso EDIC OM.
  • La fatture dal DRC sono inviate dal SAP

Endpoints:

Used certificates

  • Last certificates provided by us via SPID
  • Client (SDI) certificate (sdi_0 3222820213.csr)
    • CN = SDI-03222820213
  • Server certificate (SDIHostCertTest.csr)

Technical setup pr oxy and firewall:

  • No TLS SNI connection bet ween SDI and proxy
  • No block if SDI use the certificates provided by SPID website (the one we uploaded in August)
  • Proxy knows the certificates, the authentication from SDI should work betwe en the proxy and S DI

XML Files

  • Without special character – solved
  • With correct natura codes – solved

Problems

  • SDI is not calling our en dpoint /ReceiveNotification
  • We cannot see any calls from SDI to our endpoint in the proxy
  • HTTP 500 error is not coming from our endpoint, because they are not calling our endpoint.