IKEv2 har to signaturer: certifikat og IKE_AUTH
CA'en signerer certifikatet, og peeren signerer sin IKE_AUTH-udveksling med sit eget skema. Læs hver af dem fra sit eget felt, og notér begge.
Din billet siger, at certifikatet er SHA-256, mens gatewayens log nævner en anden signaturalgoritme, og nogen har allerede udarbejdet en anmodning om at genudstede CA'en. Før den anmodning sendes nogen steder hen, skal du skille de to signaturen ad: den ene er udstederens stempel på en offentlig nøgle, den anden er at peeren beviser, at den har den matchende private nøgle under IKE_AUTH. Forskellige komponenter vælger dem, og de må gerne være forskellige. At læse hver af dem der, hvor den bor, kræver to kommandoer og en tabel.
Læs udstederens signatur fra certifikatet
CA'en sætter sin signatur på en binding mellem en identitet og en nøgle. Den signatur registrerer, hvad CA'en gjorde ved udstedelsen, ikke hvad subjektet vil gøre, når det forbinder, så dens algoritme beskriver CA'ens eget valg af hash og nøgle. En subjektnøgle af én type kan ligge under en CA-nøgle af en anden type uden nogen uoverensstemmelse, og en rotation af CA-nøglen er rutine snarere end en fejl. Læs de to felter, og du har halvdelen af inventaret:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Skriv begge etiketter ned som separate poster. Den første beskriver CA'en, den anden beskriver subjektets nøgle, og ingen af dem forudsiger den online signatur.
Læs den online signatur fra IKE-udvekslingen
Under autentificeringen signerer hver peer udvekslingsdata med sin egen private nøgle, og den anden side kontrollerer dette bevis mod certifikatets identitet, tillidskæde og politik. For RSA hører padding og hash til dette online skema, så en længere nøgle eller et nyt SHA-256-certifikat kan ikke i sig selv vælge RSA-PSS til autentificeringssignaturen. Den forhandlede metode vises i daemonens log eller i dens forbindelsesliste, aldrig i certifikatet. Spørg hver side, hvad den forhandlede, fordi de to retninger kan være forskellige.
ipsec statusall | grep -i "auth\|proposal"Når den ene side nævner et skema, som den anden ikke kan fremstille, har du fundet den uoverensstemmelse, billetten handlede om. At genudstede CA'en er den forkerte reparation, fordi certifikatet aldrig var det, der fejlede.
Hvad RFC 7427 ændrer, og hvad den ikke gør
De oprindelige metoder er nummereret pr. algoritmekombination i RFC 7296. Den senere RFC 7427-signaturudvidelse tilføjer en generel Digital Signature-metode med signalering om signatur-hash-understøttelse, så en ny hash ikke længere behøver sit eget metodenummer. Det forhandles, det antages ikke: en peer får ikke udvidelsen, fordi dens bibliotek kan parse de samme certifikater, og en peer, der kun implementerer de oprindelige metoder, tvinger gatewayen til at beholde en af dem. Det er en politisk handel med en kompatibilitetsomkostning, ikke en defekt.
Understøttelse er pr. retning og pr. forbindelse, så test det build, du har foran dig, i stedet for at stole på en påstand på familieniveau. En kapabilitetsmatrix skrevet for tre år siden beskriver builds, der er tre år gamle.
Sæt fire rækker i inventaret
Den registrering, der afslutter diskussionen, har fire linjer, hver læst fra et forskelligt sted og hver ændret af en forskellig person. Udfyld den, før du beslutter noget, fordi den række, der er forkert, er den, der vælger rettelsen.
| Objekt | Læs det fra | Ændret af |
|---|---|---|
| certifikatudstederens signatur | certifikatets felt Signature Algorithm | CA-operatøren ved udstedelsen |
| subjektets offentlige nøgle | certifikatets felt Public Key Algorithm | den, der genererer subjektnøglen |
| IKE-autentificeringsskema | daemonlog eller forbindelsesliste, auth- og signature-hash-notifikation | IKE-profilen på begge peers |
| IKE- og ESP-beskyttelsesalgoritmer | forbindelsens forslagsliste | IPsec-profilen, pr. retning |
Hver række bærer sin egen kompatibilitetskonsekvens. En ændring af ESP-ciffer vælger ikke udstederens signatur, og en lempelse af CA-valideringen tilføjer ikke en online metode, som peerne aldrig forhandlede. Når en billet hævder en signaturuoverensstemmelse, er den række, der faktisk er forkert, næsten aldrig den første.
Afgør det gamle tilfælde uden at svække PKI'en
En ældre peer tilbyder måske kun et skema, som din politik ikke længere tillader. Valget er en tidsbegrænset kompatibilitetsundtagelse, en klientopdatering eller en anden autentificeringsordning kun for den peer. At genopbygge PKI'en omkring en svagere certifikatsignatur retter ikke en begrænsning i online-udvekslingen og svækker enhver anden tjeneste, der stoler på den samme CA. Notér, hvilken række du ændrede, og hvornår undtagelsen udløber.
Kør derefter de to læsninger igen fra toppen, fordi en ændring i én række kan flytte det, der forhandles i en anden. Hele inventaret er to kommandoer og en tabel, og det er det samme arbejde, uanset om peeren er en router, en bærbar computer eller et apparat.