Sertifikatų diskusijose sklando du teiginiai. Pirmasis — kad .p12 yra stiprus variantas, o .pem — laisvas; antrasis — kad tekstinį failą turi būti saugu siųsti, nes jį galima perskaityti. Nė vienas neatlaiko minutės patikros.

PKCS12, PEM ir DER aprašo, kaip sertifikatų objektai supakuojami ir užkoduojami. Jie nenusprendžia, kas yra kita pusė, ar išdavėju pasitikima, ar failui reikia slaptažodžio.

Ką klientas priima, yra suderinamumo klausimas. Ką faile yra, yra tapatybės klausimas. Atskirkite šiuos du dalykus ir dauguma importavimo klaidų nustos būti paslaptingos.

Trys konteineriai, vienas objektų modelis

Pradėkite nuo to, ką iš tikrųjų turite. Sertifikatas yra pasirašytas teiginys apie viešąjį raktą. Privatusis raktas yra atskira medžiaga, įrodanti, kad valdote tą raktą. Grandinė yra išdavėjų rinkinys, jungiantis jūsų sertifikatą su šaknimi, kuria pasitiki klientas. Visi trys egzistuoja nepriklausomai nuo pakavimo.

PKCS12 failas, dažniausiai .p12 arba .pfx, yra RFC 7292 apibrėžtas konteineris, galintis nešti privatųjį raktą, vieną ar daugiau sertifikatų ir grandinę viename slaptažodžiu apsaugotame bloke, su slapyvardžiu, įvardijančiu tapatybę. PEM failas yra RFC 7468 apibrėžtas teksto rėmelis: base64 turinys tarp BEGIN ir END eilučių, ir viename faile gali būti keli blokai iš eilės. DER yra tų pačių ASN.1 struktūrų dvejetainis kodavimas, o PEM turinys yra tiesiog base64 apvyniotas DER.

Paskutinis sakinys vertas įsiminti. Konvertuojant PEM į DER perrašomas rėmelis, o ne turinys, ir konvertavus atgal gaunami pirminiai baitai.

ContainerCan holdDoes not decide
PKCS12 (.p12, .pfx)Key, leaf certificate, chain, alias, passwordWhich root the client trusts
PEM (.pem, .crt, .cer)Any number of base64 blocksWhether the private key is present
DER (.der, .cer)One binary structureThe object type, whatever the extension says

Kodavimas nėra šifravimas

base64 yra transportavimo abėcėlė. Ji nieko neslepia, ir bet kas gali iššifruoti PEM bloką apvalkale. DER failas yra dvejetainis ir lygiai taip pat viešas. Nė viena savybė nėra apsauga, ir nė viena neleidžia manyti, kad yra slaptažodis.

Tikroji apsauga yra raktų medžiagoje. PKCS12 paketas gali užšifruoti savo turinį raktu, išvestu iš slaptažodžio. PEM privatųjį raktą galima užšifruoti senu antraštės bloku arba laikyti PKCS#8 EncryptedPrivateKeyInfo. Sertifikatas vienas nieko slapto nelaiko, todėl eksportas, davęs tik sertifikatą, palieka klientą be galimybės autentifikuotis, kad ir kokiu formatu jį apvyniotumėte.

Plėtinys yra užuomina, o ne sutartis. Failai, besibaigiantys .cer ir .crt, pasitaiko abiejuose kodavimuose, o įrenginiai pakankamai dažnai eksportuoja DER sertifikatus .pem pavadinimais, kad spėjimas pagal galūnę kainuotų popietę. Verčiau skaitykite pirmuosius baitus: PEM failas prasideda BEGIN eilute, o DER prasideda 0x30, nes išorinė struktūra yra SEQUENCE.

Kodėl importavimas iš tikrųjų nepavyksta

Kliento klaidų pranešimai sugrūda keletą skirtingų problemų į vieną sakinį apie negaliojantį sertifikatą, tad atskirkite jas pagal priežastį. Dažniausia yra kodavimo neatitiktis: klientas, analizuojantis PEM, DER failui grąžina analizės klaidą, o sprendimas yra konvertavimas, ne naujas sertifikatas. Antroji yra trūkstamas raktas, kai sertifikatas tvarkingas ir tapatybės įrodyti negalima. Trečioji yra grandinė, kai paketas be tarpinio sertifikato importavimo dialoge atrodo teisingai, o rankos paspaudimo metu nepavyksta.

Šifravimo parametrai sukelia ketvirtąją, ir ji atrodo lygiai kaip neteisingas slaptažodis. Senesni įrenginiai eksportuodavo PKCS12 failus su RC2-40 ir 3DES, kurių OpenSSL 3 atsisako, nebent įkeltas legacy tiekėjas. Pakartotinis eksportas iš įrenginio su AES-256-CBC ir PBKDF2 yra ilgalaikis sprendimas. Palikti senus šifrus nuolat įjungtus kliento kompiuteryje dėl vieno failo yra blogas sandoris.

Penktoji yra dviprasmiškumas. Konteineris su dviem raktais ir dviem sertifikatais, arba PEM failas su trimis CERTIFICATE blokais, verčia klientą rinktis, o jo pasirinkimas dažnai būna tiesiog pirmasis elementas. Kai tunelis pakyla su neteisinga tapatybe, dažniausiai tai ir yra priežastis.

Patikrinkite prieš konvertuodami

Skaitykite struktūrą nespausdindami paslapčių. openssl pkcs12 -in bundle.p12 -info -noout praneša šifravimo algoritmus ir slapyvardžius, slopindamas rakto ir sertifikato išvestį, o openssl-pkcs12 vadove aprašyti vėliavėlės. Pašalinti -noout ir pridėti -nodes skirta failams, kuriuos ketinate saugoti, o ne greitai apžiūrai, nes taip privatusis raktas įrašomas atvirai.

Sertifikatui openssl x509 -in cert.pem -noout -subject -issuer -dates atsako į tai, ko neatsakys importavimo dialogas, o pridėjus -ext subjectAltName parodomi vardai, kuriems sertifikatas iš tikrųjų galioja. Jei failas yra DER, pridėkite -inform DER; viena ši vėliavėlė išsprendžia daugumą unable-to-load klaidų.

Rakto susiejimas su sertifikatu yra mechaninis darbas, ir jį verta atlikti prieš bet kokį importavimą:

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

Ident išvestys reiškia, kad pora priklauso viena kitai. Skirtingos išvestys reiškia, kad turite neteisingą raktą, ir jokia formato konversija to nepakeis.

Ko formatas niekada nekeičia

Pasitikėjimo sprendimai priimami virš konteinerio. Klientas eina grandine iki šaknies savo saugykloje, tikrina galiojimo langą, tikrina išplėstinį rakto naudojimą kliento autentifikacijai, o serverio pusėje tikrina, ar vardas, kuriuo skambinta, yra sertifikate. Nė vienas iš šių žingsnių neskaito failo plėtinio.

Todėl failo pervadinimas tol, kol klaida dingsta, yra toks patikimas laiko švaistymo būdas. Importavimas pavyksta, tapatybė vis dar neteisinga, o gedimas vėl pasirodo rankos paspaudimo metu, kur pranešimas mažiau naudingas. Todėl ir prieš dvejus metus eksportuotas paketas importuojamas švariai ir vis tiek atmetamas: galiojimo data keliavo sertifikato viduje, o ne failo pavadinime.

Tvarka, kuri išvengia perdarymo

Paklauskite kliento dokumentacijos, kokius kodavimus jis priima ir kokio konteinerio tikisi kliento tapatybei, tada pažiūrėkite, ką jums davė. Jei klientas nori vienos importuojamos tapatybės, o jūs turite atskirus PEM failus, sukurkite paketą vieną kartą su jūsų kontroliuojamu slaptažodžiu ir išsaugokite šaltinius. Jei jis nori PEM, ištraukite raktą ir grandinę, o tada pašalinkite tarpinius failus tuo kvalifikacijų tvarkymo procesu, kurį jūsų komanda jau naudoja.

Po importavimo tikrinkite tapatybę, o ne dialogą: subjektas, išdavėjas, galiojimas ir vardas, kurį klientas pateiks. Draugiškas vardas sąraše yra etiketė, o ne patvirtinta tapatybė. Jei tada tunelis nepavyksta, derinate autentifikaciją ar maršrutizavimą, o ne pakavimą, ir tai daug trumpesnis pokalbis.

Susiję straipsniai