PKCS12, PEM vai DER: mitä VPN-asiakas todella tarvitsee

Varmennekeskusteluissa kiertää kaksi väitettä. Ensimmäinen on, että .p12 on vahva vaihtoehto ja .pem löysä; toinen, että tekstitiedoston on oltava turvallinen lähettää, koska voit lukea sen. Kumpikaan ei kestä minuutin tarkastelua.

PKCS12, PEM ja DER kuvaavat, miten varmenneobjektit pakataan ja koodataan. Ne eivät ratkaise, kuka vastapuoli on, onko myöntäjä luotettu tai tarvitseeko tiedosto salasanan.

Se, mitä asiakas hyväksyy, on yhteensopivuuskysymys. Se, mitä tiedosto sisältää, on identiteettikysymys. Pidä ne erillään, niin useimmat tuontivirheet lakkaavat olemasta salaperäisiä.

Kolme säiliötä, yksi objektimalli

Aloita siitä, mitä sinulla todella on. Varmenne on allekirjoitettu väite julkisesta avaimesta. Yksityinen avain on erillinen materiaali, joka todistaa, että hallitset tätä avainta. Ketju on niiden myöntäjien joukko, jotka yhdistävät varmenteesi juureen, johon asiakas luottaa. Kaikki kolme ovat olemassa pakkauksesta riippumatta.

PKCS12-tiedosto, yleensä .p12 tai .pfx, on RFC 7292:ssa määritelty säiliö, joka voi kuljettaa yksityisen avaimen, yhden tai useamman varmenteen ja ketjun yhdessä salasanalla suojatussa lohkossa, identiteetin nimeävän aliaksen kanssa. PEM-tiedosto on RFC 7468:ssa määritelty tekstikehys: base64-runko BEGIN- ja END-rivien välissä, ja yksi tiedosto voi sisältää useita lohkoja peräkkäin. DER on samojen ASN.1-rakenteiden binäärikoodaus, ja PEM-runko on kirjaimellisesti base64:ään kääritty DER.

Tuo viimeinen lause kannattaa muistaa. PEM:n muuntaminen DER:ksi kirjoittaa kehyksen uudelleen, ei sisältöä, ja takaisinmuunnos palauttaa alkuperäiset tavut.

Koodaus ei ole salausta

Base64 on siirtoaakkosto. Se ei peitä mitään, ja kuka tahansa voi purkaa PEM-lohkon komentotulkissa. DER-tiedosto on binäärinen ja yhtä julkinen. Kumpikaan ominaisuus ei ole suoja, eikä kumpikaan vihjaa, että salasana olisi olemassa.

Todellinen suoja on avainmateriaalissa. PKCS12-nippu voi salata sisältönsä salasanasta johdetulla avaimella. PEM-yksityisavain voidaan salata vanhalla otsikkolohkolla tai pitää PKCS#8 EncryptedPrivateKeyInfo:ssa. Varmenne yksin ei pidä mitään salassa, siksi vienti, joka tuotti vain varmenteen, jättää asiakkaan kykenemättömäksi todentamaan, mihin tahansa muotoon sen kääritkin.

Pääte on vihje, ei sopimus. .cer- ja .crt-päätteiset tiedostot esiintyvät molemmissa koodauksissa, ja laitteet vievät DER-varmenteita .pem-nimillä niin usein, että päätteestä arvaaminen maksaa yhden iltapäivän. Lue sen sijaan ensimmäiset tavut: PEM-tiedosto alkaa BEGIN-rivillä, kun taas DER alkaa 0x30:llä, koska ulompi rakenne on SEQUENCE.

Miksi tuonti oikeasti epäonnistuu

Asiakkaan virheilmoitukset puristavat useita eri ongelmia yhteen virheellistä varmennetta koskevaan lauseeseen, joten erottele ne syyn mukaan. Yleisin on koodausepäsuhta: PEM:iä jäsentävä asiakas palauttaa jäsennysvirheen DER-tiedostolle, ja korjaus on muunnos, ei uusi varmenne. Toinen on puuttuva avain, jolloin varmenne on kunnossa eikä identiteettiä voi todistaa. Kolmas on ketju, jolloin ilman välivarmennetta oleva nippu näyttää tuontidialogissa oikealta ja epäonnistuu kättelyssä.

Salausparametrit aiheuttavat neljännen, ja se näyttää täsmälleen väärältä salasanalta. Vanhemmat laitteet veivät PKCS12-tiedostoja RC2-40:llä ja 3DES:llä, jotka OpenSSL 3 hylkää, ellei legacy-tarjoajaa ole ladattu. Uudelleenvienti laitteesta AES-256-CBC:llä ja PBKDF2:lla on pysyvä korjaus. Vanhojen salakirjoitusten jättäminen pysyvästi käyttöön asiakaskoneelle yhden tiedoston takia on huono kauppa.

Viides on monitulkintaisuus. Säiliö, jossa on kaksi avainta ja kaksi varmennetta, tai PEM-tiedosto, jossa on kolme CERTIFICATE-lohkoa, pakottaa asiakkaan valitsemaan, ja sen valinta on usein yksinkertaisesti ensimmäinen kohde. Kun tunneli nousee väärällä identiteetillä, syy on yleensä tämä.

Tarkasta ennen muuntamista

Lue rakenne tulostamatta salaisuuksia. openssl pkcs12 -in bundle.p12 -info -noout ilmoittaa salausalgoritmit ja aliakset vaimentaen avaimen ja varmenteen tulostuksen, ja openssl-pkcs12-käsikirja dokumentoi valitsimet. -noout-valitsimen poisto ja -nodes-valitsimen lisäys on tarkoitettu tiedostoihin, jotka aiot säilyttää, ei nopeaan vilkaisuun, koska se kirjoittaa yksityisavaimen selkokielisenä.

Varmenteelle openssl x509 -in cert.pem -noout -subject -issuer -dates vastaa siihen, mihin tuontidialogi ei vastaa, ja -ext subjectAltName lisättynä näyttää nimet, joille varmenne todella kelpaa. Jos tiedosto on DER, lisää -inform DER; tuo yksi valitsin ratkaisee useimmat unable-to-load-virheet.

Avaimen sovittaminen varmenteeseen on mekaanista, ja se kannattaa tehdä ennen jokaista tuontia:

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

Samat tiivisteet tarkoittavat, että pari kuuluu yhteen. Erilaiset tiivisteet tarkoittavat, että avain on väärä, eikä mikään muunnos muuta sitä.

Mitä muoto ei koskaan muuta

Luottamuspäätökset tehdään säiliön yläpuolella. Asiakas kulkee ketjun varastossaan olevaan juureen, tarkistaa voimassaoloikkunan, tarkistaa laajennetun avainkäytön asiakastodennukseen ja palvelimen puolella tarkistaa, että soitettu nimi esiintyy varmenteessa. Mikään näistä vaiheista ei lue tiedostopäätettä.

Siksi tiedoston uudelleennimeäminen, kunnes virhe katoaa, on niin luotettava tapa hukata aikaa. Tuonti onnistuu, identiteetti on edelleen väärä, ja vika palaa kättelyn aikana, jossa viesti on vähemmän hyödyllinen. Siksi myös kaksi vuotta sitten viety nippu tuodaan puhtaasti ja hylätään silti: vanhenemispäivä matkusti varmenteen sisällä, ei tiedostonimessä.

Järjestys, joka välttää uudelleentyön

Kysy asiakkaan dokumentaatiosta, mitkä koodaukset se hyväksyy ja mitä säiliötä se odottaa asiakasidentiteetille, ja katso sitten, mitä sinulle annettiin. Jos asiakas haluaa yhden tuotavan identiteetin ja sinulla on irrallisia PEM-tiedostoja, rakenna nippu kerran salasanalla, jota hallitset, ja säilytä lähteet. Jos se haluaa PEM:iä, pura avain ja ketju ja poista sitten välitiedostot sillä valtuuksien käsittelyprosessilla, jota tiimisi jo käyttää.

Tarkista tuonnin jälkeen identiteetti, ei dialogia: subjekti, myöntäjä, vanheneminen ja nimi, jonka asiakas esittää. Ystävällinen nimi luettelossa on tarra, ei vahvistettu identiteetti. Jos tunneli sitten epäonnistuu, korjaat todennusta tai reititystä pakkauksen sijaan, mikä on paljon lyhyempi keskustelu.