PEM-formaat: hoe digitale sleutels en certificaten leesbaar en uitwisselbaar worden gemaakt
Elke keer dat je een website bezoekt met dat kleine slotje in de adresbalk, is er ergens een digitaal certificaat gebruikt om te bewijzen dat de site echt is wie hij zegt te zijn. Dat certificaat, en de geheime sleutels die erbij horen, moeten ergens worden opgeslagen en tussen computers worden uitgewisseld. PEM is het meest gebruikte bestandsformaat waarin dat gebeurt: een simpele manier om cryptografische gegevens — die van zichzelf uit onleesbare reeksen bytes zijn — om te zetten in platte tekst die je kunt openen in Kladblok, kunt kopiëren en plakken, of via e-mail kunt versturen zonder dat er iets stukgaat.
Een handige analogie: stel je een kluis voor met een kostbaar document erin (de eigenlijke cryptografische data). Dat document zelf is niet geschikt om zomaar door de post te sturen. PEM is als het overtypen van de inhoud van die kluis in een strak gestructureerde brief, met een duidelijke kop ("BEGIN CERTIFICATE") en een duidelijk einde ("END CERTIFICATE"), zodat iedere ontvanger — of dat nu een webserver, een browser of een systeembeheerder is — precies weet wat hij in handen heeft en de inhoud feilloos kan overnemen. Die bestanden zie je vaak met extensies als .pem, .crt, .cer of .key.
Wat is het precies?
Om PEM te begrijpen, helpt het om de stappen erachter te volgen. Onder de motorkap worden certificaten en sleutels meestal vastgelegd volgens een technische structuur die ASN.1 heet, gecodeerd als binaire data in het zogeheten DER-formaat (Distinguished Encoding Rules). Dat is compact en efficiënt voor computers, maar bestaat uit ruwe bytes die niet altijd heelhuids door tekstgebaseerde systemen komen — oude e-mailservers en tekstverwerkers gingen vroeger nogal eens knoeien met binaire inhoud.
PEM lost dat op door die binaire DER-data eerst om te zetten met Base64-codering: een techniek die elke groep bytes vertaalt naar een beperkte set van 64 gewone tekens (letters, cijfers en een paar tekens als + en /). Het resultaat is een blok tekst dat volledig uit leesbare ASCII-tekens bestaat en dus door vrijwel elk systeem ongeschonden kan worden doorgegeven.
Rond dat Base64-blok plaatst PEM een kop- en een voetregel die aangeven om welk type gegevens het gaat, bijvoorbeeld -----BEGIN CERTIFICATE----- en -----END CERTIFICATE----- voor een certificaat, of -----BEGIN PRIVATE KEY----- voor een geheime sleutel. Er bestaan varianten voor certificaataanvragen (CERTIFICATE REQUEST), publieke sleutels en oudere, specifiekere sleuteltypes. Eén PEM-bestand kan ook meerdere van deze blokken achter elkaar bevatten — dat gebeurt bijvoorbeeld bij een certificaatketen, waarin het certificaat van een website samen met de certificaten van de tussenliggende en de hoofduitgever in één bestand staan.
Belangrijk: een private sleutel in PEM-formaat kan optioneel versleuteld zijn met een wachtwoord, zodat iemand die het bestand in handen krijgt er niet meteen iets mee kan. Zonder die versleuteling ligt de sleutel echter in principe voor het oprapen voor wie toegang heeft tot het bestand — een van de bekendste beveiligingsfouten is dan ook het per ongeluk online zetten van een onversleutelde PEM-sleutel.
Wat wil men ermee bereiken?
Het achterliggende doel van PEM is interoperabiliteit: één simpele, universeel ondersteunde manier om cryptografisch materiaal op te slaan en te delen, ongeacht welke software, welk besturingssysteem of welke overdrachtsmethode wordt gebruikt. Zonder zo'n gedeelde afspraak zou elke fabrikant zijn eigen formaat kunnen verzinnen, met eindeloze compatibiliteitsproblemen tot gevolg.
Omdat het formaat platte tekst is, kan het probleemloos in configuratiebestanden worden geplakt, worden bijgehouden in versiebeheersystemen zoals Git, worden doorgestuurd via kopiëren-en-plakken in een terminal, of worden opgenomen in documentatie — allemaal zonder risico dat binaire tekens onderweg verminkt raken.
Die betrouwbare uitwisselbaarheid is de basis onder een groot deel van de vertrouwensinfrastructuur van het internet. Certificaatuitgevers (Certificate Authorities) leveren hun certificaten in PEM aan, webservers lezen ze in dat formaat in, en beheerders van SSH-toegang (een protocol voor veilige toegang tot servers op afstand) gebruiken een vergelijkbare aanpak voor sleutels. Kortom: het bestaat omdat veilige communicatie op internet staat of valt met een simpele, foutbestendige manier om sleutels en certificaten te verplaatsen.
Voorbeelden uit de praktijk
De geschiedenis van PEM begint niet bij beveiligde websites, maar bij e-mail. In 1993 publiceerde de IETF (de internetstandaardisatieorganisatie) de documenten RFC 1421 tot en met 1424, die "Privacy Enhanced Mail" beschreven: een poging om e-mail standaard te versleutelen en ondertekenen. Dat specifieke e-mailsysteem sloeg nooit breed aan, maar het bestandsformaat dat erin werd gedefinieerd, overleefde en kreeg een tweede leven.
Die tweede leven begon met het cryptografieproject SSLeay (1995) en de opvolger daarvan, OpenSSL (1998), dat uitgroeide tot de meest gebruikte softwarebibliotheek voor SSL/TLS-beveiliging. OpenSSL nam het PEM-formaat over als standaardmanier om sleutels en certificaten op te slaan, en via de enorme verspreiding van die bibliotheek werd PEM de facto de norm in webservers, mailservers en talloze andere toepassingen.
Een recenter voorbeeld is Let's Encrypt, een gratis certificaatdienst die in 2016 werd gelanceerd door de non-profitorganisatie Internet Security Research Group (ISRG). Met het bijbehorende programma Certbot krijgen websitebeheerders automatisch bestanden als fullchain.pem en privkey.pem aangeleverd, waarmee hun site voortaan via HTTPS bereikbaar is.
Ook in moderne cloud- en containertechniek duikt PEM overal op. Het open source project cert-manager, sinds de oprichting in 2016/2017 ondergebracht bij de Cloud Native Computing Foundation, automatiseert het aanvragen en vernieuwen van PEM-certificaten voor toepassingen die draaien op Kubernetes, een populair systeem voor het beheren van softwarecontainers.
Tot slot: wie ooit met de opensourcesoftware OpenSSH heeft ingelogd op een server op afstand, heeft vrijwel zeker een sleutelbestand aangemaakt dat in essentie hetzelfde PEM-formaat gebruikt — al hanteert OpenSSH voor de nieuwere Ed25519-sleutels een eigen variant met vergelijkbare BEGIN/END-markeringen.
Hoe ver is de techniek?
PEM zelf is, na ruim drie decennia, een volwassen en grotendeels "af" formaat. Er is weinig reden om aan de basisstructuur te sleutelen: het werkt, het is overal ondersteund, en radicale wijzigingen zouden vooral compatibiliteitsproblemen opleveren. In die zin is dit geen technologie die zich nog snel ontwikkelt — de ontwikkelingen zitten vooral in wat er omheen gebeurt.
Opvallend is dat het oorspronkelijke doel van PEM, versleutelde e-mail, feitelijk is mislukt en is ingehaald door andere standaarden zoals S/MIME en PGP. Het transportformaat overleefde zijn eigen toepassing.
De belangrijkste actuele trend is automatisering. Het ACME-protocol (vastgelegd in RFC 8555 uit 2019, ontwikkeld voor Let's Encrypt) maakt het mogelijk dat servers zelf, zonder mensenhanden, certificaten in PEM-formaat aanvragen en vernieuwen. Dat vermindert het aantal fouten dat ontstaat doordat mensen handmatig met sleutelbestanden knoeien.
Daarnaast wordt de geldigheidsduur van certificaten steeds korter gemaakt op aandringen van browserbouwers, van meerdere jaren naar momenteel maximaal 398 dagen, met voorstellen binnen het CA/Browser Forum om dit de komende jaren verder te verkorten. Dat verhoogt de druk om PEM-bestanden vaker en dus liefst automatisch te vervangen.
Een andere ontwikkeling op de langere termijn is de opkomst van post-quantumcryptografie: nieuwe wiskundige technieken die bestand moeten zijn tegen toekomstige quantumcomputers. Het Amerikaanse standaardisatie-instituut NIST rondde in 2024 de eerste post-quantumalgoritmen af. Het PEM-formaat zelf hoeft daarvoor niet te veranderen — het is in principe onafhankelijk van het gebruikte algoritme — maar de sleutels en certificaten die erin passen, worden wel aanzienlijk groter.
Het grootste obstakel blijft echter menselijk: verkeerd ingestelde bestandsrechten, per ongeluk gepubliceerde private sleutels in openbare codeopslagplaatsen, en verwarring tussen PEM en verwante formaten zoals het binaire DER of het containerformaat PKCS#12 (met extensie .p12 of .pfx) zorgen nog geregeld voor beveiligingsincidenten.
Wie werken eraan?
De IETF, en specifiek de werkgroep die zich bezighoudt met internetstandaarden voor publieke-sleutelinfrastructuur (PKIX, voortgekomen uit de oorspronkelijke PEM-werkgroep), onderhoudt de formele documenten waarop het formaat en de omliggende standaarden zijn gebaseerd.
Het OpenSSL-project, tegenwoordig ondersteund door de OpenSSL Software Foundation, levert de referentie-implementatie die door talloze andere programma's wordt hergebruikt. Daarnaast speelt de Internet Security Research Group (ISRG), de organisatie achter Let's Encrypt, een grote rol in het toegankelijk maken van certificaten voor iedereen; zij wordt gesteund door onder meer Mozilla, de Electronic Frontier Foundation en verschillende techbedrijven.
Beleid rond certificaatlevensduur en uitgiftepraktijken wordt bepaald in het CA/Browser Forum, een samenwerkingsverband van certificaatuitgevers en browserbouwers als Google, Apple, Microsoft en Mozilla. Commerciële certificaatuitgevers zoals DigiCert, Sectigo en GlobalSign, en clouddiensten als AWS Certificate Manager, Google Cloud en Azure Key Vault, verwerken dagelijks enorme aantallen PEM-bestanden in hun infrastructuur.
Op softwarematig vlak dragen ook het OpenBSD-project (ontwikkelaar van OpenSSH) en de Cloud Native Computing Foundation (met onder meer cert-manager) actief bij aan de praktische toepassing van het formaat. Voor de langetermijntoekomst van de onderliggende cryptografie speelt het Amerikaanse NIST een leidende rol met zijn post-quantumstandaarden.