Scopo del certificato non supportato: perché la CA intermedia fallisce

Lo scopo del certificato del server sembra corretto, la chiave corrisponde, le date sono a posto, e la connessione continua a fallire con unsupported certificate purpose. Il dettaglio che risolve la questione si trova di solito sulla stessa riga dell'errore: un valore di profondità e un subject che nominano un certificato più in alto nella catena. Vengono eseguiti due test diversi, e solo uno riguarda il certificato finale. Confrontarli spiega perché sostituire il certificato del server non cambia nulla.

Quale certificato il verificatore ha davvero rifiutato

Una catena non è un oggetto ripetuto tre volte. Il certificato finale porta il nome e la chiave del server, gli intermedi lo collegano a una radice, e ognuno ha il proprio periodo di validità, vincoli e usi. Quando l'errore nomina una profondità, quel numero identifica una posizione nella catena costruita dal verificatore, che potrebbe non essere la posizione attesa se il server invia una catena inaspettata.

Leggi i campi del certificato a quella profondità invece del certificato che hai supposto colpevole. Chiedi le due estensioni che vincolano l'emissione anziché scaricare ogni campo, perché la risposta è quasi sempre in una di esse. L'output delle estensioni è sicuro da condividere; le chiavi private mai.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Se il certificato nominato è un intermedio il cui uso esteso della chiave menziona qualcosa di estraneo all'autenticazione del server TLS, il resto dell'errore segue meccanicamente. La catena non può essere usata per lo scopo richiesto da OpenVPN.

Scopo del certificato finale e politica della catena sono due test

Il test del certificato finale pone una domanda ristretta: questo certificato di entità finale consente l'autenticazione del server per questo nome? Il test della catena ne pone una più ampia: ogni certificato del percorso può servire quello scopo? Un'autorità di certificazione autorizzata a emettere solo certificati client supererà i propri controlli di firma e fallirà comunque il secondo test, perché il percorso che autorizza non include lo scopo di cui l'applicazione ha bisogno. I due test falliscono con le stesse parole e hanno riparazioni del tutto diverse.

Per questo un certificato finale appena emesso, corretto in ogni campo visibile, può fallire subito. Per questo la correzione di solito appartiene al profilo dell'autorità emittente e non alla configurazione della VPN.

Un EKU assente non è un EKU restrittivo

La RFC 5280 rende facoltativa l'estensione di uso esteso della chiave e, quando presente, restrittiva. Un certificato di CA senza l'estensione, quindi, non ha detto «no» all'autenticazione del server, mentre uno che elenca solo uno scopo estraneo ha detto qualcosa di molto preciso. Trattare questi due stati come equivalenti produce la diagnosi sbagliata e, peggio, la riparazione sbagliata. La distinzione spiega anche perché due autorità che sembrano uguali in una console si comportano in modo del tutto diverso in una catena.

Anche il comportamento delle librerie non è uniforme qui. documento di OpenSSL sulle opzioni di verifica descrive il proprio trattamento dei controlli di scopo sui certificati di CA, e quel trattamento è una politica di implementazione, non una regola che ogni stack TLS segue in modo identico. Descrivi ciò che fa il tuo verificatore, poi confermalo con la versione che esegui davvero.

Riproduci l'errore offline prima di riemettere

Una verifica offline toglie l'applicazione dall'equazione. Se la catena fallisce allo stesso modo con lo stesso scopo, il problema è il certificato e nessuna configurazione del server lo nasconderà. Se la catena passa offline mentre il servizio rifiuta ancora, l'applicazione sta chiedendo un altro scopo o usando una catena diversa da quella testata.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain conta perché stampa il percorso costruito dallo strumento, che spesso non è l'ordine dei file fornito. Quell'output è il modo più rapido per scoprire che un secondo intermedio viene preso da un archivio di fiducia, che il server invia una variante firmata in modo incrociato che non intendevi, o che il flag di scopo copiato da un tutorial appartiene a un ruolo diverso da quello servito.

Correggi la politica di emissione, non la chiamata di verifica

La riparazione duratura è un intermedio emesso secondo una politica che consente gli scopi che deve servire, con il vincolo scritto e rivisto. Aggiungere ogni scopo a ogni autorità non è una politica; elimina il vincolo che dava senso all'estensione e di solito sopravvive all'incidente che l'ha motivata. Una breve nota nel profilo che descrive quali ruoli l'autorità può certificare evita che la prossima riemissione ripeta la stessa discussione.

Disattivare la verifica è l'altra scorciatoia tentante, e trasforma un problema di certificato in un problema di fiducia. Mantieni il controllo di scopo, correggi la catena e riesegui la stessa verifica offline per confermare che il percorso serva ora il ruolo previsto prima di toccare di nuovo il servizio.