PKCS12, PEM vai DER: kas VPN klientam patiešām nepieciešams
Iesaiņojums nosaka, vai klients importēs identitāti, nevis vai tai uzticas. Salīdziniet PKCS12, PEM un DER, pēc tam pārbaudiet.
Sertifikātu diskusijās klīst divi apgalvojumi. Pirmais — ka .p12 ir stiprais variants un .pem ir vaļīgais; otrais — ka teksta fails ir droši jāsūta, jo to var izlasīt. Neviens no tiem neiztur minūti pārbaudes.
PKCS12, PEM un DER apraksta, kā sertifikātu objekti tiek iesaiņoti un kodēti. Tie nenosaka, kas ir otrā puse, vai izdevējam uzticas, vai failam vajag paroli.
Tas, ko klients pieņem, ir saderības jautājums. Tas, ko fails satur, ir identitātes jautājums. Šķiriet tos un lielākā daļa importēšanas kļūdu pārstās būt noslēpumainas.
Trīs konteineri, viens objektu modelis
Sāciet ar to, kas jums tiešām ir. Sertifikāts ir parakstīts apgalvojums par publisko atslēgu. Privātā atslēga ir atsevišķs materiāls, kas pierāda, ka jūs kontrolējat šo atslēgu. Ķēde ir izdevēju kopa, kas saista jūsu sertifikātu ar sakni, kurai klients uzticas. Visi trīs pastāv neatkarīgi no iesaiņojuma.
PKCS12 fails, parasti .p12 vai .pfx, ir RFC 7292 definēts konteiners, kas var pārnēsāt privāto atslēgu, vienu vai vairākus sertifikātus un ķēdi vienā ar paroli aizsargātā blokā, ar aizstājvārdu, kas nosauc identitāti. PEM fails ir RFC 7468 definēts teksta ietvars: base64 pamatteksts starp BEGIN un END rindām, un viens fails var saturēt vairākus blokus pēc kārtas. DER ir to pašu ASN.1 struktūru binārais kodējums, un PEM pamatteksts ir burtiski base64 ietīts DER.
Pēdējais teikums ir vērts palikt atmiņā. Pārveidojot PEM uz DER, tiek pārrakstīts ietvars, nevis saturs, un pretējā pārveide atgriež sākotnējos baitus.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
Kodējums nav šifrēšana
base64 ir transporta alfabēts. Tas neko neslēpj, un ikviens var atšifrēt PEM bloku čaulā. DER fails ir binārs un tikpat publisks. Neviena īpašība nav aizsardzība, un neviena nenozīmē, ka pastāv parole.
Īsta aizsardzība ir atslēgas materiālā. PKCS12 kopums var šifrēt savu saturu ar no paroles atvasinātu atslēgu. PEM privāto atslēgu var šifrēt ar vecu galvenes bloku vai glabāt PKCS#8 EncryptedPrivateKeyInfo. Sertifikāts pats par sevi neko slepenu neglaba, tāpēc eksports, kas deva tikai sertifikātu, atstāj klientu nespējīgu autentificēties, lai kādā formātā jūs to ietītu.
Paplašinājums ir mājiens, nevis līgums. Faili, kas beidzas ar .cer un .crt, parādās abos kodējumos, un ierīces pietiekami bieži eksportē DER sertifikātus ar .pem nosaukumiem, lai minēšana pēc galotnes izmaksātu pēcpusdienu. Lasiet pirmos baitus: PEM fails sākas ar BEGIN rindu, bet DER sākas ar 0x30, jo ārējā struktūra ir SEQUENCE.
Kāpēc imports patiešām neizdodas
Klienta kļūdu ziņojumi saspiež vairākas dažādas problēmas vienā teikumā par nederīgu sertifikātu, tāpēc šķiriet tās pēc cēloņa. Visbiežākā ir kodējuma neatbilstība: klients, kas parsē PEM, DER failam atgriež parsēšanas kļūdu, un risinājums ir pārveide, nevis jauns sertifikāts. Otrā ir trūkstoša atslēga, kad sertifikāts ir kārtībā un identitāti nevar pierādīt. Trešā ir ķēde, kad kopums bez starpsertifikāta importa dialogā izskatās pareizi un cērtas rokas spiedienā.
Šifrēšanas parametri izraisa ceturto, un tā izskatās tieši kā nepareiza parole. Vecākas ierīces eksportēja PKCS12 failus ar RC2-40 un 3DES, ko OpenSSL 3 atsaka, ja nav ielādēts legacy nodrošinātājs. Atkārtota eksportēšana no ierīces ar AES-256-CBC un PBKDF2 ir ilgtspējīgs risinājums. Atstāt vecos šifrus pastāvīgi ieslēgtus klienta datorā viena faila dēļ ir slikts darījums.
Piektais ir nenoteiktība. Konteiners ar divām atslēgām un diviem sertifikātiem vai PEM fails ar trim CERTIFICATE blokiem liek klientam izvēlēties, un tā izvēle bieži vien ir vienkārši pirmais elements. Kad tunelis paceļas ar nepareizu identitāti, tas parasti ir iemesls.
Pārbaudiet pirms pārveides
Lasiet struktūru, neizdrukājot noslēpumus. openssl pkcs12 -in bundle.p12 -info -noout ziņo par šifrēšanas algoritmiem un aizstājvārdiem, nomācot atslēgas un sertifikāta izvadi, un openssl-pkcs12 rokasgrāmata dokumentē karodziņus. Noņemt -noout un pievienot -nodes ir domāts failu veidošanai, ko plānojat glabāt, nevis ātram skatam, jo tas ieraksta privāto atslēgu atklātā veidā.
Sertifikātam openssl x509 -in cert.pem -noout -subject -issuer -dates atbild uz to, ko importa dialogs neatbildēs, un, pievienojot -ext subjectAltName, tiek parādīti vārdi, kuriem sertifikāts patiešām ir derīgs. Ja fails ir DER, pievienojiet -inform DER; šis viens karodziņš atrisina lielāko daļu unable-to-load kļūdu.
Atslēgas sasaiste ar sertifikātu ir mehāniska, un to ir vērts izdarīt pirms jebkura importa:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Identiski kopsavilkumi nozīmē, ka pāris pieder kopā. Atšķirīgi kopsavilkumi nozīmē, ka jums ir nepareiza atslēga, un nekāda formāta pārveide to nemainīs.
Ko formāts nekad nemaina
Uzticības lēmumi tiek pieņemti virs konteinera. Klients iet pa ķēdi līdz saknei savā krātuvē, pārbauda derīguma logu, pārbauda paplašināto atslēgas lietojumu klienta autentifikācijai, un servera pusē pārbauda, vai nosaukums, uz kuru tas zvanīja, ir sertifikātā. Neviens no šiem soļiem nelasa faila paplašinājumu.
Tāpēc faila pārdēvēšana, līdz kļūda pazūd, ir tik uzticams laika tērēšanas veids. Imports izdodas, identitāte joprojām ir nepareiza, un kļūme atgriežas rokas spiediena laikā, kur ziņojums ir mazāk noderīgs. Tāpēc arī kopums, kas eksportēts pirms diviem gadiem, tiek importēts tīri un tomēr tiek noraidīts: derīguma termiņš ceļoja sertifikāta iekšienē, nevis faila nosaukumā.
Secība, kas izvairās no pārstrādes
Pajautājiet klienta dokumentācijai, kādus kodējumus tas pieņem un kādu konteineru tas sagaida klienta identitātei, un tad apskatiet, ko jums iedeva. Ja klients grib vienu importējamu identitāti un jums ir atsevišķi PEM faili, izveidojiet kopumu vienreiz ar paroli, kuru kontrolējat, un saglabājiet avotus. Ja tas grib PEM, izvelciet atslēgu un ķēdi, un pēc tam noņemiet starpfailus ar to akreditācijas datu apstrādes procesu, ko jūsu komanda jau izmanto.
Pēc importa pārbaudiet identitāti, nevis dialogu: subjekts, izdevējs, termiņš un nosaukums, ko klients uzrādīs. Draudzīgs nosaukums sarakstā ir etiķete, nevis pārbaudīta identitāte. Ja pēc tam tunelis neizdodas, jūs atkļūdojat autentifikāciju vai maršrutēšanu, nevis iesaiņojumu, un tā ir daudz īsāka saruna.