IKEv2 har to signaturar: sertifikat og IKE_AUTH
CA-en signerer sertifikatet, og peeren signerer IKE_AUTH-utvekslinga si med sitt eige opplegg. Les kvar av dei frå feltet sitt, og før opp båe.
Billetten din seier at sertifikatet er SHA-256, medan gateway-loggen nemner ein annan signaturalgoritme, og nokon har alt skrive eit krav om å gje ut CA-en på nytt. Før det kravet blir sendt nokon stad, skil dei to signaturane: den eine er stempelet til utstadaren på ein offentleg nøkkel, den andre er beviset frå peeren om at han har den samsvarande private nøkkelen under IKE_AUTH. Ulike komponentar vel dei, og dei har lov til å vere ulike. Å lese kvar av dei der dei bur krev to kommandoar og ein tabell.
Les signaturen til utstadaren frå sertifikatet
CA-en set signaturen sin på ei binding mellom ein identitet og ein nøkkel. Den signaturen registrerer kva CA-en gjorde ved utgivinga, ikkje kva subjektet vil gjere når det koplar til, så algoritmen skildrar CA-en sitt eige val av hash og nøkkel. Ein subjektnøkkel av ein type kan liggje under ein CA-nøkkel av ein annan type utan noka motseiing, og rotasjon av CA-nøkkelen er rutine og ikkje ein feil. Les dei to felta, og du har halve oversikta:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Skriv opp båe etikettene som eigne oppføringar. Den første skildrar CA-en, den andre skildrar nøkkelen til subjektet, og ingen av dei føreser den nettbaserte signaturen.
Les den nettbaserte signaturen frå IKE-utvekslinga
Under autentiseringa signerer kvar peer utvekslingsdataa med sin eigen private nøkkel, og den andre sida kontrollerer dette beviset mot identiteten, tillitskjeda og policyen til sertifikatet. For RSA høyrer utfylling og hash til dette nettbaserte opplegget, så ein lengre nøkkel eller eit ferskt SHA-256-sertifikat kan ikkje åleine velje RSA-PSS for autentiseringssignaturen. Den framhandla metoden viser seg i loggen til daemonen eller i tilkoplingslista hans, aldri i sertifikatet. Spør kvar side kva ho framhandla, fordi dei to retningane kan vere ulike.
ipsec statusall | grep -i "auth\|proposal"Når éi side nemner eit opplegg den andre ikkje kan produsere, har du funne avviket billetten handla om. Å gje ut CA-en på nytt er den gale reparasjonen, fordi sertifikatet aldri var det som svikta.
Kva RFC 7427 endrar, og kva ho ikkje endrar
Dei opphavlege metodane er nummererte per algoritmekombinasjon i RFC 7296. Den seinare RFC 7427-signaturutvidinga legg til ein generell Digital Signature-metode med signalering av støtte for signaturhash, slik at ein ny hash ikkje lenger treng sitt eige metodenummer. Det blir framhandla, ikkje føresett: ein peer får ikkje utvidinga fordi biblioteket kan tolke dei same sertifikata, og ein peer som berre implementerer dei opphavlege metodane tvingar gatewayen til å halde på éin av dei. Det er ein policyhandel med ein kompatibilitetskostnad, ikkje ein defekt.
Støtta er per retning og per tilkopling, så test bygget du har framføre deg i staden for å stole på ein påstand på familienivå. Ein kapabilitetsmatrise skriven for tre år sidan skildrar bygg som er tre år gamle.
Set fire rader i oversikta
Oppføringa som avsluttar diskusjonen har fire linjer, kvar lesen frå ein annan stad og kvar endra av ein annan person. Fyll ho ut før du avgjer noko, fordi den rada som er feil er den som vel reparasjonen.
| Objekt | Kvar det blir lese | Kven som endrar det |
|---|---|---|
| signaturen til sertifikatutstadaren | feltet Signature Algorithm i sertifikatet | CA-operatøren, ved utgivinga |
| offentleg nøkkel til subjektet | feltet Public Key Algorithm i sertifikatet | den som genererer subjektnøkkelen |
| IKE-autentiseringsopplegg | daemonlogg eller tilkoplingsliste, auth- og signature-hash-varsel | IKE-profilen på båe peerane |
| IKE- og ESP-vernalgoritmar | forslagslista til tilkoplinga | IPsec-profilen, per retning |
Kvar rad ber sin eigen kompatibilitetskonsekvens. Ei endring av ESP-chiffer vel ikkje signaturen til utstadaren, og å lempe på CA-valideringa legg ikkje til ein nettbasert metode peerane aldri framhandla. Når ein billett hevdar eit signaturavvik, er rada som faktisk er feil nesten aldri den første.
Løys det gamle tilfellet utan å svekkje PKI-en
Ein eldre peer tilbyr kanskje berre eit opplegg som policyen din ikkje lenger tillèt. Vala er eit tidsavgrensa kompatibilitetsunntak, ein klientoppdatering eller ei anna autentiseringsordning berre for den peeren. Å byggje PKI-en på nytt rundt ein veikare sertifikatsignatur rettar ikkje ei avgrensing i den nettbaserte utvekslinga og svekkjer alle andre tenester som stoler på same CA. Før opp kva rad du endra og når unntaket går ut.
Køyr deretter dei to lesingane på nytt frå toppen, fordi ei endring i éi rad kan flytte det som blir framhandla i ei anna. Heile oversikta er to kommandoar og ein tabell, og det er same arbeidet anten peeren er ein ruter, ein berbar datamaskin eller eit apparat.