IKEv2-l on kaks allkirja: sertifikaat ja IKE_AUTH

Teie pilet väidab, et sertifikaat on SHA-256, samal ajal kui lüüsi logi nimetab teist allkirja algoritmi, ja keegi on juba koostanud taotluse CA uuesti väljaandmiseks. Enne kui see taotlus kuhugi läheb, eraldage kaks allkirja: üks on väljaandja tempel avalikul võtmel, teine on partneri tõestus, et tal on IKE_AUTH ajal vastav privaatvõti. Erinevad komponendid valivad need ja neil on lubatud erineda. Mõlema lugemine sealt, kus see elab, nõuab kahte käsku ja üht tabelit.

Lugege väljaandja allkiri sertifikaadilt

CA paneb oma allkirja identiteedi ja võtme vahelisele sidemele. See allkiri kajastab seda, mida CA väljaandmisel tegi, mitte seda, mida subjekt ühendudes teeb, seega kirjeldab selle algoritm CA enda räsi- ja võtmevalikut. Üht tüüpi subjekti võti võib olla teist tüüpi CA võtme all ilma igasuguse vastuoluta ning CA võtme rotatsioon on rutiin, mitte rike. Lugege kaks välja ja teil on pool inventuurist:

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

Kirjutage mõlemad sildid eraldi kirjetena. Esimene kirjeldab CA-d, teine subjekti võtit, ja kumbki ei ennusta võrgus tehtavat allkirja.

Lugege võrgus tehtav allkiri IKE-vahetusest

Autentimise ajal allkirjastab iga partner vahetusandmed oma privaatvõtmega ja vastaspool kontrollib seda tõestust sertifikaadi identiteedi, usaldusahela ja poliitika vastu. RSA puhul kuuluvad täidis ja räsi selle võrguskeemi juurde, seega pikem võti või värske SHA-256 sertifikaat ei saa iseenesest valida autentimisallkirja jaoks RSA-PSS-i. Kokku lepitud meetod ilmub deemonilogi või selle ühenduste loendisse, mitte kunagi sertifikaadile. Küsige mõlemalt poolelt, milles kokku lepiti, sest kaks suunda võivad erineda.

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

Kui üks pool nimetab skeemi, mida teine ei suuda luua, olete leidnud lahknevuse, millest pilet rääkis. CA uuesti väljaandmine on selle jaoks vale parandus, sest sertifikaat ei olnud kunagi see, mis ebaõnnestus.

Mida RFC 7427 muudab ja mida mitte

Algseid meetodeid nummerdatakse algoritmikombinatsiooni kaupa dokumendis RFC 7296. Hilisem RFC 7427 allkirja laiendus lisab üldise Digital Signature meetodi koos allkirja räsi toe signaliseerimisega, seega uus räsi ei vaja enam omaette meetodinumbrit. See on läbiräägitav, mitte eeldatav: partner ei saa laiendust sellepärast, et tema teek suudab samu sertifikaate parsida, ja partner, kes rakendab ainult algseid meetodeid, sunnib lüüsi ühte neist alles hoidma. See on poliitika vahetus koos ühilduvuskuluga, mitte defekt.

Tugi on suuna ja ühenduse kaupa, seega testige ees olevat ehitust, mitte ei usalda perekonna tasandi väidet. Kolm aastat tagasi kirjutatud võimekuse maatriks kirjeldab kolme aasta vanuseid ehitisi.

Pange inventuuri neli rida

Vaieluse lõpetaval kirjel on neli rida, igaüks loetud eri kohast ja igaüks eri inimese muudetud. Täitke see enne mis tahes otsust, sest just vale rida valib paranduse.

Iga rida kannab oma ühilduvustagajärge. ESP šifri muutus ei vali väljaandja allkirja ja CA valideerimise lõdvendamine ei lisa võrgumeetodit, milles partnerid kunagi kokku ei leppinud. Kui pilet väidab allkirja lahknevust, ei ole tõeliselt vale rida peaaegu kunagi esimene.

Lahendage vana juhtum PKI-d nõrgendamata

Vanem partner võib pakkuda ainult skeemi, mida teie poliitika enam ei luba. Valikud on ajaliselt piiratud ühilduvuserand, kliendi uuendus või teistsugune autentimiskorraldus ainult selle partneri jaoks. PKI ümberehitamine nõrgema sertifikaadi allkirja ümber ei paranda võrgus toimuva vahetuse piirangut ja nõrgendab kõiki teisi teenuseid, mis samale CA-le usaldavad. Kirjutage üles, millist rida muutsite ja millal erand lõpeb.

Seejärel käivitage mõlemad lugemised uuesti algusest, sest muutus ühes reas võib nihutada seda, milles teises kokku lepitakse. Kogu inventuur on kaks käsku ja üks tabel ning see on sama töö, olgu partner ruuter, sülearvuti või seade.