IKEv2 má dva podpisy: certifikát a IKE_AUTH

Váš tiket tvrdí, že certifikát je SHA-256, zatímco log brány uvádí jiný algoritmus podpisu, a někdo už připravil žádost o opětovné vydání CA. Než ta žádost někam odejde, oddělte dva podpisy: jeden je pečeť vydavatele na veřejném klíči, druhý je důkaz protějšku, že během IKE_AUTH drží odpovídající soukromý klíč. Vybitají je různé komponenty a smějí se lišit. Přečíst každý z místa, kde žije, vyžaduje dva příkazy a jednu tabulku.

Přečtěte podpis vydavatele z certifikátu

CA umisťuje svůj podpis na vazbu mezi identitou a klíčem. Ten podpis zaznamenává, co CA udělala při vydání, ne co subjekt udělá při připojení, takže jeho algoritmus popisuje vlastní volbu hashe a klíče ze strany CA. Klíč subjektu jednoho typu může ležet pod klíčem CA jiného typu bez jakékoli nekonzistence a rotace klíče CA je rutina, ne závada. Přečtěte obě pole a máte polovinu inventáře:

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

Zapište obě označení jako samostatné položky. První popisuje CA, druhé popisuje klíč subjektu a ani jedno nepředpovídá online podpis.

Přečtěte online podpis z výměny IKE

Během autentizace každý protějšek podepisuje data výměny svým soukromým klíčem a druhá strana ověřuje tento důkaz proti identitě certifikátu, řetězci důvěry a politice. U RSA patří odsazení a hash tomuto online schématu, takže delší klíč ani nový certifikát SHA-256 sám o sobě nemůže pro autentizační podpis zvolit RSA-PSS. Vyjednaná metoda se objevuje v logu démona nebo v jeho seznamu spojení, nikdy v certifikátu. Zeptejte se každé strany, co vyjednala, protože oba směry se mohou lišit.

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

Když jedna strana uvede schéma, které druhá nedokáže vytvořit, našli jste nesoulad, o kterém tiket byl. Opětovné vydání CA je pro něj špatná oprava, protože certifikát nikdy nebyl to, co selhalo.

Co RFC 7427 mění a co ne

Původní metody jsou číslovány podle kombinace algoritmů v RFC 7296. Pozdější rozšíření podpisu RFC 7427 přidává obecnou metodu Digital Signature se signalizací podpory hashe podpisu, takže nový hash už nepotřebuje vlastní číslo metody. Vyjednává se, nepředpokládá: protějšek nezíská rozšíření proto, že jeho knihovna umí parsovat stejné certifikáty, a protějšek, který implementuje jen původní metody, nutí bránu ponechat jednu z nich. To je politická výměna s nákladem na kompatibilitu, ne defekt.

Podpora je pro každý směr a každé spojení, proto testujte sestavení před sebou, místo abyste věřili tvrzení na úrovni rodiny. Matice schopností napsaná před třemi lety popisuje sestavení stará tři roky.

Vložte do inventáře čtyři řádky

Záznam, který ukončí spor, má čtyři řádky, každý přečtený z jiného místa a každý změněný jinou osobou. Vyplňte ho, než cokoli rozhodnete, protože chybný řádek je to, co vybírá opravu.

Každý řádek nese svůj vlastní důsledek pro kompatibilitu. Změna šifry ESP nevybírá podpis vydavatele a uvolnění validace CA nepřidá online metodu, kterou protějšky nikdy nevyjednaly. Když tiket tvrdí nesoulad podpisu, řádek, který je skutečně chybný, téměř nikdy není první.

Vyřešte starý případ bez oslabení PKI

Starší protějšek může nabídnout jen schéma, které vaše politika už nepovoluje. Možnosti jsou časově omezená výjimka pro kompatibilitu, aktualizace klienta nebo jiné uspořádání autentizace jen pro tento protějšek. Přestavba PKI kolem slabšího podpisu certifikátu neopraví omezení online výměny a oslabí každou další službu, která důvěřuje stejné CA. Zaznamenejte, který řádek jste změnili a kdy výjimka vyprší.

Potom znovu spusťte obě čtení od začátku, protože změna v jednom řádku může posunout to, co se vyjednává v jiném. Celý inventář jsou dva příkazy a jedna tabulka a je to stejná práce, ať je protějšek router, notebook nebo zařízení.