PKCS12, PEM vagy DER: mire van valójában szüksége egy VPN-kliensnek

A tanúsítványokról szóló vitákban két állítás kering. Az első, hogy a .p12 az erős lehetőség, a .pem pedig a laza; a második, hogy egy szöveges fájlnak biztonságosnak kell lennie küldésre, mert el tudja olvasni. Egyik sem áll ki egy percnyi vizsgálatot.

A PKCS12, a PEM és a DER azt írja le, hogyan csomagolják és kódolják a tanúsítványobjektumokat. Nem döntik el, ki a másik fél, megbízható-e a kibocsátó, vagy kell-e jelszó a fájlhoz.

Hogy a kliens mit fogad el, az kompatibilitási kérdés. Hogy mi van a fájlban, az identitáskérdés. Tartsa külön a kettőt, és a legtöbb importálási hiba megszűnik rejtélyes lenni.

Három konténer, egy objektummodell

Kezdje azzal, ami valóban van. A tanúsítvány egy nyilvános kulcsról szóló aláírt állítás. A privát kulcs külön anyag, amely bizonyítja, hogy Ön irányítja azt a kulcsot. A lánc a kibocsátók halmaza, amelyek a tanúsítványát egy olyan gyökérhez kapcsolják, amelyben a kliens megbízik. Mindhárom létezik, függetlenül a csomagolástól.

A PKCS12-fájl, általában .p12 vagy .pfx, az RFC 7292-ben meghatározott konténer, amely egyetlen jelszóval védett blokkban hordozhat privát kulcsot, egy vagy több tanúsítványt és a láncot, az identitást megnevező aliasszal. A PEM-fájl az RFC 7468-ban meghatározott szövegkeret: base64 törzs a BEGIN és END sorok között, és egy fájl több blokkot is tartalmazhat egymás után. A DER ugyanazon ASN.1-struktúrák bináris kódolása, a PEM-törzs pedig szó szerint base64-be csomagolt DER.

Az utolsó mondatot érdemes megjegyezni. A PEM DER-ré alakítása a keretet írja át, nem a tartalmat, és a visszaalakítás az eredeti bájtokat adja.

A kódolás nem titkosítás

A base64 szállítási ábécé. Nem rejt el semmit, és bárki dekódolhat egy PEM-blokkot egy shellben. A DER-fájl bináris és ugyanolyan nyilvános. Egyik tulajdonság sem védelem, és egyik sem jelenti azt, hogy létezik jelszó.

Az igazi védelem a kulcsanyagban van. Egy PKCS12-csomag a tartalmát jelszóból származtatott kulccsal titkosíthatja. A PEM privát kulcs titkosítható régi fejlécblokkal, vagy tartható PKCS#8 EncryptedPrivateKeyInfo-ban. A tanúsítvány önmagában semmit sem tart titokban, ezért a csak tanúsítványt adó exportálás képtelenné teszi a klienst a hitelesítésre, akármilyen formátumba csomagolja is.

A kiterjesztés nyom, nem szerződés. A .cer és .crt végződésű fájlok mindkét kódolásban előfordulnak, és az eszközök elég gyakran exportálnak DER-tanúsítványokat .pem néven ahhoz, hogy a végződésből való találgatás egy délutánba kerüljön. Olvassa inkább az első bájtokat: a PEM-fájl BEGIN-sorral nyílik, míg a DER 0x30-cal kezdődik, mert a külső szerkezet egy SEQUENCE.

Miért vall kudarcot valójában az importálás

A kliens hibaüzenetei több különböző problémát préselnek egyetlen, érvénytelen tanúsítványról szóló mondatba, ezért ok szerint válassza szét őket. A leggyakoribb a kódolási eltérés: a PEM-et elemző kliens elemzési hibát ad egy DER-fájlra, és a megoldás az átalakítás, nem az új tanúsítvány. A második a hiányzó kulcs, amikor a tanúsítvány rendben van, és az identitás nem bizonyítható. A harmadik a lánc, amikor a köztes tanúsítvány nélküli csomag helyesnek látszik az importálási párbeszédablakban, és a kézfogás során elbukik.

A titkosítási paraméterek okozzák a negyediket, és az pontosan úgy néz ki, mint egy rossz jelszó. A régebbi eszközök RC2-40 és 3DES titkosítással exportáltak PKCS12-fájlokat, amelyeket az OpenSSL 3 elutasít, hacsak nincs betöltve a legacy szolgáltató. Az eszközből AES-256-CBC és PBKDF2 használatával történő újraexportálás a tartós megoldás. A régi titkosítások állandó bekapcsolva hagyása egy kliensgépen egyetlen fájl miatt rossz üzlet.

Az ötödik a kétértelműség. A két kulcsot és két tanúsítványt tartalmazó konténer, vagy a három CERTIFICATE blokkot tartalmazó PEM-fájl választásra kényszeríti a klienst, és a választása gyakran egyszerűen az első elem. Amikor egy alagút rossz identitással jön fel, általában ez az ok.

Vizsgálja meg átalakítás előtt

Olvassa be a szerkezetet titkok kiírása nélkül. openssl pkcs12 -in bundle.p12 -info -noout jelenti a titkosítási algoritmusokat és az aliasokat, miközben elnyomja a kulcs- és tanúsítványkimenetet, és az openssl-pkcs12 kézikönyv dokumentálja a kapcsolókat. A -noout elhagyása és a -nodes hozzáadása olyan fájlok készítésére való, amelyeket meg akar tartani, nem gyors pillantásra, mert a privát kulcsot nyíltan írja.

Egy tanúsítvány esetében a openssl x509 -in cert.pem -noout -subject -issuer -dates megválaszolja azt, amit egy importálási párbeszédablak nem fog, és a -ext subjectAltName hozzáadásával láthatók azok a nevek, amelyekre a tanúsítvány valóban érvényes. Ha a fájl DER, adja hozzá a -inform DER kapcsolót; ez az egy kapcsoló a legtöbb unable-to-load hibát megoldja.

A kulcs és a tanúsítvány párosítása mechanikus munka, és érdemes bármely importálás előtt elvégezni:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Az azonos kivonatok azt jelentik, hogy a pár összetartozik. Az eltérő kivonatok azt jelentik, hogy rossz kulcsa van, és semmilyen formátumátalakítás nem változtat ezen.

Amit a formátum soha nem változtat meg

A bizalmi döntések a konténer felett születnek. A kliens végigjárja a láncot a tárolójában lévő gyökérhez, ellenőrzi az érvényességi ablakot, ellenőrzi a kiterjesztett kulcshasználatot az ügyfélhitelesítéshez, és a kiszolgáló oldalán ellenőrzi, hogy a hívott név szerepel-e a tanúsítványban. Ezen lépések egyike sem olvas fájlkiterjesztést.

Ezért olyan megbízható időpazarlási mód egy fájlt átnevezni, amíg egy hiba el nem tűnik. Az importálás sikerül, az identitás továbbra is rossz, és a hiba a kézfogás során újra megjelenik, ahol az üzenet kevésbé segít. Ezért importálódik tisztán egy két éve exportált csomag, és mégis elutasítják: a lejárati dátum a tanúsítványban utazott, nem a fájlnévben.

Átdolgozást elkerülő sorrend

Kérdezze meg a kliens dokumentációjától, milyen kódolásokat fogad el, és milyen konténert vár egy kliens-identitáshoz, majd nézze meg, mit kapott. Ha a kliens egyetlen importálható identitást akar, és Önnek külön PEM-fájljai vannak, építse fel a csomagot egyszer egy Ön által irányított jelszóval, és őrizze meg a forrásokat. Ha PEM-et akar, nyerje ki a kulcsot és a láncot, majd távolítsa el a köztes fájlokat a csapata által már használt hitelesítőadat-kezelési folyamattal.

Importálás után az identitást ellenőrizze, ne a párbeszédablakot: tárgy, kibocsátó, lejárat és a név, amelyet a kliens bemutat. A lista barátságos neve címke, nem ellenőrzött identitás. Ha utána az alagút elbukik, hitelesítést vagy útválasztást hibakeres, nem csomagolást, ami sokkal rövidebb beszélgetés.