IKEv2 ima dva potpisa: certifikat i IKE_AUTH

Vaš tiket kaže da je certifikat SHA-256, dok zapisnik gatewaya navodi drugi algoritam potpisa, a neko je već sastavio zahtjev za ponovno izdavanje CA. Prije nego taj zahtjev bilo kuda ode, razdvojite dva potpisa: jedan je pečat izdavaoca na javnom ključu, drugi je dokaz peera da drži odgovarajući privatni ključ tokom IKE_AUTH. Različite komponente ih biraju i smiju se razlikovati. Čitanje svakog s mjesta gdje živi traži dvije komande i jednu tabelu.

Pročitajte izdavaočev potpis iz certifikata

CA stavlja svoj potpis na vezu između identiteta i ključa. Taj potpis bilježi šta je CA uradio pri izdavanju, a ne šta će subjekt uraditi pri povezivanju, pa njegov algoritam opisuje CA-ov vlastiti izbor hash-a i ključa. Ključ subjekta jedne vrste može stajati pod ključem CA druge vrste bez ikakve nedosljednosti, a rotacija CA ključa je rutina, a ne kvar. Pročitajte dva polja i imate pola inventara:

openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"

Zapišite obje oznake kao odvojene stavke. Prva opisuje CA, druga opisuje subjektov ključ, i nijedna ne predviđa online potpis.

Pročitajte online potpis iz IKE razmjene

Tokom autentifikacije svaki peer potpisuje podatke razmjene svojim privatnim ključem, a suprotna strana provjerava taj dokaz prema identitetu certifikata, lancu povjerenja i politici. Za RSA padding i hash pripadaju ovoj online shemi, pa duži ključ ili svjež SHA-256 certifikat sami po sebi ne mogu izabrati RSA-PSS za potpis autentifikacije. Dogovorena metoda pojavljuje se u zapisniku daemona ili u njegovom spisku veza, nikada u certifikatu. Pitajte svaku stranu šta je dogovorila, jer se dva smjera mogu razlikovati.

ipsec statusall | grep -i "auth\|proposal"

Kada jedna strana navede shemu koju druga ne može proizvesti, našli ste nesklad o kojem je tiket bio. Ponovno izdavanje CA je pogrešan popravak za to, jer certifikat nikada nije bio ono što je zakazalo.

Šta RFC 7427 mijenja, a šta ne

Originalne metode su numerisane po kombinaciji algoritama u RFC 7296. Kasnije proširenje potpisa RFC 7427 dodaje opću metodu Digital Signature sa signalizacijom podrške za hash potpisa, pa novi hash više ne treba vlastiti broj metode. To se dogovara, ne pretpostavlja: peer ne dobija proširenje zato što njegova biblioteka može parsirati iste certifikate, a peer koji implementira samo originalne metode prisiljava gateway da zadrži jednu od njih. To je politička razmjena s troškom kompatibilnosti, a ne defekt.

Podrška je po smjeru i po vezi, pa testirajte build ispred sebe umjesto da vjerujete tvrdnji na nivou porodice. Matrica sposobnosti napisana prije tri godine opisuje buildove stare tri godine.

Stavite četiri reda u inventar

Zapis koji završava raspravu ima četiri reda, svaki pročitan s drugog mjesta i svaki promijenjen od druge osobe. Popunite ga prije bilo kakve odluke, jer red koji je pogrešan određuje popravak.

Svaki red nosi vlastitu posljedicu za kompatibilnost. Promjena ESP šifre ne bira izdavaočev potpis, a popuštanje CA validacije ne dodaje online metodu koju peerovi nikada nisu dogovorili. Kada tiket tvrdi nesklad potpisa, red koji je zaista pogrešan gotovo nikada nije prvi.

Riješite stari slučaj bez slabljenja PKI

Stariji peer može ponuditi samo shemu koju vaša politika više ne dopušta. Izbori su vremenski ograničena iznimka za kompatibilnost, ažuriranje klijenta ili drugačiji aranžman autentifikacije samo za taj peer. Obnova PKI oko slabijeg potpisa certifikata ne popravlja ograničenje u online razmjeni i slabi svaku drugu uslugu koja vjeruje istom CA. Zabilježite koji ste red promijenili i kada iznimka istječe.

Zatim ponovno izvedite oba čitanja odozgo, jer promjena u jednom redu može pomjeriti ono što se dogovara u drugom. Cijeli inventar je dvije komande i jedna tabela, i to je isti posao bio peer ruter, laptop ili uređaj.