Ciao, è possibile avere informazioni sulle classi PHP MTOM?
Ciao Lorenzo,
php non supporta MTOM. Bisogna modificare le classi SoapClient e SoapServer per adattarle alla lettura di MTOM.
Ciao! Spero tu possa aiutarmi. Ho provato ad installare tutti i certificati manualmente o doppio cliccare quello CLIENT convertito PFX. Ma nulla. Mi da sempre l’errore “Forbidden”. Come dovrei fare?
io ho usato questa procedura.
ho installato i certificato sul browser ed impostato che il browser mi chieda quali certificati usare.
Aprendo la pagina https://testservizi.fatturapa.it/ricevi_file?wsdl da browser dovrebbe chiederti il certificato
Se continuando la navigazione (dato che il certificato è homemade) compare il wsdl, bene.
Se non compare il Wsdl e restituisce forbidden, allora probabilmente in Sogei non hanno caricato il tuo certificato e non sei abilitato ad accedere alla pagina. in quel caso chiama il numero verde
Ciao a tutti,
suppongo che anche a voi ieri sia arrivata una PEC con i nuovi certificati da usare per i nostri server SDICOOP.
Avete già applicato la nuova configurazione ad Apache?
Cosa avete cambiato?
Analizzando i file mi sembrano l’intermediate di let’s encrypt e la CA relativa e non più certificati self-signed dell’agenzia delle entrate. Significa che d’ora in poi come certificato client per le chiamate useranno dei certificati fatti con let’s encrypt?
Significa quindi che dobbiamo fare un unico PEM concatenando DST e intermediate (convertito) e poi usare questo file nella sola configurazione “SSLCACertificateFile” per poter validare i nuovi certificati dello SdI lasciando invariato invece il SSLCertificateChainFile che serve perchè lo SDI possa verificare il certificato che ci ha generato in fase di accreditamento?
Ciao a tutti,
Mi aggancio anch’io a questa domanda, non vorrei fare confusione e cerco conferme anche da altri. A suo tempo versai lacrime amare per configurare Apache e controllando la roba che mi ero lasciato alle spalle da ca. 1 anno, mi pare di poterti confermare quanto hai detto.
Risulterebbe anche a me dover cambiare il “SSLCACertificateFile” in cui mettere la chiave DST.pem_ (che è già in formato PEM) concatenata a intermediate.der_ (da convertire in PEM).
nel post che ha linkato cesco69 in risposta a me, dicono che non bisogna fare nulla. Lì ho commentato dicendo che se è così allora la PEC dice di fare una cosa sbagliata e sarebbe bello che arrivasse una errata corrige ufficiale.
Io avevo già fatto la cosa della concatenazione e della modifica di SSLCACertificateFile , ma poi ho pensato che così facendo perdo completamente la sicurezza (autenticazione) e chiunque conosca l’endpoint e possa fare un certificato con letsencrypt avrebbe potuto farmi chiamate, e quindi ora ho riportato la configurazione originale e aspetto di capire meglio (alla peggio fallirà qualche chiamata da parte dello SdI).
Hanno solo cambiato il loro certificato server.
Quello vecchio (che scadeva 10/11/2019) era firmato da GlobalSign.
Quello nuovo è firmato da Let’s Encrypt.
Entrambi i certificati non coinvolgono minimamente la configurazione del proprio web server. Servono per autenticare il server del SdI quando il proprio client si collega ai webservice, ma essendo le CA usate globalmente riconosciute, se il proprio sistema operativo è aggiornato, non serve nessuna particolare configurazione dei client (a meno che il linguaggio/ambiente usato non sia in grado di usare le CA di sistema).
Buonasera, sto cercando di far funzionare il canale SDICoop accreditato e per fare i test ho aggiunto un sottodominio ad un servizio hosting acquistato precedentemente. Sistema Linux, Apache, gestito attraverso plesk. Ho caricato le procedure php client/server, ho installato i certificati lato server creando un nuovo certificato SSL/TLS con:
key: chiave utilizzata per generare i CSR,
cert: SDI-_server.pem,
certCA: ca_all.pem (concatenazione di caentrate.der + CAEntratetest.cer)
eseguo il test con il comando openssl s_client -connect sottodominio.dominio.ext:443 e ricevo codice di errore 19 (il certificato caentrate.der è autofirmato) quindi il sito non risulta essere sicuro
eseguo il test con il comando openssl s_client -connect dominio.ext:443 e legge correttamente il certificato Let’s Encrypt installato sul dominio principale che funziona come sempre.
Invio la prima fattura con la procedura client e ricevo identificativo SdI e dataora, quindi risulta nei flussi del canale, ma la notifica di scarto non mi viene consegnata per il seguente errore: javax.net.ssl.SSLException: Received fatal alert: handshake_failure
Deduco che il client SDI non riconosca i certificati installati, ma ho provato tutte le combinazioni e il risultato è sempre lo stesso. Ho anche provato a concatenare tutti i certificati presenti nel kit di test ma è sempre lo stesso errore! Quindi secondo me non arriva neanche a leggerli i certificati.
Purtroppo con plesk non ho la possibilità di configurare apache come indicato nei vari post e non ho neanche la possibilità di attivare il protocollo TLSv1 che qualcuno dice che viene utilizzato da sogei per fare l’hello. Può essere che non è possibile farlo funzionare su un sottodominio che in realtà ha lo stesso IP del dominio principale dove è installato un altro certificato? Ma ho provato anche a impostare lo stesso certificato sul dominio principale ma non cambia nulla.
Ormai sono al terzo canale accreditato, ho provato a fare la CSR server impostando il common name sia con SDI- sia con il nome dell’host quindi nel mio caso sottodominio.dominio.ext, ma non cambia nulla.
Spero in un vostro illuminante aiuto.
Aggiornamento: il protocollo TLSv1.0, 1.1 e 1.2 sono abilitati
Buongiorno,
sono alle prese con realizzazione wepapp di invio fatture e ricezione notifiche con Apache + PHP,
mi collego a questo post perchè sono bloccato da giorni sullo stesso problema.
Posso sapere come avete risolto?
Grazie
Buongiorno,
anche a me risulta sempre l’errore “javax.net.ssl.SSLHandshakeException: General SSLEngine problem”. Ho controllato tutto un paio di volte, ma non riesco a ricevere qualcosa. Invece il client funziona bene. Ho riuscito a mandare qualcosa all’ sdi.
Rigaurdando lo server ho un idea:
Nei miei certificati ho trovato uno che si chiama “caentrate_new.cer”, che non ho visto nei altri post. Forse hanno fatto un errore nell’ ambiente test, quando hanno introdotto quel certificato, e l’ambiente test non funziona piu?
Tra quelli certificati il “caentrate_new.cer” è l’unico che è un certificato root dei due (client e server) che ho ricevuto dall’ sdi.
Se lancio il comando
“openssl s_client -connect test.miodominio.it:443 -CAfile .\caentrate_new.cer”
da un altra macchina, mi da un “Verify return code: 0 (ok)”.
Se invece chiedo:
“openssl s_client -connect testservizi.fatturapa.it:443 -CAfile .\caentrate_new.cer”
mi dice: Verify return code: 19 (self signed certificate in certificate chain)
“openssl s_client -connect testservizi.fatturapa.it:443 -CAfile .\caentrate.der”
mi da un Verify return code: 0 (ok)".
Non so se i due certificati devono corrispondere, era solo un idea. Forse cè`qualcuno che può chiarire le cose.
Grazie e saluti
Alessandro
Anche io da ieri, quando ho iniziato i test per un nuovo accreditamento (solo trasmissione), ho sempre questo errore nel dettaglio di ogni notifica: “javax.net.ssl.SSLHandshakeException: General SSLEngine problem”.
Ho seguito passo passo quanto fatto due anni fa per altri tre server (vps ubuntu server 18.04) risultanti da subito raggiungibili correttamente dal sistema di notifica, ma in questo caso riscontro dei problemi.
1 Mi Piace
Almeno non sono solo. Ho scritto un’ e-mail al SDI questa mattina. Spero di ricevere presto un messaggio da loro. Se so qualcosa lo metto qui
Saluti Alessandro
1 Mi Piace
Ho fatto anche io la segnalazione, ieri, e mi hanno appena comunicato che hanno risolto il problema, ed infatti adesso non ho più l’errore javax.net.ssl.SSLHandshakeException: General SSLEngine problem
1 Mi Piace
Purtroppo non mi hanno ancora risposto. Oggi farò un altro test. Si spera che funzioni. Hai utilizzato il vecchio certificato o quello nuovo?
Ho sbagliato io, il sistema che ti risponde non puo lavorare coi indirizzi pec. Adesso ho scelto un altro mail e mi hanno risposto adesso.
PER TUTTI GLI ALTI CHE HANNO LO STESSO PROBLEMA:
Mandate un message all’ agenzia, dopo quello ha funzionato. Forse c’è un errore con gli certificati che devono risolvere loro.
Saluti Alexander
1 Mi Piace
Come dice @AlexanderKlement per tutti quelli che sbattono la testa con l’errore nella primissima fase dei test:
javax.net.ssl.sslhandshakeexception: general sslengine problem
CONTATTATE L’ASSISTENZA Perchè è un problema loro, aprite il ticket menzionando l’errore e abbastanza velocemente vi sistemano l’errore e le chiamate successive saranno corrette.
Ciao a tutti.
Stò anche io cercando per la prima volta di accreditare il canale.
Ho seguito la configurazione di @Paolo_Pedrazzi_Digit
ma continua ad avere il seguente messaggio di errore
“javax.net.ssl.SSLHandshakeException: General SSLEngine problem”
La mia configurazione è la seguente
SSLCertificateFile /certs/SDI-xxxxxxxxxxx_server.crt
SSLCertificateKeyFile /certs/keyserver.key #La mia chiave inviata generata ed inviata all'agenzia
SSLCertificateChainFile /certs/caentrate.der
SSLCACertificateFile /certs/CA_Agenzia_delle_Entrate_all.pem #ho concatenato tramite editor i due file caentrate.der + CAEntratetest.cer
SSLVerifyClient optional
SSLVerifyDepth 5
SSLStrictSNIVHostCheck off
Eseguendo il comando
openssl s_client -connect miodominiotest.com:443
Ricevo
Verify return code: 21 (unable to verify the first certificate)
Mentre
openssl s_client -connect miodominiotest.com:443 -CAfile caentrate_new.cer
Ricevo
Verify return code: 0 (ok)
Vi chiedo se la configurazione è corretta o se mi sono perso qualche cosa e se, come consigliato da @AlexanderKlement , aprire un ticket di assitenza.
Grazie!
Un’ultima domanda. il file caentrate_new.cer l’ho usato per testare il canale con openssl… serve a qualche altra cosa?