IKEv2 har två signaturer: certifikatet och IKE_AUTH
CA:n signerar certifikatet och peeren signerar sitt IKE_AUTH-utbyte med ett eget förfarande. Läs var och en från sitt eget fält och notera båda.
Din biljett säger att certifikatet är SHA-256 medan gatewayens logg namnger en annan signaturalgoritm, och någon har redan skrivit ett ärende om att utfärda CA:n på nytt. Innan det ärendet går någonstans, skilj på de två signaturerna: den ena är utgivarens stämpel på en offentlig nyckel, den andra är peerens bevis att den har den matchande privata nyckeln under IKE_AUTH. Olika komponenter väljer dem och de får skilja sig. Att läsa var och en där den bor kräver två kommandon och en tabell.
Läs utgivarens signatur från certifikatet
CA:n sätter sin signatur på en bindning mellan en identitet och en nyckel. Signaturen registrerar vad CA:n gjorde vid utfärdandet, inte vad subjektet kommer att göra när det ansluter, så algoritmen beskriver CA:ns eget val av hash och nyckel. En subjektnyckel av en typ kan ligga under en CA-nyckel av en annan typ utan någon motsägelse, och rotation av CA-nyckeln är rutin och inte ett fel. Läs de två fälten och du har halva inventariet:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Skriv upp båda etiketterna som separata poster. Den första beskriver CA:n, den andra beskriver subjektets nyckel, och ingen av dem förutsäger onlinesignaturen.
Läs onlinesignaturen från IKE-utbytet
Under autentiseringen signerar varje peer utbytesdata med sin egen privata nyckel, och andra sidan kontrollerar beviset mot certifikatets identitet, förtroendekedja och policy. För RSA hör utfyllnad och hash till detta onlineschema, så en längre nyckel eller ett nytt SHA-256-certifikat kan inte på egen hand välja RSA-PSS för autentiseringssignaturen. Den förhandlade metoden syns i daemonens logg eller i dess anslutningslista, aldrig i certifikatet. Fråga varje sida vad den förhandlade, eftersom de två riktningarna kan skilja sig.
ipsec statusall | grep -i "auth\|proposal"När ena sidan namnger ett förfarande som den andra inte kan producera har du hittat den avvikelse biljetten handlade om. Att utfärda CA:n på nytt är fel åtgärd, eftersom certifikatet aldrig var det som misslyckades.
Vad RFC 7427 ändrar, och vad den inte ändrar
De ursprungliga metoderna numreras per algoritmkombination i RFC 7296. Den senare RFC 7427-signaturutökningen lägger till en allmän Digital Signature-metod med signalering av stöd för signaturhash, så en ny hash behöver inte längre ett eget metodnummer. Det förhandlas, det antas inte: en peer får inte utökningen för att dess bibliotek kan tolka samma certifikat, och en peer som bara implementerar de ursprungliga metoderna tvingar gatewayen att behålla en av dem. Det är en policyhandel med en kompatibilitetskostnad, inte en defekt.
Stödet är per riktning och per anslutning, så testa bygget framför dig i stället för att lita på ett påstående på familjenivå. En kapacitetsmatris skriven för tre år sedan beskriver byggen som är tre år gamla.
Sätt fyra rader i inventariet
Posten som avslutar diskussionen har fyra rader, var och en läst på olika ställen och var och en ändrad av olika personer. Fyll i den innan du beslutar något, eftersom det är den felaktiga raden som väljer åtgärden.
| Objekt | Var det läses | Vem som ändrar det |
|---|---|---|
| certifikatutgivarens signatur | certifikatets fält Signature Algorithm | CA-operatören, vid utfärdandet |
| subjektets offentliga nyckel | certifikatets fält Public Key Algorithm | den som genererar subjektnyckeln |
| IKE-autentiseringsförfarande | daemonlogg eller anslutningslista, auth- och signature-hash-avisering | IKE-profilen på båda peerarna |
| IKE- och ESP-skyddsalgoritmer | anslutningens förslagslista | IPsec-profilen, per riktning |
Varje rad bär sin egen kompatibilitetskonsekvens. En ändring av ESP-chiffer väljer inte utgivarens signatur, och en uppmjukning av CA-valideringen lägger inte till en onlinemetod som peerarna aldrig förhandlade. När en biljett hävdar en signaturavvikelse är den rad som faktiskt är fel nästan aldrig den första.
Lös det gamla fallet utan att försvaga PKI:n
En äldre peer erbjuder kanske bara ett förfarande som din policy inte längre tillåter. Valen är ett tidsbegränsat kompatibilitetsundantag, en klientuppdatering eller ett annat autentiseringsarrangemang bara för den peeren. Att bygga om PKI:n kring en svagare certifikatsignatur åtgärdar inte en begränsning i onlinutbytet och försvagar alla andra tjänster som litar på samma CA. Notera vilken rad du ändrade och när undantaget löper ut.
Kör sedan de två läsningarna igen från början, eftersom en ändring i en rad kan flytta det som förhandlas i en annan. Hela inventariet är två kommandon och en tabell, och det är samma arbete oavsett om peeren är en router, en bärbar dator eller en apparat.