IKEv2 ha due firme: il certificato e IKE_AUTH
La CA firma il certificato e il peer firma il proprio scambio IKE_AUTH con uno schema suo. Leggete ciascuna dal suo campo, poi registrate entrambe.
Il vostro ticket dice che il certificato è SHA-256 mentre il log del gateway nomina un altro algoritmo di firma, e qualcuno ha già preparato una richiesta per riemettere la CA. Prima che quella richiesta vada da qualche parte, separate le due firme: una è il timbro dell'emittente su una chiave pubblica, l'altra è la prova del peer di possedere la chiave privata corrispondente durante IKE_AUTH. Componenti diversi le scelgono, ed è consentito che differiscano. Leggere ciascuna dal luogo in cui vive richiede due comandi e una tabella.
Leggete la firma dell'emittente dal certificato
La CA appone la propria firma su un legame tra un'identità e una chiave. Quella firma registra ciò che la CA ha fatto all'emissione, non ciò che farà il soggetto quando si connette, quindi il suo algoritmo descrive la scelta di hash e chiave della CA stessa. Una chiave di soggetto di un tipo può stare sotto una chiave di CA di un altro tipo senza alcuna incoerenza, e la rotazione della chiave della CA è routine e non un guasto. Leggete i due campi e avete metà dell'inventario:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Annotate entrambe le etichette come voci separate. La prima descrive la CA, la seconda descrive la chiave del soggetto, e nessuna delle due predice la firma in linea.
Leggete la firma in linea dallo scambio IKE
Durante l'autenticazione ogni peer firma i dati dello scambio con la propria chiave privata, e l'altro lato verifica quella prova rispetto all'identità, alla catena di fiducia e alla politica del certificato. Per RSA il padding e l'hash appartengono a questo schema in linea, quindi una chiave più lunga o un certificato SHA-256 nuovo non possono da soli scegliere RSA-PSS per la firma di autenticazione. Il metodo negoziato compare nel log del demone o nel suo elenco di connessioni, mai nel certificato. Chiedete a ciascun lato che cosa ha negoziato, perché le due direzioni possono differire.
ipsec statusall | grep -i "auth\|proposal"Quando un lato nomina uno schema che l'altro non può produrre, avete trovato la discrepanza di cui parlava il ticket. Riemettere la CA è la riparazione sbagliata, perché il certificato non è mai stato ciò che ha fallito.
Che cosa cambia RFC 7427 e che cosa no
I metodi originali sono numerati per combinazione di algoritmi in RFC 7296. La successiva estensione di firma RFC 7427 aggiunge un metodo Digital Signature generale con segnalazione del supporto all'hash di firma, così un nuovo hash non ha più bisogno di un numero di metodo proprio. Si negozia, non si presume: un peer non ottiene l'estensione perché la sua libreria sa analizzare gli stessi certificati, e un peer che implementa solo i metodi originali obbliga il gateway a conservarne uno. È uno scambio di politica con un costo di compatibilità, non un difetto.
Il supporto è per direzione e per connessione, quindi provate la build che avete davanti invece di fidarvi di un'affermazione a livello di famiglia. Una matrice di capacità scritta tre anni fa descrive build di tre anni.
Inserite quattro righe nell'inventario
Il record che chiude la discussione ha quattro righe, ciascuna letta in un punto diverso e ciascuna modificata da una persona diversa. Compilatelo prima di decidere qualunque cosa, perché è la riga sbagliata a scegliere la correzione.
| Oggetto | Da dove si legge | Chi lo cambia |
|---|---|---|
| firma dell'emittente del certificato | il campo Signature Algorithm del certificato | l'operatore della CA, all'emissione |
| chiave pubblica del soggetto | il campo Public Key Algorithm del certificato | chi genera la chiave del soggetto |
| schema di autenticazione IKE | log del demone o elenco delle connessioni, notifica auth e signature-hash | il profilo IKE su entrambi i peer |
| algoritmi di protezione IKE ed ESP | l'elenco delle proposte della connessione | il profilo IPsec, per direzione |
Ogni riga porta la propria conseguenza di compatibilità. Un cambio di cifrario ESP non sceglie la firma dell'emittente, e allentare la validazione della CA non aggiunge un metodo in linea che i peer non hanno mai negoziato. Quando un ticket sostiene una discrepanza di firma, la riga davvero sbagliata non è quasi mai la prima.
Risolvete il caso vecchio senza indebolire la PKI
Un peer più vecchio può offrire solo uno schema che la vostra politica non consente più. Le opzioni sono un'eccezione di compatibilità a tempo, un aggiornamento del client o un diverso assetto di autenticazione solo per quel peer. Ricostruire la PKI attorno a una firma di certificato più debole non corregge un limite nello scambio in linea e indebolisce ogni altro servizio che si fida della stessa CA. Annotate quale riga avete cambiato e quando scade l'eccezione.
Poi rieseguite le due letture dall'inizio, perché un cambiamento in una riga può spostare ciò che si negozia in un'altra. L'intero inventario è due comandi e una tabella, ed è lo stesso lavoro sia che il peer sia un router, un portatile o un apparato.