Tracciare gli errori del proxy nei controlli dei certificati CRL e OCSP

Una richiesta a un sito web può raggiungere il suo proxy e comunque fallire perché la verifica del certificato richiede un'altra richiesta di rete. Il recupero CRL o OCSP può passare attraverso un componente della piattaforma con un account e un criterio proxy diversi da quelli del client HTTP dell'applicazione.

Iniziate dall'errore esatto della catena. Revocato significa qualcosa di diverso da impossibile ottenere le informazioni di revoca attuali. Scadenza ed emittente non attendibile sono ancora altri problemi. Solo l'errore di recupero richiede di tracciare un percorso mancante verso un URL di stato.

Per quell'errore, identificate tre cose insieme: l'URL recuperato, il componente che esegue il recupero e l'identità del suo processo. Il fatto che un browser apra l'URL con successo con il vostro account interattivo non dimostra che un servizio possa autenticarsi allo stesso proxy.

Se il componente identificato usa WinHTTP, esaminate il criterio applicabile. La configurazione statica del proxy e la valutazione automatica del proxy per URL sono meccanismi separati. Applicate la configurazione supportata per l'account previsto; copiare le impostazioni del browser o modificare un runtime non correlato può lasciare intatto il recupero effettivo.

In .NET, UrlRetrievalTimeout sul criterio della catena controlla un'attesa per la verifica online o il recupero CRL. Estendere il normale timeout di risposta HTTP non estende lo stesso timer, ed estendere il timer di recupero non fornisce credenziali proxy né un percorso.

Un proxy HTTPS può rendere visibile questa dipendenza anche prima del TLS di destinazione: la fiducia nella connessione al proxy può essa stessa richiedere il recupero delle informazioni di revoca. Ripristinate l'accesso al recupero supportato e l'assetto di fiducia in quella fase. Disattivare il controllo di revoca cambia il criterio del certificato; non ripristina il recupero fallito.