IKEv2 má dva podpisy: certifikát a IKE_AUTH

Váš tiket tvrdí, že certifikát je SHA-256, kým log brány uvádza iný algoritmus podpisu, a niekto už pripravil žiadosť o opätovné vydanie CA. Skôr než tá žiadosť niekam pôjde, oddeľte dva podpisy: jeden je pečať vydavateľa na verejnom kľúči, druhý je dôkaz partnera, že má počas IKE_AUTH zodpovedajúci súkromný kľúč. Vyberajú ich rôzne komponenty a smú sa líšiť. Prečítať každý z miesta, kde žije, vyžaduje dva príkazy a jednu tabuľku.

Prečítajte podpis vydavateľa z certifikátu

CA umiestňuje svoj podpis na väzbu medzi identitou a kľúčom. Ten podpis zaznamenáva, čo CA urobila pri vydaní, nie čo urobí subjekt pri pripojení, preto jeho algoritmus opisuje vlastnú voľbu hashu a kľúča zo strany CA. Kľúč subjektu jedného typu môže ležať pod kľúčom CA iného typu bez akejkoľvek nekonzistencie a rotácia kľúča CA je rutina, nie porucha. Prečítajte obe polia a máte polovicu inventára:

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

Zapíšte obe označenia ako samostatné položky. Prvé opisuje CA, druhé opisuje kľúč subjektu a ani jedno nepredpovedá online podpis.

Prečítajte online podpis z výmeny IKE

Počas autentizácie každý partner podpisuje údaje výmeny svojím súkromným kľúčom a druhá strana overuje tento dôkaz proti identite, reťazcu dôvery a politike certifikátu. Pri RSA patrí doplnenie a hash tomuto online schematu, takže dlhší kľúč ani nový certifikát SHA-256 sám nedokáže zvoliť RSA-PSS pre autentizačný podpis. Vyjednaná metóda sa objavuje v logu démona alebo v jeho zozname spojení, nikdy v certifikáte. Opýtajte sa každej strany, čo vyjednala, pretože oba smery sa môžu líšiť.

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

Keď jedna strana uvedie schému, ktorú druhá nedokáže vytvoriť, našli ste nezhodu, o ktorú išlo v tikete. Opätovné vydanie CA je pre to nesprávna oprava, pretože zlyhalo niečo iné ako certifikát.

Čo mení RFC 7427 a čo nie

Pôvodné metódy sú číslované podľa kombinácie algoritmov v RFC 7296. Neskoršie rozšírenie podpisu RFC 7427 pridáva všeobecnú metódu Digital Signature so signalizáciou podpory hashu podpisu, takže nový hash už nepotrebuje vlastné číslo metódy. Vyjednáva sa to, nepredpokladá: partner nezíska rozšírenie preto, že jeho knižnica dokáže parsovať tie isté certifikáty, a partner, ktorý implementuje len pôvodné metódy, núti bránu ponechať si jednu z nich. Je to politická výmena s nákladom na kompatibilitu, nie defekt.

Podpora je pre každý smer a každé spojenie, preto testujte zostavenie, ktoré máte pred sebou, namiesto dôvery tvrdeniu na úrovni rodiny. Matica schopností napísaná pred tromi rokmi opisuje zostavenia staré tri roky.

Vložte do inventára štyri riadky

Záznam, ktorý ukončí spor, má štyri riadky, každý prečítaný z iného miesta a každý zmenený inou osobou. Vyplňte ho pred akýmkoľvek rozhodnutím, pretože práve nesprávny riadok vyberá opravu.

Každý riadok nesie svoj vlastný dôsledok pre kompatibilitu. Zmena šifry ESP nevyberá podpis vydavateľa a uvoľnenie validácie CA nepridá online metódu, ktorú partneri nikdy nevyjednali. Keď tiket tvrdí nezhodu podpisu, riadok, ktorý je naozaj nesprávny, takmer nikdy nie je prvý.

Vyriešte starý prípad bez oslabenia PKI

Starší partner môže ponúknuť len schému, ktorú vaša politika už nepovoľuje. Možnosti sú časovo obmedzená výnimka pre kompatibilitu, aktualizácia klienta alebo iné usporiadanie autentizácie len pre tohto partnera. Prestavba PKI okolo slabšieho podpisu certifikátu neopraví obmedzenie online výmeny a oslabí každú ďalšiu službu, ktorá dôveruje tej istej CA. Zaznamenajte, ktorý riadok ste zmenili a kedy výnimka vyprší.

Potom znova spustite obe čítania od začiatku, pretože zmena v jednom riadku môže posunúť to, čo sa vyjednáva v inom. Celý inventár sú dva príkazy a jedna tabuľka a je to tá istá práca, či je partner router, notebook alebo zariadenie.