Hoe het werkt
Een X.509-certificaat is een ondertekend document dat een openbare sleutel koppelt aan een naam: een domein, een persoon of een organisatie. Tussen servers en in bestanden wordt de binaire vorm (DER) gebruikt; wat je kopieert en plakt is dezelfde structuur in Base64 tussen de regels BEGIN CERTIFICATE en END CERTIFICATE, het PEM-formaat. Het bevat een onderwerp, een uitgever, een geldigheidsperiode, de openbare sleutel en extensies die aangeven waarvoor het dient en waar je kunt nagaan of het is ingetrokken.
De tool herkent certificaten, PKCS#10-ondertekeningsverzoeken (CSR), privésleutels in PKCS#8, PKCS#1 en SEC1, openbare sleutels, PKCS#7-bundels (.p7b) en PKCS#12-bestanden (.pfx, .p12). Plak je meerdere blokken tegelijk, dan ordent de tool de keten van eindcertificaat tot root, verifieert elke handtekening met de sleutel van de uitgever en vergelijkt de privésleutel met elk certificaat en elke CSR om je te vertellen wat bij wat hoort.
De tool converteert ook tussen formaten, maakt van het certificaat en de sleutel de .pfx die IIS en Azure vereisen, en genereert een nieuwe CSR met bijbehorende privésleutel of een zelfondertekend certificaat voor tests. Alles gebeurt met de cryptografische API van je browser: certificaten noch sleutels worden naar een server verstuurd.
Voorbeelden
ISRG Root X1 · SHA-25696:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6De SHA-256-vingerafdruk van de root van Let's Encrypt. Dat is de waarde die de certificeringsinstantie en de vertrouwensarchieven publiceren: komt die van jouw bestand overeen, dan is het precies dat certificaat.ISRG Root X1 · pin SPKIC5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=De SHA-256 van de openbare sleutel in Base64. Dat is de waarde voor pin-sha256 in de netwerkbeveiligingsconfiguratie van Android of voor certificate pinning in een app, en die verandert niet bij het vernieuwen van het certificaat als de sleutel wordt hergebruikt.root.crt + intermediate.crt + server.crtserver.crt + intermediate.crt + root.crtnginx en HAProxy beschouwen het eerste certificaat in het bestand als dat van de server. Staat de keten omgekeerd, dan faalt nginx met key values mismatch omdat het de privésleutel met het rootcertificaat vergelijkt.openssl pkcs12 -in viejo.pfx -legacy -nodes | openssl pkcs12 -export -out nuevo.pfxPBES2 · AES-256-CBC · MAC SHA-256.pfx-bestanden die door oudere Windows-versies of OpenSSL 1.x zijn geëxporteerd, zijn versleuteld met RC2 en 3DES, die browsers niet implementeren. Deze opdracht versleutelt ze opnieuw met AES, het standaardformaat van OpenSSL 3.Gebruiksscenario's
- Vóór de installatie controleren of het certificaat van de certificeringsinstantie alle domeinen (SAN) dekt en of de vervaldatum klopt.
- Uitzoeken welke van de privésleutels die op de server zijn achtergebleven bij welk certificaat hoort, zonder moduli met OpenSSL te hoeven vergelijken.
- Achterhalen waarom een client je site niet vertrouwt: een ontbrekend tussenliggend certificaat, een keten in de verkeerde volgorde of een certificaat ondertekend met SHA-1.
- De CSR genereren om een certificaat te kopen of te vernieuwen, met de sleutel aangemaakt op je eigen computer en de gelijkwaardige OpenSSL-opdracht voor als je het liever op de server doet.
- Een .crt en de bijbehorende .key omzetten naar een .pfx voor IIS, Azure App Service of een Java-keystore, of het certificaat en de sleutel uit een .pfx halen voor nginx.
- De vingerafdruk of SPKI-pin van een certificaat opvragen om certificate pinning in een mobiele app te configureren of een clientcertificaat te valideren.
Veelgestelde vragen
Is het veilig om mijn privésleutel hier te plakken?
De sleutel wordt met de Web Crypto API in je browser verwerkt en naar geen enkele server verstuurd; je kunt dat controleren op het tabblad Netwerk van de ontwikkelaarstools. Toch is het goede praktijk om elke productiesleutel als geheim te behandelen: plak hem alleen in tools die je vertrouwt en sluit het tabblad als je klaar bent.
Wat is het verschil tussen PEM, DER, CRT, CER, P7B en PFX?
DER is het certificaat in binaire vorm en PEM is diezelfde binaire inhoud in Base64 tussen BEGIN- en END-regels. De extensies .crt en .cer zeggen niets over het formaat: ze kunnen beide bevatten. Een .p7b is een PKCS#7-bundel met meerdere certificaten en geen sleutel. Een .pfx of .p12 is een PKCS#12: die bevat het certificaat, de tussenliggende certificaten en de privésleutel samen, versleuteld met een wachtwoord.
Hoe weet ik of mijn server het tussenliggende certificaat mist?
Plak wat je op de server hebt geconfigureerd. Eindigt de keten met een certificaat dat niet zelfondertekend is, dan ontbreekt er een schakel: de extensie Authority Information Access van dat certificaat bevat onder CA Issuers meestal het adres om de uitgever te downloaden. Desktopbrowsers zoeken die soms zelf op, maar Android, curl en de meeste bibliotheken niet, dus de fout treedt maar bij sommige clients op.
Hoe lang mag een openbaar TLS-certificaat geldig zijn?
Sinds september 2020 weigeren browsers certificaten die langer dan 398 dagen geldig zijn. Het CA/Browser Forum heeft in 2025 besloten het maximum stapsgewijs te verlagen: 200 dagen voor certificaten uitgegeven vanaf 15 maart 2026, 100 dagen vanaf maart 2027 en 47 dagen vanaf maart 2029. Daarom is het verstandig de vernieuwing met ACME te automatiseren. Interne CA's van een bedrijf hebben die limiet niet.
RSA of ECDSA voor de CSR?
ECDSA P-256 biedt beveiliging die vergelijkbaar is met RSA van 3072 bits, met veel kleinere sleutels en handtekeningen, en de server voert de handshake sneller uit. Alle huidige browsers en systemen ondersteunen het. RSA 2048 blijft de veilige keuze als je zeer oude clients, embedded apparaten of een systeem hebt dat alleen RSA accepteert.
Is het genoeg om het domein in de algemene naam (CN) te zetten?
Nee. Sinds Chrome 58, in 2017, kijken browsers alleen naar de alternatieve namen (SAN) en wordt de CN genegeerd. Elk domein waarvoor het certificaat wordt gebruikt, ook dat van de CN, moet in de SAN-lijst staan. Een wildcard als *.example.com dekt maar één niveau: hij geldt voor www.example.com, maar niet voor example.com of a.b.example.com.