PKCS12, PEM aŭ DER: kion VPN-kliento vere bezonas

En diskutoj pri atestiloj cirkulas du asertoj. La unua estas, ke .p12 estas la fortika opcio kaj .pem la malstrikta; la dua, ke tekstdosiero devas esti sendebla sekure ĉar vi povas legi ĝin. Neniu el ili eltenas unu minuton da inspektado.

PKCS12, PEM kaj DER priskribas, kiel atestilaj objektoj estas pakitaj kaj kodigitaj. Ili ne decidas, kiu estas la kontraŭulo, ĉu la eldoninto estas fidinda, aŭ ĉu la dosiero bezonas pasvorton.

Kion la kliento akceptas, estas demando pri kongrueco. Kion la dosiero enhavas, estas demando pri identeco. Tenu ilin aparte kaj plej multaj import-eraroj ĉesas esti misteraj.

Tri ujoj, unu objektmodelo

Komencu per tio, kion vi vere havas. Atestilo estas subskribita deklaro pri publika ŝlosilo. La privata ŝlosilo estas aparta materialo, kiu pruvas, ke vi regas tiun ŝlosilon. Ĉeno estas la aro de eldonintoj, kiuj ligas vian atestilon al radiko, kiun la kliento fidas. Ĉiuj tri ekzistas sendepende de la pakado.

Dosiero PKCS12, kutime .p12 aŭ .pfx, estas ujo difinita en RFC 7292, kiu povas porti privatan ŝlosilon, unu aŭ plurajn atestilojn kaj la ĉenon en unu pasvort-protektita bloko, kun kaŝnomo nomanta la identecon. Dosiero PEM estas teksta kadro difinita en RFC 7468: base64-korpo inter linioj BEGIN kaj END, kaj unu dosiero povas teni plurajn blokojn sinsekve. DER estas la binara kodigo de la samaj ASN.1-strukturoj, kaj la PEM-korpo estas laŭlitere DER envolvita en base64.

Tiu lasta frazo indas memori. Konverti PEM al DER reverkas la kadron, ne la enhavon, kaj rekonverto redonas la originajn bitokojn.

Kodigo ne estas ĉifrado

Base64 estas transporta alfabeto. Ĝi kaŝas nenion, kaj iu ajn povas malĉifri PEM-blokon en ŝelo. Dosiero DER estas binara kaj same publika. Neniu el la du ecoj estas protekto, kaj neniu implicas, ke pasvorto ekzistas.

Vera protekto kuŝas en la ŝlosila materialo. PKCS12-pakaĵo povas ĉifri sian enhavon per ŝlosilo derivita de pasvorto. Privata PEM-ŝlosilo povas esti ĉifrita per malnova kaplinio aŭ tenata en PKCS#8 EncryptedPrivateKeyInfo. Atestilo sola enhavas nenion sekretan, tial eksporto, kiu produktis nur atestilon, lasas la klienton nekapabla aŭtentigi, en kiu ajn formato vi envolvus ĝin.

La finaĵo estas aludo, ne kontrakto. Dosieroj finiĝantaj per .cer kaj .crt aperas en ambaŭ kodigoj, kaj aparatoj eksportas DER-atestilojn sub .pem-nomoj sufiĉe ofte, ke diveni laŭ la sufikso kostas posttagmezon. Legu la unuajn bitokojn anstataŭe: PEM-dosiero malfermiĝas per BEGIN-linio, dum DER komenciĝas per 0x30 ĉar la ekstera strukturo estas SEQUENCE.

Kial la importo fakte malsukcesas

Klientaj erarmesaĝoj kunpremas plurajn malsamajn problemojn en unu frazon pri nevalida atestilo, do apartigu ilin laŭ kaŭzo. La plej ofta estas kodiga malkongruo: kliento, kiu analizas PEM, redonas analizan eraron ĉe DER-dosiero, kaj la solvo estas konverto, ne nova atestilo. La dua estas mankanta ŝlosilo, kie la atestilo estas en ordo kaj la identeco ne pruveblas. La tria estas la ĉeno, kie pakaĵo sen sia intera atestilo aspektas ĝusta en la importa dialogo kaj malsukcesas dum la manpremo.

Ĉifraj parametroj kaŭzas kvaran, kaj ĝi aspektas ĝuste kiel malĝusta pasvorto. Pli malnovaj aparatoj eksportis PKCS12-dosierojn kun RC2-40 kaj 3DES, kiujn OpenSSL 3 rifuzas krom se la legacy-provizanto estas ŝargita. Reeksporto el la aparato kun AES-256-CBC kaj PBKDF2 estas la daŭra solvo. Lasi malnovajn ĉifrojn permane ŝaltitaj sur klienta maŝino por unu dosiero estas malbona interŝanĝo.

La kvina estas dusenceco. Ujo tenanta du ŝlosilojn kaj du atestilojn, aŭ PEM-dosiero kun tri CERTIFICATE-blokoj, devigas la klienton elekti, kaj ĝia elekto ofte estas simple la unua ero. Kiam tunelo leviĝas kun la malĝusta identeco, tio kutime estas la kialo.

Inspektu antaŭ ol konverti

Legu la strukturon sen presi sekretojn. openssl pkcs12 -in bundle.p12 -info -noout raportas la ĉifrajn algoritmojn kaj la kaŝnomojn dum ĝi subpremas ŝlosilan kaj atestilan eligon, kaj la manlibro openssl-pkcs12 dokumentas la flagojn. Forigi -noout kaj aldoni -nodes servas por produkti dosierojn, kiujn vi intencas konservi, ne por rapida rigardo, ĉar ĝi skribas la privatan ŝlosilon malkaŝe.

Por atestilo, openssl x509 -in cert.pem -noout -subject -issuer -dates respondas tion, kion importa dialogo ne respondos, kaj aldonante -ext subjectAltName montriĝas la nomoj, por kiuj la atestilo vere validas. Se la dosiero estas DER, aldonu -inform DER; tiu sola flago solvas plej multajn unable-to-load-erarojn.

Parigi ŝlosilon kun atestilo estas mekanike, kaj indas fari ĝin antaŭ iu ajn importo:

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

Identaj resumoj signifas, ke la paro apartenas kune. Malsamaj resumoj signifas, ke vi havas la malĝustan ŝlosilon, kaj neniu formatkonverto tion ŝanĝos.

Kion la formato neniam ŝanĝas

Fiddecidoj okazas super la ujo. La kliento trapasas la ĉenon al radiko en sia konservejo, kontrolas la validecan fenestron, kontrolas etenditan ŝlosiluzon por klienta aŭtentigo, kaj sur la servila flanko kontrolas, ke la nomo, kiun ĝi alvokis, aperas en la atestilo. Neniu el tiuj paŝoj legas dosieran finaĵon.

Tial renomado de dosiero ĝis eraro malaperas estas tiel fidinda maniero malŝpari tempon. La importo sukcesas, la identeco restas malĝusta, kaj la fiasko reaperas dum la manpremo, kie la mesaĝo estas malpli helpa. Tial ankaŭ pakaĵo eksportita antaŭ du jaroj importiĝas pure kaj tamen estas rifuzata: la findato vojaĝis ene de la atestilo, ne en la dosiernomo.

Ordo, kiu evitas relaboron

Demandu la dokumentaron de la kliento, kiujn kodigojn ĝi akceptas kaj kiun ujon ĝi atendas por klienta identeco, kaj poste rigardu, kion oni donis al vi. Se la kliento volas unu importeblan identecon kaj vi havas apartajn PEM-dosierojn, konstruu la pakaĵon unufoje per pasvorto, kiun vi regas, kaj konservu la fontojn. Se ĝi volas PEM, eltiru la ŝlosilon kaj la ĉenon, kaj poste forigu la interajn dosierojn per la akreditila traktado, kiun via teamo jam uzas.

Post la importo, kontrolu la identecon anstataŭ la dialogon: subjekto, eldoninto, findato kaj la nomo, kiun la kliento prezentos. Afabla nomo en listo estas etikedo, ne kontrolita identeco. Se la tunelo poste fiaskas, vi sencimigas aŭtentigon aŭ enkursigon anstataŭ pakadon, kio estas multe pli mallonga konversacio.