Errore del certificato web su Access Server: il bundle CA vuoto

Una pagina di accesso web che non si carica mentre il DNS risolve correttamente di solito non è un problema DNS. Se il log del servizio menziona un percorso del bundle di certificati vuoto o un errore di analisi PEM del certificato web e della chiave privata, il listener HTTPS non ha materiale utilizzabile e nessuna risoluzione dei nomi aiuterà. La riparazione sta in tre chiavi di configurazione e non richiede di reinstallare un solo certificato client VPN.

A cosa puntano davvero le tre chiavi

L'insieme personalizzato dei certificati web è descritto da cs.cert, cs.priv_key e cs.ca_bundle. Ognuna memorizza un percorso di file e il servizio web le usa tutte e tre insieme. Un certificato con la chiave sbagliata, o un file di catena che in realtà è il certificato foglia, fallisce come un valore vuoto: il listener non può costruire una catena che il browser accetti.

Queste chiavi appartengono all'interfaccia web Admin e Client. Sono separate dalla PKI che emette certificati ai client VPN, quindi sostituirle non richiede di toccare i profili client, la chiave del server o l'autorità di certificazione. Trattare un guasto TLS web come motivo per ricostruire tutta la PKI è il passo sbagliato più costoso qui.

Una distinzione fa risparmiare tempo: un valore personalizzato esplicitamente vuoto non è lo stesso stato di nessuna sovrascrittura. Il primo consegna al parser un percorso vuoto, ed è ciò che dice la riga di log. Il secondo lascia Access Server sul proprio materiale, per questo alcuni host partono bene dopo un aggiornamento e altri no.

Perché un file esistente non viene comunque analizzato

Il parser legge i blocchi etichettati dentro il file, non il nome del file. Un .crt che contiene una chiave privata, una catena scritta come un unico blocco concatenato dove si attendeva un solo certificato, o un file salvato con l'ultima riga troncata vengono tutti rifiutati. RFC 7468 definisce queste etichette leggibili perché sono l'unica cosa che dice al lettore quale tipo di oggetto segue.

Esaminate gli oggetti, non le estensioni. Su un host Linux, openssl x509 -noout -subject -issuer -in server.pem e openssl pkey -noout -check -in key.pem rispondono alle due domande che contano, e confrontare il modulo o la chiave pubblica di entrambi prova che vanno insieme. Tenete l'output della chiave privata fuori da ticket e log di chat; il controllo vuole un'impronta, non la chiave.

Un percorso vuoto merita lo stesso sospetto di un file malformato, perché entrambi producono errori a valle vaghi. Se il log dice che il percorso del bundle è vuoto, leggete il valore memorizzato prima di fare debug del file.

Tornare al ripiego di proposito

La CLI di Access Server include un controllo di validazione che prende i tre percorsi come argomenti e riporta se l'insieme è utilizzabile. I percorsi sotto sono illustrativi; sostituiteli con le posizioni protette sull'host:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Leggete il risultato prima di toccare il servizio in esecuzione, e solo dopo importate i valori e applicateli tramite l'operazione documentata per la versione installata. Il tutorial CLI ufficiale copre validazione, import nel database di configurazione e fase di applicazione, e la sua versione conta più di qualsiasi riassunto.

Verificate il nome che gli utenti digitano

Quando il materiale personalizzato è rotto e un ripiego integrato valido esiste ancora, il recupero documentato è rimuovere le tre sovrascritture personalizzate e lasciare che Access Server usi quel ripiego. Predisponete prima l'accesso alla console e un backup della configurazione attuale, perché il servizio che riavviate è quello che serve l'interfaccia di amministrazione.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Svuotare l'intero database di configurazione non è una riparazione del certificato. Puntate a quelle tre chiavi, applicate e confermate che l'interfaccia web risponda. I file autofirmati nella directory web-ssl sono la risorsa di ripiego, non uno spazio di lavoro: sovrascriverli o rigenerarli può rimuovere l'unico materiale funzionante.

Aspettatevi che il browser mostri un certificato diverso dopo l'entrata in vigore del ripiego. È il risultato corretto, e la risposta è verificarlo tramite il vostro processo amministrativo fidato, non insegnare agli utenti a ignorare ogni avviso.

Il recupero termina con un accesso riuscito

Il recupero non è finito quando compare un listener TCP. Validate il nome DNS, l'identità del certificato e la catena per quel nome, poi caricate le interfacce web Admin e Client e completate un accesso. Un controllo di porta non prova nulla di tutto ciò.

Access Server 3.1 e successivi possono servire certificati web diversi per nome host SNI. Se è configurato, le chiavi predefinite e le voci specifiche del nome sono insiemi separati, e testare per indirizzo IP mostra facilmente un certificato diverso da quello che ricevono gli utenti. Correggete e validate l'insieme del nome che falliva, poi ripetete il test di accesso prima di chiudere l'incidente.