PKCS12, PEM edo DER: zer behar duen benetan VPN bezero batek
Paketatzeak erabakitzen du bezeroak identitatea inportatzen duen ala ez, ez ea fidagarria den. Konparatu PKCS12, PEM eta DER, eta gero egiaztatu.
Ziurtagiriei buruzko eztabaidetan bi baieztapen dabiltza. Lehena .p12 aukera sendoa dela eta .pem ahula; bigarrena, testu-fitxategi bat bidaltzeko segurua izan behar dela irakur dezakezulako. Bietako batek ere ez du minutu bateko ikuskapenik gainditzen.
PKCS12, PEM eta DERek ziurtagiri-objektuak nola paketatzen eta kodeatzen diren deskribatzen dute. Ez dute erabakitzen nor den beste aldea, igorlea fidagarria den edo fitxategiak pasahitza behar duen.
Bezeroak zer onartzen duen bateragarritasun-kontua da. Fitxategiak zer daukan identitate-kontua da. Biak bereizten badituzu, inportazio-errore gehienek misterioa izateari utziko diote.
Hiru edukiontzi, objektu-eredu bat
Hasi benetan daukazunarekin. Ziurtagiria gako publiko bati buruzko sinatutako adierazpena da. Gako pribatua gako hori kontrolatzen duzula frogatzen duen material bereizia da. Katea zure ziurtagiria bezeroak fidatzen duen erro batekin lotzen duten igorleen multzoa da. Hirurak paketatzeaz aparte existitzen dira.
PKCS12 fitxategia, normalean .p12 edo .pfx, RFC 7292n definitutako edukiontzia da, eta gako pribatu bat, ziurtagiri bat edo gehiago eta katea pasahitzez babestutako bloke bakarrean eraman ditzake, identitatea izendatzen duen alias batekin. PEM fitxategia RFC 7468n definitutako testu-markoa da: base64 gorputza BEGIN eta END lerroen artean, eta fitxategi batek hainbat bloke eduki ditzake segidan. DER egitura ASN.1 beren kodeaketa bitarra da, eta PEM gorputza literalki base64z bildutako DER da.
Azken esaldi hori gogoratzeko modukoa da. PEM DER bihurtzeak markoa berridazten du, ez edukia, eta itzultzeak jatorrizko byteak itzultzen ditu.
| 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 |
Kodeatzea ez da zifratzea
Base64 garraio-alfabetoa da. Ez du ezer ezkutatzen, eta edonork deskoditu dezake PEM bloke bat shell batean. DER fitxategia bitarra da eta berdin publikoa. Bi propietate horietako bat ere ez da babesa, eta batek ere ez du pasahitzarik badenik adierazten.
Benetako babesa gako-materialean dago. PKCS12 sorta batek bere edukia pasahitzetik eratorritako gako batekin zifra dezake. PEM gako pribatu bat goiburu bloke zahar batekin zifra daiteke edo PKCS#8 EncryptedPrivateKeyInfo barruan gorde. Ziurtagiri batek bakarrik ez du ezer sekreturik gordetzen, horregatik ziurtagiri bat soilik eman zuen esportazioak bezeroa autentifikatzeko gai ez dela uzten du, edozein formatutan bildu ere.
Luzapena argibidea da, ez kontratua. .cer eta .crt amaitzen diren fitxategiak bi kodeaketetan agertzen dira, eta gailuek DER ziurtagiriak .pem izenekin hain maiz esportatzen dituzte, non atzizkiaren arabera asmatzeak arratsalde bat kostatzen duen. Irakurri lehen byteak horren ordez: PEM fitxategia BEGIN lerro batekin hasten da, eta DER 0x30ekin hasten da kanpoko egitura SEQUENCE delako.
Zergatik huts egiten duen inportazioak benetan
Bezeroaren errore-mezuak hainbat arazo esaldi bakarrean sakatzen ditu ziurtagiri baliogabe bati buruz, beraz bereizi itzazu arrazoiaren arabera. Ohikoena kodeaketa-desadostasuna da: PEM analizatzen duen bezero batek analisi-errorea itzultzen du DER fitxategi batekin, eta konponbidea bihurtzea da, ez ziurtagiri berri bat. Bigarrena falta den gakoa da, non ziurtagiria ondo dagoen eta identitatea ere ezin den frogatu. Hirugarrena katea da, non tarteko ziurtagiririk gabeko sorta ondo ikusten den inportazio-elkarrizketan eta esku-ematean huts egiten duen.
Zifratze-parametroek laugarrena eragiten dute, eta pasahitz oker baten itxura zehatza du. Gailu zaharrek PKCS12 fitxategiak RC2-40 eta 3DESekin esportatzen zituzten, eta OpenSSL 3k ukatu egiten ditu legacy hornitzailea kargatu ezean. Gailutik AES-256-CBC eta PBKDF2rekin berriro esportatzea da irtenbide iraunkorra. Fitxategi bakarra lortzeko makineria bezero batean zifratze zaharrak betiko piztuta uztea negozio txarra da.
Bosgarrena anbiguotasuna da. Bi gako eta bi ziurtagiri dituen edukiontzi batek, edo hiru CERTIFICATE bloke dituen PEM fitxategi batek, bezeroa aukeratzera behartzen du, eta haren aukera lehen elementua izan ohi da. Tunel bat identitate okerrarekin altxatzen denean, hori izaten da arrazoia.
Ikuskatu bihurtu aurretik
Irakurri egitura sekretuak inprimatu gabe. openssl pkcs12 -in bundle.p12 -info -noout komandoak zifratze-algoritmoak eta aliasak jakinarazten ditu gakoaren eta ziurtagiriaren irteera isilaraziz, eta openssl-pkcs12 eskuliburuak banderak dokumentatzen ditu. -noout kentzea eta -nodes gehitzea gordeko dituzun fitxategiak sortzeko da, ez begirada azkar baterako, gako pribatua agerian idazten duelako.
Ziurtagiri batentzat, openssl x509 -in cert.pem -noout -subject -issuer -dates komandoak inportazio-elkarrizketa batek erantzungo ez lukeena erantzuten du, eta -ext subjectAltName gehitzeak ziurtagiria benetan balio duen izenak erakusten ditu. Fitxategia DER bada, gehitu -inform DER; bandera bakar horrek unable-to-load errore gehienak konpontzen ditu.
Gako bat ziurtagiri batekin parekatzea mekanikoa da, eta inportazio edozein egin aurretik merezi du:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Digest berberek bikotea elkarrekin doala esan nahi dute. Digest ezberdinek gako okerra daukazula esan nahi dute, eta formatu-bihurtze batek ere ez du hori aldatuko.
Formatuak inoiz aldatzen ez duena
Konfiantza-erabakiak edukiontziaren gainetik gertatzen dira. Bezeroak katea zeharkatzen du bere biltegiko erro bateraino, baliozkotasun-leihoa egiaztatzen du, gakoaren erabilera hedatua egiaztatzen du bezeroaren autentifikaziorako, eta zerbitzariaren aldean markatutako izena ziurtagirian agertzen dela egiaztatzen du. Urrats horietako batek ere ez du fitxategi-luzapenik irakurtzen.
Horregatik da hain modu fidagarria denbora galtzeko fitxategi bat errore bat desagertu arte berrizendatzea. Inportazioak arrakasta du, identitatea okerra da oraindik, eta hutsegitea esku-ematean agertzen da berriro, mezua lagungarriagoa ez den tokian. Horregatik ere duela bi urte esportatutako sorta bat garbi inportatzen da eta hala ere baztertzen da: iraungitze-data ziurtagiriaren barruan bidaiatu zen, ez fitxategi-izenean.
Berregitea saihesten duen ordena
Galdetu bezeroaren dokumentazioari zein kodeaketa onartzen dituen eta zein edukiontzi espero duen bezero-identitate batentzat, eta gero begiratu eman dizutena. Bezeroak inporta daitekeen identitate bakarra nahi badu eta PEM fitxategi solteak badituzu, eraiki sorta behin kontrolatzen duzun pasahitz batekin eta gorde iturriak. PEM nahi badu, atera gakoa eta katea, eta gero ezabatu tarteko fitxategiak zure taldeak jada erabiltzen duen kredentzialen kudeaketa-prozesuaren bidez.
Inportatu ondoren, egiaztatu identitatea eta ez elkarrizketa: subjektua, igorlea, iraungitzea eta bezeroak aurkeztuko duen izena. Zerrendako izen atsegina etiketa bat da, ez egiaztatutako identitatea. Gero tunelak huts egiten badu, autentifikazioa edo bideratzea ari zara arazten, paketatzea beharrean, eta hori askoz elkarrizketa laburragoa da.