Giu17202317 Giugno 202317 Giugno 20230Commentidi Ermanno Goletto

Errore 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

Pubblicato in IT, Security, Tips

Una Subordinate Certificate Authority potrebbe non avviarsi segnalando l’errore:

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)

A seguito del mancato avvio del servizio nel log Applicazione viene registrato l’evento di errore 100:

Nome registro: Application
Origine: Microsoft-Windows-CertificationAuthority
ID evento: 100
Livello: Errore
Utente: SYSTEM
Computer: subca01.contoso.com
Descrizione:
Servizi certificati Active Directory non è stato avviato: impossibile caricare o verificare il certificato CA corrente. Contoso Issuing CA. Il server di revoca è offline. La funzione richiamata non è in grado di completare il controllo di revoca. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

e l’evento di avviso 

Nome registro: Application
Origine: Microsoft-Windows-CertificationAuthority
ID evento: 48
Livello: Avviso
Utente: SYSTEM
Computer: subca01.contoso.com
Descrizione:
Impossibile verificare lo stato di revoca di un certificato nella catena per il certificato CA 0 per Contoso Issuing CA. Il server non è disponibile. Il server di revoca è offline. La funzione richiamata non è in grado di completare il controllo di revoca. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

Gli eventi registrati nel log Applicazione permettono di capire che la Subordinate Certificate Authority non è riuscita ad avviarsi perché non è stata in grado di verificare la Certificate Revocation List (CRL) del proprio certificato.

Il certificato della Subordinate Certificate Authority è rilasciato dalla Root Certificate Authority e tra i vari campi vi è anche il CRL Distribution Point in cui è disponibile la CRL tramite cui verificare se il certificato non sia stato revocato.

Se non è possibile per vari motivi, che vedremo successivamente, verificare che il certificato della Subordinate Certificate Authority non sia stato revocato viene visualizzato l’errore descritto precedentemente e il servizio non si avvia impedendo alla CA di emettere certificati tramite un certificato che potrebbe essere stato revocato.

Ovviamente questo tipo di problematica può verificarsi solo all’avvio di una Subordinate Certificate Authority, quindi in Architetture di PKI Two-Tier, a riguardo si vedano i miei articoli:

Workaround temporaneo

Nel caso sia necessario forzare l’avvio della Subordinate Certificate Authority avendo la certezza che il certificato della CA sia valido è possibile escludere temporaneamente il controllo della CRL tramite il comando:

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

Ovviamente non appena il problema che impedisce la verifica della CRL verrà risolto occorrerà ripristinare il controllo della CRL tramite il comando:

certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

Test per l’analisi delle cause dell’errore

Per provare manualmente la verifica della CRL è possibile utilizzare il seguente comando che permette di specificare l’URL della CRL e aprire l’URL Retrieval Tool per eseguire dei test di raggiungibilità e verifica:

certutil -URL “http://crl.contoso.com/CertEnroll/Contoso Issuing CA.crl”

L’URL Retrieval Tool permette di verificare l’accessibilità dei file crl e la loro validità (selezionando Recupera) e la verifica del certificato della Subordinate Certificate Authority (selezionando Seleziona… e quindi Recupera).

Causa 1 dell’errore: il servizio non riesce ad accedere al file della CRL

Come avevo descritto nell’articolo Deploy PKI in Windows Server 2016 – Parte 2 – Installazione e configurazione di una Root CA Offline | ICT Power è consigliabile specificare un’URL come CRL Distribution Point in questo modo la verifica del certificato generato dalla Root Certificate Authority sarà possibile  da client sia in grado di accedere all’URL indipendentemente dal fatto che sia o meno membro di un dominio Active Directory. Inoltre come riportato in Optimizing the Revocation Experience conviene gestire la Certificate Revocation List (CRL) solo tramite HTTP anziché tramite LDAP configurando un server web che si occuperà della pubblicazione evitando di assegnare tale ruolo alla Subordinate CA per ragioni di sicurezza soprattutto nel caso in cui la CRL debba essere pubblicata in Internet:

“Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.”

Ovviamente se il servizio è in grado di accedere all’URL o all’URL indicato esiste il file della CRL verrà visualizzato l’errore x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

Quindi si tenga presente che il servizio dovrà:

  • essere in grado di risolvere i nomi DNS specificati nell’URL
  • riuscire ad accedere all’URL tenendo presente che il servizio viene eseguito per default tramite l’account di Sistema Locale e che utilizza WinHTTP

L’utilizzo dei servizi HTTP Di Microsoft Windows (WinHTTP) implica che potrebbe essere possibile all’URL tramite una sessione utente, ma non tramite il servizio dal momento che la sessione utente utilizza le impostazioni specificate nel browser che potrebbero differire da quelle configurate in WinHTTP. Ciò significa che il test proposto precedentemente basato sull’utilizzo dell’URL Retrieval Tool potrebbe dare esito positivo quando eseguito in una sessione utente senza evidenziare alcun problema in quanto non fa uso di WinHTTP per accedere all’URL.

Un esempio potrebbe essere quello che in WinHTTP sia stato specificato l’uso di un proxy non funzionante o che non permette di accedere all’URL (per un esempio di uno scenario in potrebbe essere stato necessario specificare l’utilizzo di un proxy in WinHTTP si veda il mio post Windows Server 2016 e Windows Update tramite proxy – DevAdmin Blog).

Per visualizzare le impostazioni relative al proxy configurate su WinHTTP è possibile usare il comando:

netsh winhttp show proxy

Per rimuovere eventuali impostazioni relative al proxy configurate su WinHTTP è possibile usare il comando:

netsh winhttp reset proxy

Causa 2 dell’errore: La CRL è scaduta

Dal momento che la Subordinate Certificate Authority verifica il proprio certificato rilasciato dalla Root Certificate Authority la CRL generata dalla Root Certificate Authority non dovrà essere scaduta.

Il test proposto precedentemente basato sull’utilizzo dell’URL Retrieval Tool permette di verificare che la CRL della Root non sia scaduta, ma è possibile farlo semplicemente verificando che la data dell’Aggiornarmento successivo della CRL sia successivo alla data corrente

Questa problematica può verificarsi in una Architetture di PKI Two-Tier dal momento che per ragioni di sicurezza la Root Certificate Authority deve rimanere normalmente spenta ed essere accesa solo per aggiornare la CRL, ma se per qualche motivo si sono verificati problemi nell’aggiornamento della CRL la Subordinate Certificate Authority non riuscirà a validare il proprio certificato.

Per ovviare al problema basta aggiornare la CRL della Root Certificate Authority tramite il comando

certutil -CRL

quindi assicurarsi che il file della CRL venga copiato nel percorso a cui punta il CRL Distribution Point.

A riguardi si vedano i miei articoli: