ca md too weak: riemettere il certificato o abbassare il livello?

Un OpenVPN che il mese scorso funzionava ora fallisce all'avvio con ca md too weak, e il profilo su disco è identico byte per byte a quello che funzionava. Il messaggio riguarda la firma sul certificato di un'autorità di certificazione, non la cifratura dei dati, il digest auth o la password dell'account. Tre condizioni decidono se la correzione è nuovo materiale d'identità, una catena nuova o un cambio deliberato di politica. Affrontatele in ordine ed eviterete l'esito abituale, in cui il tunnel torna indebolendo ogni connessione TLS dell'host.

Cosa nomina davvero l'errore

OpenSSL solleva questo errore di verifica mentre costruisce una catena, quando il certificato che agisce come CA porta un digest della firma che il livello di sicurezza della libreria non accetta più. MD5 è rifiutato al livello predefinito, e SHA-1 è rifiutato appena il livello viene alzato. Il digest del certificato foglia qui conta meno di quello dell'emittente che lo firma. La stessa politica può rifiutare una radice del tutto ordinaria il giorno in cui è stata emessa.

Per questo modificare auth o data-ciphers non serve a nulla contro questo guasto. Quelle impostazioni regolano come i pacchetti sono protetti dopo lo handshake, mentre l'oggetto rifiutato è un documento d'identità esaminato prima che esista un tunnel. Un certificato può stare comodamente dentro la sua finestra di validità e portare comunque una firma che la libreria non accetterà.

Tenete separati i controlli in testa e l'errore smette di sembrare misterioso. Le date di validità, l'uso della chiave e il digest della firma sono test indipendenti, e esattamente uno di essi è appena fallito.

Prima condizione: l'oggetto rifiutato è la radice?

Stampate ogni certificato del profilo e leggete i campi subject e issuer. Una radice autofirmata mostra lo stesso valore in entrambi, e il suo algoritmo di firma è quello su cui poggia l'intera catena. Quando il digest debole sta lì, ogni foglia sotto di essa eredita il problema. Annotate l'algoritmo accanto al subject perché il confronto successivo sia meccanico e non a memoria.

I file CA raggruppati contengono spesso più blocchi, quindi identificate il blocco realmente caricato invece di supporre che il primo sia colpevole. Il comando openssl x509 -in ca.pem -noout -subject -issuer -text descrive un certificato alla volta, il che impone di dividere prima il pacchetto se ne contiene più di uno. Confrontate l'algoritmo di firma stampato con il digest che vi aspettereste dall'epoca di creazione della radice.

Una foglia firmata in SHA-256 sotto una radice debole fallisce comunque, perché il controllo della catena risale fino in cima. È quell'ordine a rendere importante la condizione successiva.

Seconda condizione: controllate l'emittente?

Se la radice appartiene alla vostra organizzazione, la correzione duratura è una nuova radice con un digest moderno più foglie riemesse, fornite come un solo aggiornamento del profilo. Costa una finestra di manutenzione e un piano per i dispositivi che non possono ricevere l'aggiornamento lo stesso giorno.

Se la catena l'ha emessa un terzo, la correzione è una richiesta a quell'operatore, e l'unica azione locale utile è smettere di dipendere dal materiale vecchio. Modificare il testo PEM o risalvare il file non cambia nulla di ciò che la firma copre.

Un caso intermedio merita un nome: una radice interna anteriore ai valori predefiniti attuali ma che firma ancora materiale di cui altri sistemi si fidano. Sostituirla significa verificare ogni consumatore, compresi gli apparati che fissano il vecchio certificato tramite impronta. Contate quei consumatori prima di pianificare il cambio, perché una sostituzione della radice che ne dimentica uno scambia un errore di avvio con un'interruzione.

Terza condizione: cos'altro accetta l'abbassamento del livello

Abbassare il livello di sicurezza, o scegliere il profilo certificati legacy di OpenVPN, fa tornare il client ad accettare il vecchio digest. Rilassa anche altri controlli della stessa libreria, per ogni connessione che quel processo apre.

Può essere difendibile in laboratorio, o come ponte breve mentre si prepara il materiale sostitutivo, purché l'eccezione sia limitata a un profilo e porti una data di fine. Come impostazione permanente su un host condiviso allarga silenziosamente ciò di cui ogni client TLS lì si fiderà.

Annotate l'eccezione con un responsabile e un passo di rimozione. Un cambio di livello non documentato è indistinguibile da un errore sei mesi dopo, e l'ingegnere successivo non saprà che fu mai una decisione.

La decisione, scritta come regola

Sostituite la catena quando controllate l'emittente e potete elencarne i consumatori. Escalate all'emittente quando non potete. Abbassate il livello solo come eccezione datata e circoscritta, con la sostituzione già pianificata. Qualunque altra cosa lascia lo stesso certificato al suo posto e sposta il rischio in un punto meno visibile.

Poi riprovate il profilo da un client pulito, confermate che lo handshake si completa, e conservate il testo esatto del rifiuto se fallisce ancora. Un messaggio d'errore preciso è la cosa meno costosa che potete consegnare a chi possiede il livello successivo.