PKCS12, PEM of DER: wat in VPN-klant echt nedich hat
De ferpakking beslûtet oft jo klant de identiteit ymportearret, net oft dy fertroud is. Fergelykje PKCS12, PEM en DER, en ferifiearje dan.
Yn sertifikaatdiskussjes geane twa bewearingen om. De earste is dat in .p12 de sterke opsje is en in .pem de losse; de twadde dat in tekstbestân feilich te ferstjoeren wêze moat om’t jo it lêze kinne. Gjin fan beide hâldt in minút ynspeksje út.
PKCS12, PEM en DER beskriuwe hoe’t sertifikaatobjekten ferpakt en kodearre wurde. Se beslisse net wa’t de tsjinpartij is, oft de útjouwer fertroud is of oft it bestân in wachtwurd nedich hat.
Wat de klant akseptearret is in kompatibiliteitsfraach. Wat it bestân befettet is in identiteitsfraach. Hâld dy twa útinoar en de measte ymportflaters hâlde op geheimsinnich te wêzen.
Trije konteners, ien objektymodel
Begjin mei wat jo wier hawwe. In sertifikaat is in ûndertekene ferklearring oer in iepenbiere kaai. De partikuliere kaai is apart materiaal dat bewiist dat jo dy kaai behearskje. In keatling is de set útjouwers dy’t jo sertifikaat ferbynt mei in woartel dy’t de klant fertrout. Alle trije bestean los fan ’e ferpakking.
In PKCS12-bestân, meast .p12 of .pfx, is in kontener definiearre yn RFC 7292 dy’t in partikuliere kaai, ien of mear sertifikaten en de keatling yn ien troch wachtwurd beskerme blok drage kin, mei in alias dy’t de identiteit neamt. In PEM-bestân is tekstomkadering definiearre yn RFC 7468: in base64-lichem tusken BEGIN- en END-rigels, en ien bestân kin ferskate blokken efterinoar hâlde. DER is de binêre kodearring fan deselde ASN.1-struktueren, en it PEM-lichem is letterlik DER mei base64 d’romhinne.
Dy lêste sin is it wurdich te ûnthâlden. PEM nei DER omsette skriuwt de omkadering oer, net de ynhâld, en werom omsette jout de oarspronklike bytes.
| 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 |
Kodearring is gjin fersifering
Base64 is in ferfiersalfabet. It ferberget neat, en elkenien kin in PEM-blok yn in shell dekodearje. In DER-bestân is binêr en like iepenbier. Gjin fan beide eigenskippen is beskerming, en gjin fan beide betsjut dat der in wachtwurd is.
Echte beskerming sit yn it kaaimateriaal. In PKCS12-bondel kin syn ynhâld fersiferje ûnder in kaai ôflaat fan in wachtwurd. In partikuliere PEM-kaai kin fersifere wurde mei in âld kopblok of bewarre wurde yn PKCS#8 EncryptedPrivateKeyInfo. In sertifikaat allinnich hâldt neat geheims, dêrom lit in eksport dy’t allinnich in sertifikaat joech de klant net autentisearje, yn hokker formaat jo it ek ynpakke.
De útwreiding is in oanwizing, gjin kontrakt. Bestannen dy’t einigje op .cer en .crt komme yn beide kodearrings foar, en apparaten eksportearje DER-sertifikaten sa faak ûnder .pem-nammen dat rieden op ’e efterheaksel in middei kostet. Lês ynstee de earste bytes: in PEM-bestân iepent mei in BEGIN-rigel, wylst DER begjint mei 0x30 om’t de bûtenste struktuer in SEQUENCE is.
Wêrom’t de ymport eins mislearret
Flaterberjochten fan klanten drukke ferskate problemen yn ien sin oer in ûnjildich sertifikaat, dus skied se op reden. It meast foarkommend is in kodearringsôfwiking: in klant dy’t PEM parset jout in parseflater op in DER-bestân, en de oplossing is in omsetting, gjin nij sertifikaat. It twadde is in ûntbrekkende kaai, wêrby’t it sertifikaat goed is en de identiteit net bewiisd wurde kin. It tredde is de keatling, wêrby’t in bondel sûnder syn tuskenlizzende sertifikaat korrekt liket yn it ymportdialooch en mislearret by de hânskudding.
Fersiferingsparameters feroarsaakje in fjirde, en dy liket krekt op in ferkeard wachtwurd. Aldere apparaten eksportearren PKCS12-bestannen mei RC2-40 en 3DES, dy’t OpenSSL 3 wegeret útsein as de legacy-provider laden is. Op ’e nij eksportearje fan it apparaat mei AES-256-CBC en PBKDF2 is de duorsume oplossing. Alde syfers permanint oan litte op in klantmasine foar ien bestân is in minne ruil.
De fyfde is dûbelsinnigens. In kontener mei twa kaaien en twa sertifikaten, of in PEM-bestân mei trije CERTIFICATE-blokken, twingt de klant te kiezen, en syn kar is faak gewoan it earste item. As in tunnel mei de ferkearde identiteit omheech komt, is dat meastentiids de reden.
Ynspektearje foar’t jo omsette
Lês de struktuer sûnder geheimen te printsjen. openssl pkcs12 -in bundle.p12 -info -noout rapportearret de fersiferingsalgoritmen en de aliassen wylst it kaai- en sertifikaatútput ûnderdrukt, en it openssl-pkcs12-hânboek dokumintearret de flaggen. -noout weilitte en -nodes tafoegje is foar it meitsjen fan bestannen dy’t jo bewarje wolle, net foar in flugge eachopslach, om’t it de partikuliere kaai iepen skriuwt.
Foar in sertifikaat beantwurdet openssl x509 -in cert.pem -noout -subject -issuer -dates wat in ymportdialooch net beantwurdzje sil, en mei -ext subjectAltName tafoege lit it de nammen sjen wêr’t it sertifikaat eins jildich foar is. Is it bestân DER, foegje -inform DER ta; dy iene flag lost de measte unable-to-load-flaters op.
In kaai oan in sertifikaat keppelje is meganysk, en wurdich foar elke ymport:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Idinteitske digesten betsjutte dat it pear byinoar heart. Ferskillende digesten betsjutte dat jo de ferkearde kaai hawwe, en gjin formaatomsetting sil dat feroarje.
Wat it formaat nea feroaret
Fertrouwensbesluten wurde boppe de kontener nommen. De klant rint de keatling nei in woartel yn syn opslach, kontrolearret it jildichheidsfinster, kontrolearret it útwreide kaaigebrûk foar klantautentikaasje, en kontrolearret oan ’e serverkant dat de namme dy’t er bellet yn it sertifikaat foarkomt. Gjin fan dy stappen lêst in bestânsútwreiding.
Dêrom is in bestân omneame oant in flater ferdwynt sa’n betroubere manier om tiid te fergripen. De ymport slagget, de identiteit is noch altyd ferkeard, en de flater komt werom by de hânskudding wêr’t it berjocht minder helpend is. Dêrom ymportearret in bondel dy’t twa jier lyn eksportearre is skjin en wurdt dochs wegere: de ferfaldatum reizge yn it sertifikaat, net yn ’e bestânsnamme.
In oarder dy’t werwurk foarkomt
Freegje de dokumintaasje fan ’e klant hokker kodearrings er akseptearret en hokker kontener er foar in klantidentiteit ferwachtet, en sjoch dan nei wat jo krigen hawwe. Wol de klant ien ymportearbere identiteit en hawwe jo losse PEM-bestannen, bou dan de bondel ien kear mei in wachtwurd dat jo behearskje en hâld de boarnen. Wol er PEM, helje dan de kaai en keatling derút, en smyt de tuskenbestannen dêrnei fuort fia it proses foar it omgean mei bewiisstikken dat jo team al brûkt.
Ferifiearje nei de ymport de identiteit ynstee fan it dialooch: ûnderwerp, útjouwer, ferfal en de namme dy’t de klant presintearret. In freonlike namme yn in list is in label, gjin ferifiearre identiteit. Mislarget de tunnel dêrnei, dan debugge jo autentikaasje of routing ynstee fan ferpakking, wat in folle koartere petear is.