Certificato foglia valido, catena scaduta: leggi la profondità

Controlli il certificato del server, vedi mesi rimanenti sull'orologio, e il client rifiuta ancora la connessione con un messaggio di scadenza. La data che leggi appartiene alla foglia, e la lamentela può riguardare qualcosa di più profondo nel percorso. La verifica percorre una catena, e qualsiasi certificato selezionato da questo percorso può fallire nella propria finestra di validità. Leggi quale ha fallito prima di rinnovare qualsiasi cosa.

La profondità nomina il certificato che ha fallito

Nella diagnostica OpenSSL, la profondità 0 è il certificato di destinazione e la profondità 1 è l'emittente che lo ha firmato, con numeri più alti che proseguono verso l'ancora di fiducia. Una scadenza segnalata alla profondità 1 non è contraddetta da un notAfter valido sulla foglia, quindi ricontrollare il certificato visibile non spiegherà mai l'errore.

Annota l'impronta del certificato fallito insieme al suo subject, perché certificati diversi possono portare lo stesso nome CA. La firma incrociata produce esattamente questa situazione: la stessa autorità appare più di una volta, con date di validità diverse, e il verificatore ha scelto quella che non ti aspettavi. Un'etichetta familiare non è un identificatore, e un'impronta è ciò che distingue due oggetti che condividono un nome.

Osserva anche i prodotti con più di un ruolo di certificato. Su OpenVPN Access Server, i certificati che proteggono le interfacce web sono separati da quelli usati per le connessioni VPN, quindi un browser che apre la pagina di amministrazione non dimostra nulla sul percorso del tunnel.

Gli input di fiducia non sono gli stessi dei candidati della catena

Fornisci al verificatore i due input separatamente ed esplicitamente. Il file di fiducia contiene le ancore che accetti; il pacchetto non attendibile contiene i certificati intermedi offerti per costruire il percorso. Mescolarli è il modo in cui le persone promuovono accidentalmente un intermedio a radice e poi si chiedono perché lo stesso errore le segua tra macchine.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Disattivare il percorso e l'archivio predefiniti con -no-CApath -no-CAstore mantiene onesto il test: il risultato dipende allora dai file che hai nominato, non da ciò di cui la workstation si fida per caso. Il riferimento di verifica OpenSSL documenta queste opzioni e la diagnostica che producono.

-show_chain stampa la catena costruita quando la verifica riesce, il che è utile per confermare che il percorso sia quello previsto. Quando fallisce, conserva la profondità e il subject segnalati; quei due campi dicono al lettore successivo quale certificato ispezionare.

Ciò che questo non fa è riprodurre la politica di ogni client. Un pin, una restrizione di scopo o un controllo di identità specifico del client vive nel client, non in questo comando. Sono le impostazioni da ispezionare quando la verifica passa sul server e la connessione fallisce ancora. Tieni separati i due diagnostici, altrimenti rinnoverai un certificato sano inseguendo un errore di pinning.

Cosa dimostra il controllo e cosa lascia fuori

Questo è un controllo di percorso e scopo contro un file di fiducia che hai fornito. Per un controllo del nome HTTPS, aggiungi il nome host atteso tramite l'opzione appropriata; per una connessione VPN, conserva i controlli di identità configurati del client e usa il materiale di fiducia che quel client legge davvero.

Ciò che un server invia è un insieme di candidati, non il percorso che il tuo client finirà per costruire. La fiducia locale e le regole di costruzione della libreria plasmano entrambe il risultato, ed è per questo che la stessa risposta può verificarsi su una macchina e fallire su un'altra. Confronta l'archivio di fiducia mantenuto e l'implementazione TLS del client che fallisce con quelli di un client funzionante prima di assumere una valutazione identica. Una differenza lì spiega molti rapporti «solo questo portatile fallisce».

Per vedere la finestra di ogni certificato invece di uno alla volta, stampali come insieme:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Quel secondo comando elenca subject ed emittenti senza decodificare ogni file a mano, ed è così che individui un intermedio la cui data è passata mentre la foglia sembra ancora a posto.

Ripara il percorso senza indebolire la verifica

Quando viene fornito un intermedio scaduto o un certificato firmato incrociato obsoleto, ottieni la catena attualmente supportata dall'emittente e distribuiscila tramite il flusso di certificati documentato del servizio. Quando al client manca l'ancora mantenuta prevista, aggiorna la sua configurazione di fiducia gestita o il software client. Resisti alla scorciatoia di marcare ogni certificato del pacchetto come radice solo per zittire il messaggio.

La gestione della radice merita una nota, perché i riassunti spesso la esagerano. RFC 5280 tratta l'ancora come un input che sta fuori dal percorso prospettico, mentre OpenSSL documenta controlli di validità che includono il suo certificato CA radice. Entrambe le affermazioni sono vere per i propri sistemi; generalizzare il comportamento di scadenza della radice di una libreria a ogni client produce risposte sbagliate e sicure di sé.

Dopo la modifica, forza una nuova autenticazione sul client interessato e conferma che il messaggio di scadenza specifico sia sparito. Rinnova la foglia solo se la foglia stessa è inadeguata. Disattivare i controlli di tempo o ripristinare un certificato incrociato storico non produce un percorso attuale valido; ritarda solo il prossimo guasto.