A fájlkiterjesztések nem azonosítják a kulcsalgoritmusokat, és egy .pem boríték tartalmazhat RSA vagy ECDSA anyagot. A PEM azt írja le, hogyan vannak a bájtok becsomagolva, míg az RSA és az ECDSA különböző algoritmusokat jelöl, és a PKCS12 fájl megint egy harmadik dolog. A strongSwan hitelesítő adatokat bővítményeken és konfigurációs backendon keresztül tölt be, így egy tanúsítvány megjelenhet egy listában, miközben a titkos kulcs soha nem válik használhatóvá. Válassza szét ezeket a rétegeket, mielőtt bármilyen titkot szerkeszt.

A kódolás, az algoritmus és a csomagolás három réteg

Egy kulcsfájlnak van kódolása, algoritmusa és gyakran tárolója. A PEM az ismert base64 boríték; a DER a bináris megfelelője; a PKCS12 egy tanúsítványt csomagol a kulcsával és láncával együtt. A tanúsítványlánc-fájl egy újabb tároló, és általában egyáltalán nem tartalmaz titkos kulcsot. Egyik címke sem mondja meg, hogy a benne lévő anyag RSA vagy ECDSA.

Olvassa ki az algoritmust magából az objektumból. Egy szolgáltató marketingneve vagy egy fájlkiterjesztés nem bizonyíték, mert ugyanaz a kibocsátó különböző kulcstípusokat adhat ki.

Hasonlítsa össze a nyilvános kulcsokat, mielőtt a betöltőt hibáztatná

Egy betöltődő tanúsítvány azt bizonyítja, hogy a tanúsítvány feldolgozható volt, nem azt, hogy a titkos kulcsa jelen van vagy használható. Vezesse le a nyilvános kulcsot a tanúsítványból és a javasolt titkos kulcsból, majd hasonlítsa össze a két kivonatot. Ha bármelyik kinyerés meghiúsul, álljon meg ott, mert egy üres kimenet kivonata semmit sem bizonyít. Az egyező kivonatok bizonyítják, hogy a pár összetartozik, és semmi többet arról, hogy a tanúsítvány alkalmas-e a feladatra.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

A második parancs a gépén lévő titkos anyagot érinti, de csak a nyilvános felét adja ki. Tartsa így, és soha ne illesszen be titkos kulcsot egy jegybe. Ha a kulcs titkosított, hagyja, hogy a támogatott eszköz kérje be a jelmondatot, ahelyett hogy parancssorba tenné, ahol a folyamatlista felfedheti.

Régi ipsec.secrets vagy swanctl hitelesítő adatok

A strongSwannak két gyakran használt hitelesítőadat-útvonala van. A régi starter verem típus-specifikus bejegyzéseket olvas innen: ipsec.secrets, és minden bejegyzésnek a helyes típust kell megneveznie az anyaghoz. A swanctl és vici verem a saját hitelesítőadat-könyvtárából tölti be a kulcsokat a saját konfigurációján keresztül. Annak a fájlnak a szerkesztése, amelyet a futó backend nem olvas, semmit sem változtat.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Derítse ki, melyik backend fut valójában, majd helyezze a kulcsot oda, ahová az a backend néz. strongSwan 5.9 régi kézikönyv meghatározza a típus-specifikus titokbejegyzéseket, és ez nem swanctl dokumentáció. A kettő keverése olyan daemont eredményez, amely figyelmen kívül hagy egy fájlt, amelyet az adminisztrátor mérvadónak tart. Az újratöltés, amely nem jelent hibát, csak azt jelenti, hogy a konfiguráció feldolgozható volt.

Olvassa el a betöltési eseményt és a hitelesítési eredményt

Egy ellenőrzött újratöltés után olvassa el a daemon saját betöltési kimenetét az adott kulcsra. A státuszkimentésben felsorolt tanúsítvány nem mutatja, hogy a titkos kulcsot hozzá párosították.

Ha egy kliens továbbra is meghiúsul, tartsa külön a szervereseményt és a klienshibát. A lánc érvényesítése, az identitás egyeztetése és a módszerek kompatibilitása későbbi kérdések a saját bizonyítékaikkal. Írja le az eredményt a pontos kulcsútvonallal és az összehasonlított kivonattal, mert különben a következő műszak ugyanazt az újratöltést ismétli. A CA lecserélése nem az első válasz a betöltő eltérésére.

Kapcsolódó cikkek