IKEv2 har to signaturer: sertifikat og IKE_AUTH
CA-en signerer sertifikatet, og peeren signerer sin IKE_AUTH-utveksling med sitt eget opplegg. Les hver av dem fra sitt eget felt, og før opp begge.
Billetten din sier at sertifikatet er SHA-256, mens gateway-loggen navngir en annen signaturalgoritme, og noen har allerede skrevet et krav om å utstede CA-en på nytt. Før det kravet sendes noe sted, skill de to signaturene: den ene er utstederens stempel på en offentlig nøkkel, den andre er peeren som beviser at den har den samsvarende private nøkkelen under IKE_AUTH. Ulike komponenter velger dem, og de har lov til å være forskjellige. Å lese hver av dem der den bor krever to kommandoer og én tabell.
Les utstederens signatur fra sertifikatet
CA-en setter signaturen sin på en binding mellom en identitet og en nøkkel. Den signaturen registrerer hva CA-en gjorde ved utstedelsen, ikke hva subjektet vil gjøre når det kobler til, så algoritmen beskriver CA-ens eget valg av hash og nøkkel. En subjektnøkkel av én type kan ligge under en CA-nøkkel av en annen type uten noen motsigelse, og rotasjon av CA-nøkkelen er rutine og ikke en feil. Les de to feltene, og du har halve oversikten:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Skriv opp begge etikettene som separate oppføringer. Den første beskriver CA-en, den andre beskriver subjektets nøkkel, og ingen av dem forutsier den nettbaserte signaturen.
Les den nettbaserte signaturen fra IKE-utvekslingen
Under autentiseringen signerer hver peer utvekslingsdataene med sin egen private nøkkel, og den andre siden kontrollerer dette beviset mot sertifikatets identitet, tillitskjede og policy. For RSA hører utfylling og hash til dette nettbaserte opplegget, så en lengre nøkkel eller et ferskt SHA-256-sertifikat kan ikke alene velge RSA-PSS for autentiseringssignaturen. Den forhandlede metoden vises i daemonens logg eller i dens tilkoblingsliste, aldri i sertifikatet. Spør hver side hva den forhandlet, fordi de to retningene kan være forskjellige.
ipsec statusall | grep -i "auth\|proposal"Når én side navngir et opplegg den andre ikke kan produsere, har du funnet avviket billetten handlet om. Å utstede CA-en på nytt er den gale reparasjonen, fordi sertifikatet aldri var det som sviktet.
Hva RFC 7427 endrer, og hva den ikke endrer
De opprinnelige metodene er nummerert per algoritmekombinasjon i RFC 7296. Den senere RFC 7427-signaturutvidelsen legger til en generell Digital Signature-metode med signalering av støtte for signaturhash, slik at en ny hash ikke lenger trenger sitt eget metodenummer. Det forhandles, det forutsettes ikke: en peer får ikke utvidelsen fordi biblioteket kan tolke de samme sertifikatene, og en peer som bare implementerer de opprinnelige metodene tvinger gatewayen til å beholde én av dem. Det er en policyhandel med en kompatibilitetskostnad, ikke en defekt.
Støtten er per retning og per tilkobling, så test bygget du har foran deg i stedet for å stole på en påstand på familienivå. En kapabilitetsmatrise skrevet for tre år siden beskriver bygg som er tre år gamle.
Sett fire rader i oversikten
Oppføringen som avslutter diskusjonen har fire linjer, hver lest fra et ulikt sted og hver endret av en ulik person. Fyll den ut før du bestemmer noe, fordi den raden som er feil er den som velger reparasjonen.
| Objekt | Hvor det leses | Hvem som endrer det |
|---|---|---|
| sertifikatutstederens signatur | sertifikatets felt Signature Algorithm | CA-operatøren, ved utstedelsen |
| subjektets offentlige nøkkel | sertifikatets felt Public Key Algorithm | den som genererer subjektnøkkelen |
| IKE-autentiseringsopplegg | daemonlogg eller tilkoblingsliste, auth- og signature-hash-varsel | IKE-profilen på begge peerne |
| IKE- og ESP-beskyttelsesalgoritmer | tilkoblingens forslagsliste | IPsec-profilen, per retning |
Hver rad bærer sin egen kompatibilitetskonsekvens. En endring av ESP-chiffer velger ikke utstederens signatur, og å lempe på CA-valideringen legger ikke til en nettbasert metode peerne aldri forhandlet. Når en billett hevder et signaturavvik, er raden som faktisk er feil nesten aldri den første.
Løs det gamle tilfellet uten å svekke PKI-en
En eldre peer tilbyr kanskje bare et opplegg som policyen din ikke lenger tillater. Valgene er et tidsbegrenset kompatibilitetsunntak, en klientoppdatering eller en annen autentiseringsordning bare for den peeren. Å bygge PKI-en på nytt rundt en svakere sertifikatsignatur retter ikke en begrensning i den nettbaserte utvekslingen og svekker alle andre tjenester som stoler på samme CA. Før opp hvilken rad du endret og når unntaket utløper.
Kjør deretter de to lesingene på nytt fra toppen, fordi en endring i én rad kan flytte det som forhandles i en annen. Hele oversikten er to kommandoer og én tabell, og det er samme arbeid enten peeren er en ruter, en bærbar maskin eller et apparat.