A questo punto penso proprio che sia un problema di certificato. La nostra situazione è la seguente.
Abbiamo un unico URL dove esponiamo diversi WEB Services tra cui TrasmissioneFatture.asmx
Il Binding ssl lo abbiamo fatto sul dominio principale in IIS ed il certificato è Let’s Encrypt.
Sulla singola pagina TrasmissioneFatture.asmx abbiamo impostato richiedi SSL in modalità Accetta.
Ora navigando dallo stesso WEB Server il certificato non viene richiesto e viene visualizzata direttamente la pagina con il wsdl. Da un altro client, in IE non visualizza la richiesta del certificato e da errore di accesso negato, Chrome richiede il certificato, ma visualizza la pagina di errore accesso negato e da Firefox non richiede il certificato e visualizza correttamente la pagina con il wsdl.
Premetto che cambiando nell’url la pagina dell’asmx con un’altra dove non è impostato “Richiedi SSL”, il tutto funziona regolarmente in https.
Il certificato sdi server lo avete abbinato al binding del dominio principale?
Ti posso dire quello che ho fatto:
. ho fatto una “bonifica” dei certificati come spiegato nel SECONDO post quì: https://stackoverflow.com/questions/26247462/http-error-403-16-client-certificate-trust-issue
. ho installato solo e solamente questi certificati:
solo SDI-XXXXXXX-client.PFX in CurrentUser/Personal
solo caentrate.der e CAEntratetest.cer INSTALLATI in ComputerAccount/LocalMachine -> Autorità di certificazione radice attendibili
ho importato SDI-XXXXXXX-server.PFX in IIS
Ora, SE in IIS imposto il binding del mio dominio col certificato SDI-XXXXXXX-server.PFX, allora SOGEI riesce a chiamare il mio webservice TrasmissioneFatture senza errori.
SE invece lascio il binding al certificato che avevo prima (Let’s Encript) allora si genera javax.net.ssl.SSLHandshakeException
Ti ho risposto nel messaggio.
Grazie delle preziose risposte, attiviamo subito un dominio dedicato di terzo livello facendo il binding con il certificato previsto sdi-[partita iva]-server.
Vi terremo al corrente sull’esito
Grazie ancora.
non sono un esperto di reti, ma suppongo dovrai anche attivare un nuovo ip, magari installando una nuova scheda di rete, o sbaglio? … inoltre credo dovrai rifare la procedura di accreditamento, perchè cambierà l’url di chiamata al tuo trasmissioneFatture, dico bene?
Da sdi ricevo questa request
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<WSCorIDSOAPHeader xmlns="http://www.wilytech.com/" CorID="AF1F18571A028AC8A43C499D980EF077,1:1,1,0,sdibe85q1|WebSphere|sdife85q1Cell01/BEClusterMember1|WebServices|Client|http_//www.fatturapa.gov.it/sdi/ws/trasmissione/v1.0/types|notificaScarto,2,stringa lunga">
</WSCorIDSOAPHeader>
</soapenv:Header>
<soapenv:Body>
<ns2:notificaScarto xmlns:ns2="http://www.fatturapa.gov.it/sdi/ws/trasmissione/v1.0/types">
<IdentificativoSdI>idsdi</IdentificativoSdI>
<NomeFile>nomefile.xml</NomeFile>
<File>
file base64
</File>
</ns2:notificaScarto>
</soapenv:Body>
</soapenv:Envelope>
mentre la mia request accettata è questa
Ovviamente non funziona. Mi riesci a dare un suggerimento su come posso avere una request allineata ed accettata? Grazie in anticipo
per la gestione di certificati multipli su IIS senza usare SNI (che sogei non sembra supportare) e senza attivare nuovi host e domini forse basterebbe che il primo certificato inviato da IIS al client fosse quello di sogei. Ho letto qualcosa a riguardo quì: https://stackoverflow.com/questions/19565961/default-certificate-for-sni-server-name-indication
ma non ci ho capito molto… qualcuno ha affrontato una situazione del genere e l’ha risolta?
x sgardini: non so se ti rivolgessi a me, comunque io quando mi ha funzionato non ho dovuto modificare nulla dei sorgenti del webservice TrasmissioneFatture che ho generato esattamente come è spiegato qui Trasmissione Fatture WSDL WCF
Grazie dell’indicazione, da ieri ho cominciato a ricevere le notifiche da SdI.
Sul server dove ho i WS per SDI ho anche altri domini sotto IIS con i relativi certificati. Ho risolto il problema SNI (credo e spero) aggiungendo un IP dedicato su cui vanno solo i servizi SDI
Ciao a tutti,
scusate, sono in possesso dei seguenti certificati:
- caentrate.der
- CAEntratetest.cer
- servizi.fatturapa.it.cer
- SistemaInterscambioFatturaPA.cer
- SistemaInterscambioFatturaPATest.cer
- testservizi.fatturapa.it.cer
in quale percorso di IIS vanno installati?
Perché stiamo ricevendo errore 403 e sicuramente dipende dal fatto che non c’è match.
Grazie
Io ho fatto così:
i due caentrate li ho messi nella trusted root certification authorities
sdi-piva(server) + sistemainterscambiofatturapatest + testservizi.fatturapa.it li ho messi nello store personal della macchina
Questo per la versione di test
Spero ti aiuti
Ciao, scusami, sono fermo nella fase in cui riesco ad inviare le fatture ma non ricevo le notifiche perchè ricevo un errore “Unable to decrypt message”. Credo che tu abbia superato proprio questo problema, ma vorrei qualche chiarimento riguardo a qualcuno dei punti da te esposti:
4) cosa intendi con "importato SistemaInterscambioFatturaPATest.cer "? Come e dove lo hai importato?
5) con “ho installato il certificato sul dominio”, intendi il certificato server pfx ricavato dai file ricevuti dall’agenzia delle entrate, vero? Ossia, hai impostato quel certificato nel binding https del dominio, giusto? Questo l’ho già fatto.
7) dici che è necessario usare un utente apposito? Non è sufficiente l’utente amministratore o un altro utente esistente, tipo iis_iusrs?
Grazie mille!
Ciao, grazie per la risposta, adesso sto ottenendo errore 500.
Ciao a tutti,
I WEB Services che ho esposto non sono in MTOM.
Avrei bisogno di sapere come utilizzare i file TrasmissioneFatture_v1.1.wsdl e RicezioneFatture_v1.0.wsdl, forniti in fase di accreditamento, in IIS senza utilizzare MTOM nel nostro server.
Grazie
Ciao, scusami, sono fermo nella fase in cui riesco ad inviare le fatture ma non ricevo le notifiche perchè ricevo un errore “Unable to decrypt message”. Ho provato ad impostare sia onetoone che manytoone, ma niente da fare…. Tu hai risolto? Inoltre, quando richiamo con browser del mio pc l’endpoint client, ricevo un errore " Errore HTTP 403.7 - Forbidden: La pagina a cui si sta tentando di accedere richiede che il browser disponga di un certificato client Secure Sockets Layer (SSL) riconosciuto dal server Web.". E’ giusto così? A volte leggo che dovrebbe apparire la finestra di scelta del certificato, ma questo succede quando sul proprio pc si ha un certificato installato?
@robyone1 abilita il trace in iis così vedi nel dettaglio l’errore
anchio ho lo stesso problema come hai risolto?
L’errore 403.7 c’è in queste situazioni:
-se un client non fornisce un certificato client quando ne è richiesto uno
-se il client ha rifiutato di inviare un certificato client
-il client non ha avuto un certificato rilasciato da un’autorità di certificazione reciprocamente attendibile.
Hi,
which framework are you using?
Have you imported this references?
using System.ServiceModel;
using System.ServiceModel.Activation;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.ServiceModel.Channels;
have a good day
hello sir,
Using WCF I generated the service contract with the visual studio tool wsdl.exe, starting from the TrasmissioneFatture_v1.1.wsdl file and the TrasmissioneTypes_v1.1.xsd file. I generated the Service and tried it with a test client.
and generated interface file is -
Trying the “RicevutaConsegna” method I noticed that my client generates a different SOAP than the one sent by the SDI client. in fact with my client everything works but the corresponding request manager is not access my request method.
my soap body is -
can you please help me to solve this issue.
Hi.
you can download my project to this link