cert8.db non è una cache usa e getta: verificate il proprietario dell’archivio

Un vecchio thread di supporto consiglia di eliminare un file chiamato cert8.db e il VPN riprende a funzionare. Quella sequenza è più spesso una coincidenza che una riparazione. Il file è un database di certificati, e rimuoverlo cambia lo stato di sicurezza persistente in modi che un avvio riuscito non rivela.

Un accesso bloccato non è un problema di cache

La cache del browser memorizza copie di risorse; un database di certificati memorizza decisioni di fiducia, certificati e le chiavi associate. Eliminare il secondo è più vicino a reimpostare un’identità che a cancellare la cronologia. Se il client si è bloccato durante l’accesso, la prova utile è quale processo ha aperto quale profilo e cosa ha registrato, non quale file ha rimosso un post di un forum. Riprodurre il blocco e leggere il log del client richiede più tempo che eliminare un file, ed è l’unica via verso una causa reale.

Il nome del file porta anche storia: NSS distingue i vecchi cert8.db e key3.db dai cert9.db e key4.db di SQLite. Annotate la riga di log vista prima del blocco, perché è l’unica prova duratura che avete.

Quale profilo apre realmente il client

Identificate il client, il suo metodo di autenticazione e l’archivio che legge. Esistono tre percorsi di accesso: assistito dal browser, browser incorporato e client nativo, e non devono condividere un profilo. Un database con il nome corretto in un’altra directory non dimostra che il processo bloccato lo abbia aperto. Su Linux l’archivio NSS si trova di solito sotto ~/.pki/nssdb dell’utente o in una directory di profilo per applicazione. Le due disposizioni possono coesistere sulla stessa macchina, quindi verificatele entrambe se la migrazione è recente.

Elencate cosa contiene l’archivio prima di modificarlo: certutil -L -d sql:$HOME/.pki/nssdb stampa i certificati, e lo stesso strumento con -K mostra se sono presenti chiavi.

Se il comando segnala che il database non può essere aperto, avete trovato il profilo usato dallo strumento, non necessariamente quello usato dal VPN.

Fate una copia di sicurezza del profilo prima di qualsiasi riparazione

Chiudete le applicazioni interessate, poi copiate l’intera directory del profilo con il metodo di backup approvato. I database di certificati e chiavi sono uno stato correlato ma distinto, e salvare un file arbitrario non è un piano di ripristino per l’intera identità. Proteggete la copia, perché il profilo può contenere chiavi private. Annotate cosa avete salvato e dove, così una riparazione fallita ha una via di ritorno.

Poi confermate la portata esatta della riparazione con il manutentore. Un ripristino completo dell’archivio, la rimozione di un certificato obsoleto noto e una riparazione del profilo del browser sono tre modifiche diverse con tre rischi diversi.

Dopo la riparazione, accedete e ispezionate l’archivio

Dopo una riparazione autorizzata, accedete al VPN e confermate che il certificato del server sia ancora convalidato come previsto. Verificate che le identità necessarie al flusso di lavoro siano ancora presenti e che non sia comparsa un’ancora di fiducia inattesa. Una riparazione che fa funzionare la connessione fidandosi più di prima non è una riparazione.

Tenete separate l’osservazione e l’istruzione: una cancellazione seguita da un avvio riuscito non è una soluzione generale.

Se il blocco ritorna, catturate il log del client e il profilo in uso prima di cambiare qualsiasi altra cosa. È quel registro che trasforma un’ipotesi in una diagnosi.