CRL Aged non funzionante?

Buongiorno a tutti.

Ho un problema con il mio WS SdiCoop. Spesso le chiamate in arrivo dallo SdI non vengono autenticate perchè il mio server (IIS) non riesce a verificare la CRL dell’authority dell’Aged (“The revocation function was unable to check revocation because the revocation server was offline”).

In effetti se cerco, ad esempio ora, di verificare la crl dall’indirizzo inserito nei loro certificati (“ldap://cads.entrate.finanze.it/cn=CA Agenzia delle Entrate,ou=Servizi Telematici,o=Agenzia delle Entrate,c=it?certificateRevocationList”) non ci riesco.

Ma è normale?
grazie

Interessante, anche noi abbiamo notato questo problema. Sembra che il nostre server IIS non sia in grado di raggiungere l’url CRL e, in fase di ricezione della fattura elettronica, risponda che il certificato è revocato.

Disabilitiamo il controllo o sei riuscito a trovare una soluzione?

Grazie

giusto stamattina ho disabilitato il controllo CRL solo sull’hosting che ospita il WS (non volevo toglierlo a tutto IIS…) e per ora mi sembra andare. Ho una discussione aperta stamattina che alla fine va a parare qui dove ti rimando https://forum.italia.it/t/problemi-autenticazione-chiamate-sdi-verso-iis/6245/3

Disabilitato il CRL … funziona alla perfezione. Riesco a ricevere notifiche quasi in tempo reale in ambiente di produzione.
La cosa meravigliosa è che ho superato tutta la fase di test senza questa necessità e in produzione, ricevevo random le notifiche mentre altre fallivano con 403.13
Nessun supporto da parte della sogei che quantomeno dovrebbe condividere esperienze per più piattaforme.
Grazie

Siamo in due! Ho fatto anche io tutto lo sviluppo senza e superato tutto i test. E in produzione non andavo riscontrando con quel problema… Attualmente sta filando liscio anche a me.

Ritengo sia sbagliato il certificato della loro CA cmq, che pubblica la CRL su un indirizzo LDAP e non HTTP. Come se fosse “per uso interno” all’azienda…

A Sogei non ho nemmeno pensato di chiederlo, figuriamoci, dopo aver sentito il livello di supporto sulle cose terra-terra… :frowning:

Concordo, non esiste url http solo LDAP.
Ribadisco che è veramente uno scandalo. E’ chiaro che gli sviluppatori siamo noi ma considerando la loro documentazione scarna, potevano degnarsi di fare dei progetti (veri) di esempio e una check-list di configurazione per piattaforma, bastava apache e iis. Invece ora sono riempiti di email e chiamate telefoniche da sviluppatori erranti in vicoli bui, che se non fosse per i forum di discussione come questo, avrebbero già cambiato identità e fatto perdere le proprie tracce :smiley:

Buonasera a tutti, abbiamo avuto lo stesso problema. Su IIS 8.5 abbiamo risolto con (non utilizziamo SNI ovviamente):

Per visualizzare i certificati:
netsh http show sslcert

Abbiamo preso appid (sarebbe IIS) e certhash dal binding 0.0.0.0:443

Abbiamo cancellato il binding esistente (il binding configurato sotto le form di IIS va lasciato intatto)

netsh http delete sslcert ipport=0.0.0.0:443

e lo abbiamo ricreato:

netsh http add sslcert ipport=0.0.0.0:443 certhash=xxxxxx appid={xxxxxx}
certstorename=My verifyclientcertrevocation=disable

Ora riceviamo correttamente, ma mi piacerebbe capire se questo è un problema di tutti o solo di alcuni.

è quello di quando dicevo “disabilitato il controllo CRL solo sull’hosting che ospita il WS”…

per me è indispensabile, secondo il mio modesto parere quel certificato della root auth è sballato e fa casino se l’utilizzatore vuole verificare la CRL come dovrebbe.

Scusate io ho nei log dei miei WS dei 403 random a, volte va tutto bene altre volte, invece, l’agenzia si prende un 403.
Credo che il mio problema sia identico al vostro sebbene a volte tutto funzioni come deve.
Ci sono problemi di sicurezza disabilitando CRL?

non credo, dubito che Aged faccia revoca dei certificati. In ogni caso, se anche lo facesse, visto che non la pubblica correttamente non ti cambia niente ignorarla…