Wat is een X.509-certificaat?

X.1988 werd voor het eerst geïntroduceerd in 500 naast de X.509-standaarden voor elektronische adreslijstdiensten en is aangepast voor internetgebruik door de Public-Key Infrastructure van de IETF (X.509) (PKIX) werkgroep. RFC 5280 profileert het X.509 v3-certificaat, de X.509 v2-certificaatintrekkingslijst (CRL) en beschrijft een algoritme voor X.509-certificaatpadvalidatie.

Veel voorkomende toepassingen van X.509-certificaten zijn onder meer:

SSL /TLS en HTTPS voor geverifieerd en versleuteld surfen op het web
Ondertekende en versleutelde e-mail via de S/MIME protocol
Code ondertekening
Document ondertekening
Client authenticatie
Door de overheid uitgegeven elektronisch identiteitsbewijs

Certificaat nodig? SSL.com heeft u gedekt. Vergelijk hier de opties om de juiste keuze voor u te vinden, vanaf S/MIME en codeondertekeningscertificaten en meer.

BESTEL NU

Sleutelparen en handtekeningen

Ongeacht de beoogde toepassing (en), elk X.509-certificaat bevat een publieke sleutel, digitale handtekeningen informatie over zowel de identiteit die aan het certificaat is gekoppeld als de afgifte ervan certificeringsinstantie (CA):

De publieke sleutel maakt deel uit van een sleutelpaar dat omvat ook een privé sleutel. De privésleutel wordt veilig bewaard en de openbare sleutel is opgenomen in het certificaat. Dit openbare / privé-sleutelpaar:
- Staat de eigenaar van de privésleutel toe om documenten digitaal te ondertekenen; deze handtekeningen kunnen worden geverifieerd door iedereen met de bijbehorende openbare sleutel.
- Hiermee kunnen derden berichten verzenden die zijn versleuteld met de openbare sleutel en die alleen de eigenaar van de persoonlijke sleutel kan ontsleutelen.
A digitale handtekening is een gecodeerde hash (digest met vaste lengte) van een document dat is gecodeerd met een privésleutel. Wanneer een X.509-certificaat is ondertekend door een publiekelijk vertrouwde CA, zoals SSL.com, kan het certificaat door een derde partij worden gebruikt om de identiteit van de entiteit die het presenteert te verifiëren.
Opmerking: Niet alle toepassingen van X.509-certificaten vereisen openbaar vertrouwen. Een bedrijf kan bijvoorbeeld zijn eigen vertrouwde privécertificaten uitgeven voor intern gebruik. Lees ons artikel over voor meer informatie Privé versus openbaar PKI.
Elk X.509-certificaat bevat velden die de onderwerpen, afgevende CA, en andere vereiste informatie zoals het certificaat versie en geldigheidsduur. Bovendien bevatten v3-certificaten een set van extensies die eigenschappen definiëren zoals acceptabel sleutelgebruik en aanvullende identiteiten om een sleutelpaar aan te binden.

Ga naar boven

Certificaatvelden en extensies

Om de inhoud van een typisch X.509-certificaat in het wild te bekijken, zullen we de SSL /TLS certificaat, zoals weergegeven in Google Chrome. (U kunt dit allemaal in uw eigen browser controleren op elke HTTPS-website door op het slot aan de linkerkant van de adresbalk te klikken.)

De eerste groep details bevat informatie over de Onderwerp, inclusief de naam en het adres van het bedrijf en de Gemeenschappelijke naam (of volledig gekwalificeerde domeinnaam) van de website die het certificaat moet beschermen. (Opmerking: de Serienummer weergegeven in dit onderwerpveld is een bedrijfsidentificatienummer van Nevada, niet het serienummer van het certificaat zelf.)
Als we naar beneden scrollen, komen we informatie tegen over de Emittent. Niet toevallig, in dit geval de Organisatie is "SSL Corp" voor zowel de subject als de uitgever, maar de uitgever Gemeenschappelijke naam is de naam van het uitgevende CA-certificaat in plaats van een URL.
Onder de Issuer zien we de certificaten Serienummer (een positief geheel getal dat het certificaat uniek identificeert), X.509-versie (3), de Handtekeningalgoritme, en datums die de certificaten specificeren Geldigheidsperiode.
Vervolgens komen we aan bij de public Key, Signatuuren bijbehorende informatie.
Naast de bovenstaande velden bevatten X.509 v3-certificaten een groep uitbreidingen die extra flexibiliteit bieden bij het gebruik van certificaten. Bijvoorbeeld de Onderwerp Alternatieve Naam extensie maakt het mogelijk dat het certificaat aan meerdere identiteiten wordt gebonden. (Om deze reden worden certificaten met meerdere domeinen soms aangeduid als SAN-certificaten). In het onderstaande voorbeeld kunnen we zien dat het certificaat eigenlijk elf verschillende SSL.com-subdomeinen omvat:
De vingerafdrukken die hieronder worden weergegeven, maken de certificaatinformatie in Chrome geen deel uit van het certificaat zelf, maar zijn onafhankelijk berekende hashes die kunnen worden gebruikt om een certificaat uniek te identificeren.

Ga naar boven

Certificaatketens

Om zowel administratieve als veiligheidsgerelateerde redenen worden X.509-certificaten doorgaans gecombineerd in ketens voor validatie. Zoals te zien is in de schermafbeelding van Google Chrome hieronder, is de SSL /TLS certificaat voor www.ssl.com is ondertekend door een van de tussenliggende certificaten van SSL.com, SSL.com EV SSL Intermediate CA RSA R3. Het tussenliggende certificaat wordt op zijn beurt ondertekend door de EV RSA-root van SSL.com:

Voor openbaar vertrouwde websites zal de webserver zijn eigen server leveren eindentiteit certificaat, plus eventuele tussenproducten die nodig zijn voor validatie. Het root-CA-certificaat met zijn openbare sleutel wordt opgenomen in het besturingssysteem van de eindgebruiker en / of de browsertoepassing, wat resulteert in een volledige keten van vertrouwen.

Ga naar boven

herroeping

X.509-certificaten die ongeldig moeten worden gemaakt vóór hun Niet geldig na datum kan zijn herroepen. Zoals hierboven vermeld, RFC 5280 profielen certificaatintrekkingslijsten (CRL's), lijsten met tijdstempels van ingetrokken certificaten die kunnen worden opgevraagd door browsers en andere clientsoftware.

Op internet zijn CRL's in de praktijk niet effectief gebleken en zijn ze vervangen door andere oplossingen voor intrekkingscontrole, waaronder het OCSP-protocol (gepubliceerd in RFC 2560), OCSP Stapling (gepubliceerd in RFC 6066, sectie 8, als "Certificaatstatusaanvraag"), en een assortiment van leverancier-specifieke oplossingen geïmplementeerd in verschillende webbrowsers. Lees onze artikelen voor meer informatie over de netelige geschiedenis van intrekkingscontrole en hoe huidige boegers de intrekkingsstatus van certificaten controleren, Optimalisatie van pagina laden: OCSP-nieten en Hoe gaan browsers om met ingetrokken SSL /TLS Certificaten?