Az IKEv2-nek két aláírása van: a tanúsítvány és az IKE_AUTH
A CA aláírja a tanúsítványt, a peer pedig saját sémájával írja alá az IKE_AUTH-cseréjét. Olvassa ki mindkettőt a saját mezőjéből, majd rögzítse mindkettőt.
A jegye szerint a tanúsítvány SHA-256, miközben az átjáró naplója más aláírás-algoritmust nevez meg, és valaki már megfogalmazott egy kérést a CA újrakibocsátására. Mielőtt az a kérés bárhová elindulna, válassza szét a két aláírást: az egyik a kibocsátó pecsétje egy nyilvános kulcson, a másik pedig a peer bizonyítéka arra, hogy az IKE_AUTH során birtokolja a hozzá tartozó privát kulcsot. Különböző összetevők választják őket, és megengedett, hogy eltérjenek. Mindkettőt onnan kiolvasni, ahol él, két parancsot és egy táblázatot igényel.
Olvassa ki a kibocsátó aláírását a tanúsítványból
A CA az aláírását egy identitás és egy kulcs közötti kötésre teszi. Ez az aláírás azt rögzíti, amit a CA a kibocsátáskor tett, nem azt, amit az alany a csatlakozáskor tesz majd, ezért algoritmusa a CA saját hash- és kulcsválasztását írja le. Egy típusú alanykulcs lehet más típusú CA-kulcs alatt minden ellentmondás nélkül, és a CA-kulcs rotációja rutin, nem hiba. Olvassa ki a két mezőt, és megvan a leltár fele:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Írja fel mindkét címkét külön bejegyzésként. Az első a CA-t írja le, a második az alany kulcsát, és egyik sem jósolja meg az online aláírást.
Olvassa ki az online aláírást az IKE-cseréből
A hitelesítés során minden peer a saját privát kulcsával írja alá a csereadatokat, a túloldal pedig ezt a bizonyítékot a tanúsítvány identitásához, bizalmi láncához és szabályzatához méri. RSA esetén a kitöltés és a hash ehhez az online sémához tartozik, így egy hosszabb kulcs vagy egy friss SHA-256 tanúsítvány önmagában nem választhat RSA-PSS-t a hitelesítési aláíráshoz. Az egyeztetett módszer a démon naplójában vagy annak kapcsolatlistájában jelenik meg, soha nem a tanúsítványban. Kérdezze meg mindkét oldalt, miben egyezett meg, mert a két irány eltérhet.
ipsec statusall | grep -i "auth\|proposal"Amikor az egyik oldal olyan sémát nevez meg, amelyet a másik nem tud előállítani, megtalálta azt az eltérést, amelyről a jegy szólt. A CA újrakibocsátása erre rossz javítás, mert a tanúsítvány soha nem az volt, ami elbukott.
Mit változtat az RFC 7427, és mit nem
Az eredeti módszerek algoritmus-kombinációnként vannak számozva az RFC 7296-ban. A későbbi RFC 7427 aláírás-kiterjesztés egy általános Digital Signature módszert ad hozzá az aláírás-hash támogatásának jelzésével, így egy új hash-nek már nincs szüksége saját módszerszámra. Ezt egyeztetik, nem feltételezik: a peer nem azért kapja meg a kiterjesztést, mert a könyvtára ugyanazokat a tanúsítványokat tudja értelmezni, és az a peer, amely csak az eredeti módszereket valósítja meg, arra kényszeríti az átjárót, hogy megtartson egyet közülük. Ez szabályzat-alku kompatibilitási költséggel, nem hiba.
A támogatás irányonként és kapcsolatonként értendő, ezért azt a buildet tesztelje, amely előtte van, ne bízzon egy családszintű állításban. Egy három éve írt képességmátrix hároméves buildeket ír le.
Tegyen négy sort a leltárba
A vitát lezáró rekordnak négy sora van, mindegyik máshonnan olvasva és mindegyik más ember által módosítva. Töltse ki, mielőtt bármit eldönt, mert a hibás sor az, amelyik a javítást kiválasztja.
| Objektum | Honnan olvassuk | Ki változtatja |
|---|---|---|
| a tanúsítvány kibocsátójának aláírása | a tanúsítvány Signature Algorithm mezője | a CA üzemeltetője, kibocsátáskor |
| az alany nyilvános kulcsa | a tanúsítvány Public Key Algorithm mezője | aki az alany kulcsát előállítja |
| IKE hitelesítési séma | démonnapló vagy kapcsolatlista, auth és signature-hash értesítés | az IKE-profil mindkét peeren |
| IKE- és ESP-védelmi algoritmusok | a kapcsolat javaslatlistája | az IPsec-profil, irányonként |
Minden sor a saját kompatibilitási következményét hordozza. Az ESP-rejtjel módosítása nem a kibocsátó aláírását választja, a CA-ellenőrzés lazítása pedig nem ad hozzá olyan online módszert, amelyben a peerek soha nem egyeztek meg. Amikor egy jegy aláírás-eltérést állít, a valóban hibás sor szinte soha nem az első.
Oldja meg a régi esetet a PKI gyengítése nélkül
Egy régebbi peer esetleg csak olyan sémát kínál, amelyet a szabályzata már nem engedélyez. A választások egy időben korlátozott kompatibilitási kivétel, egy kliensfrissítés, vagy egy másfajta hitelesítési elrendezés csak arra a peerre. A PKI újjáépítése gyengébb tanúsítvány-aláírás köré nem javítja az online csere korlátját, és gyengít minden más szolgáltatást, amely ugyanabban a CA-ban bízik. Jegyezze fel, melyik sort változtatta meg, és mikor jár le a kivétel.
Ezután futtassa újra a két olvasást felülről, mert az egyik sor változása elmozdíthatja azt, amiről egy másikban megegyeznek. A teljes leltár két parancs és egy táblázat, és ugyanaz a munka, akár router, laptop vagy készülék a peer.