Hoe werken digitale certificaten?

Tijdens digitale communicatie tussen 2 computers of op het internet wordt je vaak geconfronteerd met digitale certificaten. Deze digitale certificaten zorgen ervoor dat u een veilige verbinding op kunt zetten met een geautoriseerde partner (server). Maar hoe werken deze digitale certificaten? Ik doe mijn best het complete plaatje zo beknopt mogelijk uit te leggen. Are you with me?

Allereerst even een aantal basisbegrippen uitleggen alvorens we ingaan op de werking van digitale certificaten.

Public Key Infrastructure (PKI)

Een Public Key Infrastructure is een netwerk van systemen waarmee de uitgifte van een digitaal certificaat geregeld kan worden. De certificate authority beheerd dus geheel of gedeeltelijk zijn eigen PKI. Het uitgeven van een certificaat is een delicate aangelegenheid. Om de absolute veiligheid van een certificaat te waarborgen moet de PKI extreem goed beveiligd zijn. Denk aan logische en fysieke beveiliging. Om deze reden zijn ook bepaalde taken die behoren tot het uitgeven en administreren van digitale certificaten onderverdeeld een aantal functies. Dit zijn:

• RA – Registration Authority – Controleert de gebruikersaanvragen voor een certificaat en stelt vast dat de identiteit van de aanvrager klop. Bij akkoord geeft de RA aan de CA door dat het certificaat uitgegeven mag worden
• CPS – Certificate Practise Statement – De algemene voorwaarden van de PKI
• DS – Directory Service – De digitale certificaten worden gekoppeld aan entiteiten welke binnen een Directory Service beheerd worden (b.v. Active Directory)
• CA – Certificate Authority – Geeft digitale certificaten uit en beheerd deze
• VA – Validation Authority – Valideert het certificaat bij gebruik
• CRL – Certificate Revocation List – Dit is een lijst met ingetrokken of vervallen digitale certificaten. Voor X.509 digitale certificaten wordt meestal gebruik gemaakt van OCSP (Online Certificate Status Protocol) i.p.v. CRL.

Certificate Authority – CA

De “certificate authority” (of afgekort de CA) is de instantie die de digitale certificaten verstrekt. Er zijn veel certificate authorities maar de meest bekende zijn toch wel Symantec, Comodo, GoDaddy, Globalsign en Digicert. De certificate authority is verantwoordelijk voor de uitgifte van de digitale certificaten en dus voor het verificatieproces van de aanvrager. De CA waarborgt dus zowel de integriteit als de authenticiteit van het certificaat en staat dus in voor de identiteit van de certificaathouder. Veel grote certificate authorities zijn commercieel en rekenen dus centjes voor het uitgeven van een certificaat. Andere instanties zoals CAcert doen dit gratis.

Digitaal certificaat

Het digitale certificaat verifieerd de eigendom van de gebruikte publieke sleutel (later meer over deze publieke sleutel). De houder van het digitale certificaat is dus geverifieerd op de specifieke publieke sleutel te gebruiken. Een certificaat bevat de volgende zaken:

• Geregistreerde naam van de certificaathouder
• Publieke sleutel voor de certificaathouder
• Geldigheidsperiode certificaat
• Identiteit van de certificate authority
• Locatie van de CRL (Certificate Revocation List)
• Digitale handtekening om bovenstaande gegevens te waarborgen. Dit is een samenvatting van bovenstaande welke gehashed is en versleuteld met een geheime sleutel van de certificate authority.

Self-Signed digitale certificaten

Je kunt ook zelf je eigen PKI installeren en je eigen digitale certificaten uitgeven. Dit type digitale certificaten noemen we “self signed certificates”. Dit type certificaat wordt ondertekend met zijn eigen private key. Een self-signed certificaat is snel en goedkoop om uit te rollen. De grote / bekende certificate authorities worden standaard door je computer en browsers herkend. Om deze reden zien we zonder verdere vragen automatisch een slotje of groene balk op verschillende websites. De computer vertrouwd het certificaat van de bekende CA en vertrouwt daarmee de integriteit van de persoon of het bedrijf die het certificaat gebruikt. Als je een self signed certificaat uitrolt dan herkennen andere computers het certificaat niet automatisch en krijgen ze de melding dat het certificaat onveilig is en mogelijk voor malafide doeleinden wordt gebruikt.

Certificate Signing Request – CSR

Om een certificaat aan te vragen heb je een Certificate Signing Request (CSR) nodig. Een CSR is een stukje gecodeerde informatie met daarin informatie over je te beschermen resource (domeinnaam) en organisatie alsmede je publieke sleutel. De CSR is ook het begin (1e onderdeel) van je uiteindelijke certificaat. De Certificate Signing Request vraag je dan ook aan op de server waar je het uiteindelijke certificaat gaat gebruiken of op een andere server. Belangrijk is dat het CSR aangemaakt wordt met de privésleutel die je gaat gebruiken en dat deze privésleutel geheim blijft. Hoe je een CSR aanmaakt is erg afhankelijk van het type server waar je de CSR op aanmaakt. Het meest voorkomende formaat voor een CSR is een PKCS # 10 (Public Key Cryptography Standards # 10) bestand en een Spkac (Signed Public Key and Challenge) bestand. In de CSR zijn vrijwel altijd de volgende zaken vermeld?

• Volledige domeinnaam (ofwel de CN – Common Name), bijvoorbeeld www.mijndomeinnaam.nl. In het geval van een organisatie certificaat (waarbij het certificaat ook geldig is voor de sub domeinen) gebruik je een * i.p.v. www. Dus bijvoorbeeld *.mijndomeinnaam.nl
• Volledige bedrijfsnaam (incl. toevoegingen als BV / VOF etc.), bijvoorbeeld Mijn Domeinnaam B.V.
• Afdelingsnaam, bijvoorbeeld IT
• Land waar het bedrijf gevestigd is, bijvoorbeeld Nederland
• Provincie waar het bedrijf gevestigd is, bijvoorbeeld Noord Brabant
• Plaats waar het bedrijf gevestigd is, bijvoorbeeld Tilburg
• E-mailadres van de contactpersoon
• Publieke sleutel
• Bitlengte

Hoe sterker de sleutellengte (ofwel bitlengte of keysize) van een CSR des te veiliger het uiteindelijke certificaat. Een sleutellengte van 2048 bits is tegenwoordig minimaal verplicht. Aan te raden is om een sleutellengte van 4096 bits te gebruiken.

Alvorens de CSR aangemaakt kan worden maakt de aanvrager een keypair (sleutelpaar) aan. Dit is een automatisch proces welke meestal meteen uitgevoerd wordt tijdens de CSR aanvraag. Dit sleutelpaar bevat 2 sleutels. 1 publieke sleutel (public key) en 1 privé sleutel (private key). De CSR wordt uiteindelijk ondertekend met de publieke sleutel. Als dat alles compleet is wordt de CSR opgestuurd naar de Certificate Authority.

Certificate Revocation List – CRL

Tijdens het controleproces raadpleegt de CA altijd de Certificate Revocation List. Op deze CRL staan de serienummers van de digitale certificaten die ingetrokken zijn en waarvan de gebruiker dus niet meer vertrouwd mag worden. De CRL wordt periodiek geüpdate en vaak direct nadat een ingetrokken certificaat wordt toegevoegd. Digitale certificaten op deze lijst kunnen de status “revoked” hebben waarna ze definitief ongeldig zijn. Digitale certificaten kunnen ook de status “hold” hebben. Als digitale certificaten deze status hebben kunnen deze nog teruggedraaid worden zodat ze alsnog geldig zijn.

Encryptie

Encryptie is het versleutelen van data. Versleutelde data kan alleen ontsleutelt (decryptie) worden door geautoriseerde partijen die beschikken over de juiste sleutel. Encryptie zorgt er niet voor dat data niet onderschept kan worden maar zorgt er wel voor dat deze data niet gelezen kan worden. De data wordt versleuteld volgens een bepaald encryptie algoritme. Het algoritme veranderd de data is een onleesbare cijfertekst (ciphertext). Er zijn veel soorten encryptiemethodes voor verschillende doeleinden. In combinatie met digitale certificaten worden meestal TLS (Transport Layer Security) en SSL (Secure Socket Layer) gebruikt. Dit type encryptie noemen we asymmetrische encryptie.

Asymmetrische encryptie:
Bij asymmetrische encryptie wordt gebruik gemaakt van 2 sleutels. 1 sleutel wordt gebruikt om de data te versleutelen (public key) en 1 sleutel wordt gebruikt om data te ontsleutelen (private key). Met de private key ontsleutel je een bericht dat met de publieke sleutel is versleuteld. Met de Private Key zet je jouw handtekening (je versleutelt met de private key de hash die je van het bericht en/of het certificaat hebt gemaakt. De ontvanger (of de computer waar je mee gaat communiceren) kan met jouw publieke sleutel die handtekening lezen. Dat wil zeggen dat deze met jouw publieke sleutel de door de private key versleutelde hash kan ontsleutelen. Om zeker te weten dat de publieke sleutel is van degene die je het bericht wilt sturen of van de computer waar je mee wilt communiceren worden publieke sleutels gecertificeerd door een CA die deze met zijn geheime sleutel ondertekent (dus inpakt). Met deze publieke sleutel van de CA kun je de handtekening op het certificaat lezen (dwz uitpakken met de publieke sleutel van de CA). Alle publieke sleutels van vertrouwde CA’s zijn opgenomen in de certificates stores op je computer. Nadat een pakketje van het certificaat is ontsleuteld met de publieke sleutel van de CA maak je zelf een hash van het certificaat en dat vergelijk je met de hash zoals aangeleverd door de CA. Als de hashes gelijk zijn dan weet je of de computer waarmee je wilt communiceren ook echt is wie hij “zegt te zijn”. De identiteit is gevalideerd. Als we het in dit artikel over encryptie hebben dan hebben we het over asymmetrische encryptie.

Symmetrische encryptie
Symmetrische encryptie is sneller dan asymmetrische encryptie omdat voor het versleutelen en ontsleutelen van de data dezelfde sleutel gebruikt wordt. Deze methode vereist wel dat beide partijen over deze sleutel beschikken.

Hash

Versleutelde (encrypted) data kan met de juiste sleutel weer leesbaar gemaakt worden. Het encryptieproces is dus omkeerbaar. Een hash zet data om in een specifieke waarde welke niet meer om te draaien of terug te rekenen is. Hashing wordt vaak gebruikt bij het opslaan van wachtwoorden in een database. Tijdens opslag wordt het wachtwoord gehashed waardoor er een unieke waarde ontstaat. Als de gebruiker vervolgens inlogt wordt het wachtwoord ook gehashed en verzonden. Vervolgens wordt de hash in de database vergeleken met de hash die gebruikt wordt om te authentiseren. Als de hashes overeenkomen dan is het wachtwoord correct. Een goede hash moet an de volgende eigenschappen voldoen:

• De hash mag niet terug te rekenen zijn (als “a” een “0” wordt en “b” een “1” dan mag “ab” niet “01” vormen)
• Dezelfde waarde moet ook dezelfde hash genereren
• Moet ongeacht de content altijd eenzelfde lengte zijn

Een hash is echter dus niet altijd uniek. Het wachtwoord “123456” is nog steeds een van de meest gebruikte wachtwoorden. De hash “e10adc3949ba59abbe56e057f20f883e” is echter dus ook altijd hetzelfde en bij crackers bekend. Een cracker kan dus buitgemaakte databases doorzoeken naar bekende hashes zoals “e10adc3949ba59abbe56e057f20f883e”. Juist om deze reden wordt er op hashes vaak een salt toegepast. De “salt” methode wordt ervoor dat de uiteindelijke hash voor 2 verschillende gebruikers met hetzelfde wachtwoord toch verschillend is. Dit werkt door een andere constante waarde mee te nemen in de hash.

Normale hash

Hash + Salt

Online maken we vaak gebruik van MD5 hashing en SHA-256 (de opvolger van het zwakkere SHA-1).

Soorten digitale certificaten

Er zijn verschillende typen digitale certificaten. Het grote verschil in deze digitale certificaten zit hem in de controle die er uitgevoerd wordt na het aanvragen van het digitale certificaat en de manier waarop je het certificaat wilt gaan inzetten. Meestal zijn de volgende type digitale certificaten aan e vragen bij een CA.

Basis domein certificaat:
Het basis domein SSL certificaat is meestal het goedkoopste certificaat en is bedoeld voor 1 (hoofd) domeinnaam. Dit certificaat voorziet de browser van een valide https voorvoegsel en een gesloten slotje in de balk. Bij deze digitale certificaten wordt alleen gecontroleerd of de aanvrager gemachtigd is om het certificaat voor de domeinnaam aan te vragen. De aanvraagprocedure duurt ongeveer 1 werkdag.

Organisatie certificaat (ofwel wildcard certificaat):
Het organisatie certificaat is bijna hetzelfde als het “basis domein certificaat”. Het organisatie certificaat zorgt eveneens voor een valide https voorvoegsel en een gesloten slotje. Het enige verschil is dat het organisatie certificaat ook voor subdomeinnamen geldig is. Dus ook backup.mijndomeinnaam.nl en remote.mijndomeinnaam.nl kunnen worden opgenomen in dit certificaat. Een organisatie certificaat is meestal een stuk duurder en ook de validatieprocedure is een stuk uitgebreider. Uiteraard wordt gekeken of de aanvrager gemachtigd is om te handelen voor die domeinnaam en voor het aangegeven bedrijf. De bedrijfsgegevens van het bedrijf worden ook gecontroleerd. Zo zal vaak een kopie van het KvK uittreksel meegestuurd moeten worden. De validatie wordt meestal telefonisch afgerond. Dat wil zeggen dat de aanvrager ook telefonisch akkoord moet geven op de aanvraag. De hele procedure duurt ongeveer 3 tot 6 werkdagen.

EV (Extended Validation) certificaat:
De naam van dit certificaat zegt natuurlijk al een beetje dat dit certificaat een uitgebreid certificaat is. Dit certificaat is het duurste certificaat en geldig voor 1 domein. De aanvraag duurt gemiddeld 5 tot 10 werkdagen. Dit certificaat zorgt niet alleen voor een valide https voorvoegsel en een gesloten slotje maar ook voor de groene adresbalk. Deze groene adresbalk straalt extra veel vertrouwen uit wat natuurlijk ook terecht is gezien de uitgebreide validatie welke het bedrijf doorlopen heeft. Het bedrijf wordt op meerdere punten gecontroleerd. Zo zal ook een uittreksel van het KvK opgestuurd moeten worden. Maar ook de domeinnaam registratie moet volledig correct zijn. De aanvrager van het certificaat (en zijn relatie tot het bedrijf) wordt volledig gecontroleerd. Zo kan het zijn dat er een brief van jurist meegestuurd moet worden om de aanvraag en aanvrager goed te keuren. Ook zal de directie (CEO of COO) gecontacteerd worden voor goedkeuring.

Workflow voor het aanvragen van een certificaat

De workflow voor het aanvragen van een certificaat is als volgt:

1. De aanvrager genereerd een CSR en ondertekend deze met zijn publieke sleutel. De CSR wordt opgestuurd naar de CA (Certificate Authority)

2. De Certificate Authority ontvangt de aanvraag en bekijkt het type certificaat welke aangevraagd wordt

3. Als de CSR akkoord is worden de benodigde validatiestappen doorlopen om de authenticiteit van de aanvrager vast te stellen

4. Bij akkoord ondertekend de CA de CSR van de aanvrager met zijn eigen publieke sleutel en stuurt deze retour met een geldigheidsdatum. Meestal 1 of 2 jaar.

5. De ontvangen CSR wordt toegevoegd aan de originele CSR en vormt het complete certificaat. Op deze manier weet de ontvanger van het certificaat wat de publieke sleutels van de server en de CA zijn. De ontvanger kan zijn data zo versleutelen en naar de server of de CA sturen. De server of CA kunnen deze data alleen decrypten met hun privé sleutels.

Workflow opvragen van data over HTTPS (SSL Handshake)

Als het certificaat geïnstalleerd is dan is heeft de aanvrager van data (de bezoeker) een mogelijkheid om een veilige en versleutelde verbinding op te zetten. Met het aanwezige certificaat waarborgt de webserver zijn authenticiteit en integriteit en weet de bezoeker zeker dat de webserver met het certificaat de juiste server is om de communicatie te starten. De complete workflow is als volgt:

1. De cliënt geeft aan te willen communiceren met de server over SSL of TLS beveiligde verbinding. De cliënt stuurt eveneens mee met welke cipher suites (encryptie mogelijkheden) hij kan communiceren.

2. De server geeft aan over SSL te kunnen communiceren en stuurt zijn certificaat (met publieke sleutel) naar de cliënt alsmede de gekozen cipher settings. De uiteindelijke verbinding zal over de sterkte encryptie beschikken waar beide partijen (cliënt en server) gebruik van kunnen maken.

3. De cliënt controleert de authenticiteit van het certificaat (geldigheid, DN, CA etc.) en bij akkoord gaan de cliënt en server willekeurige getallen uitwisselen. Tussen deze willekeurige getallen zit een speciaal nummer genaamd de “Pre-Master Secret”. De cliënt versleuteld de pre-master secret met de publieke sleutel van de server en verstuurd deze encrypted naar de server.

4. De server decrypt het bericht van de cliënt met zijn privé sleutel. De cliënt en server creëren vervolgens een gezamenlijk geheim (de Master Secret). De master secret wordt door cliënt en server weer gebruikt om de sessiesleutel voor hashing te genereren en om de sessiesleutel voor encryptie te genereren. Deze sessiesleutels zijn alleen bedoeld voor de huidige sessie en zijn symmetrische sleutels. Beide partijen beschikken dus over de sleutel om de data te versleutelen en ontsleutelen.

5. Nu de sessiesleutels opgezet zijn schakelen de cliënt en server beide om naar het veilige kanaal waar ze kunnen starten met het uitwisselen van data aan elkaar welke encrypted zijn met de sessiesleutel.

Workflow opvragen van data over HTTPS – Sesamstraat methode

De Sesamstraat methode gebruik ik om hetzelfde voorbeeld nogmaals uit te leggen maar dan zonder moeilijke termen. Door gebruik te maken van de Sesamstraat methode is het duidelijker wat er op welk punt met de data gebeurt en waarom dit veilig is.

1. De cliënt vraagt data op van de server en wil dit veilig doen. Hij verteld met welke encryptiemethodes hij kan werken.

2. De server kiest de hoogst mogelijke encryptiemethode en stuurt de cliënt zijn certificaat met publieke sleutel

3. De cliënt controleert het certificaat en bij akkoord verzint de pre-master key welke hij versleuteld met de publieke sleutel naar de server stuurt

4. De server kan de pre-master key alleen ontsleutelen met zijn privé sleutel. De pre-master key is nu bekend bij beide partijen. Beide partijen voegen nog data toe en uiteindelijk zijn ze beide in bezit van de master key. Met de master key worden 2 sessiesleutels gemaakt voor hashing en encryptie).

5. Data wordt versleuteld tussen beide partijen verstuurd. Beide partijen beschikken namelijk over de juiste sessiesleutels om data te encrypten en decrypten.

Root CA – Certificate Chain

Een computer (of browser) zal een certificaat proberen te valideren zodat hij een pre-master key aan kan maken. Dit doet hij door te kijken wie de uitgevende CA is. Dit kan er slechts 1 zijn. Dan is dit de root CA (basiscertificeringsinstantie). Maar het kunnen er ook meer zijn. Het kan ook zijn dat de Root CA een volgende CA vertrouwd en die vertrouwd weer de CA die jouw certificaat uitgegeven heeft. Alle tussenliggende certificeringsinstanties noemen we “Intermediate CA’s”.

Bovenstaande noemen we de “certificate chain”. De computer of browser zal eerst kijken of hij de uitgevende CA vertrouwd. Zo niet dan probeert hij de bovenliggende CA. Als hij een CA in de certificate chain vertrouwd zal de verbinding opgezet worden. Als geen enkele CA vertrouwd wordt dan wordt de verbinding verbroken.

Standaard zijn computers en browsers voorzien van een archief met de digitale certificaten van vertrouwde certificeringsinstanties. Je kunt je eigen self-signed digitale certificaten dus vertrouwen door je eigen (CA) certificaat te importeren in het juiste archief (Vertrouwde basiscertificeringsinstanties).

Certificaat Formaten

Mocht je nu aan de slag gaan met certificaten dan zal je merken dat er nogal wat verschillende soorten bestanden zijn. De volgende formaten kom je vaak tegen.

*.pem (Privacy enhanced Electronic Mail)
&
*.cer (Canonical Encoding Rules)
De meeste CA’s leveren hun certificaten in het PEM of CER bestandsformaat. Deze certificaten bevatten de volgende gegevens:

Certificaat: Ja
Incl. Root Certificaten: Nee
Incl. Intermediate Certificaten: Nee
Incl. Private Key: Nee
Incl. Public Key: Ja (van de CA)
Versleuteling: Base64 (elke regel is exact 64 tekens lang)
Webservers: Voornamelijk IIS en APACHE
Herkenbaar aan: “—–BEGIN CERTIFICATE—–” en “—–END CERTIFICATE—–“ tags

*.der (Distinguished Encoding Rules)
Dit bestand wordt vaak door de computer hetzelfde aangeduid als een *.cer bestand. Het bestand heeft eenzelfde functie maar bij een *.der staat de lengte van de code vast terwijl bij een *.cer het eindstuk van de code uitgelezen wordt en de lengte niet vaststaat en hier ook geen limiet aan gesteld wordt. Hierdoor is een *.der meer geschikt voor kortere bestanden en een *.cer voor grotere bestanden.

Certificaat: Ja
Incl. Root Certificaten: Nee
Incl. Intermediate Certificaten: Nee
Incl. Private Key: Nee
Incl. Public Key: Ja (van de CA)
Versleuteling: Base64
Webservers: Voornamelijk IIS en APACHE
Herkenbaar aan: “—–BEGIN CERTIFICATE—–” en “—–END CERTIFICATE—–“ tags

*.pfx OF *.p12 (Personal Information Exchange Format)
Deze bestanden bevatten een volledige certificate chain incl. de private en public keys. Meestal worden deze bestanden gegenereerd als een backup bestand op een server waardoor deze later weer volledig en in een handeling te importeren is. Omdat deze files alle informatie bevatten moeten ze voorzien worden van een wachtwoord.

Certificaat: Ja
Incl. Root Certificaten: Ja
Incl. Intermediate Certificaten: Ja
Incl. Private Key: Ja
Incl. Public Key: Ja (van de CA)
Webservers: Geen. Deze extensie is voor certificaat backups.

*.p7b OF *.p7c (Cryptographic Message Syntax Standard)
Dit soort bestanden zijn ideaal om een volledige certificate chain te importeren en te vertrouwen. Vaak worden deze files gebruikt door servers en firewalls. De *.p7b en *.p7c certificaten zijn de tegenhanger van de *.pfx en de *.p12 certificaten met als uitzondering dat het *.p7b bestand nooit de private key bevat.

Certificaat: Ja
Incl. Root Certificaten: Ja
Incl. Intermediate Certificaten: Ja
Incl. Private Key: Nee
Incl. Public Key: Ja (van de CA)
Versleuteling: Base64
Webservers: Voornamelijk IIS en JAVA TomCat Keytool
Herkenbaar aan: “—–BEGIN PKCS7—–” en “—–END PKCS7—– “ tags

*.csr (Certificate Signing Request) OF *.p10
Een Certificate Signing Request wordt vrijwel altijd gegenereerd in een * .csr bestand. Het *.csr bestand wordt bij de CA ingediend en dient als het eerste gedeelte voor het volledige certificaat.

Certificaat: Nee, alleen het 1e deel, de CSR
Incl. Root Certificaten: Nee
Incl. Intermediate Certificaten: Nee
Incl. Private Key: Nee
Incl. Public Key: Ja (van de aanvrager)
Versleuteling: Base64
Webservers: Bijna alle webservers zoals IIS en APACHE
Herkenbaar aan: “—– BEGIN NEW CERTIFICATE REQUEST —–” en “—– END NEW CERTIFICATE REQUEST —–“ tags

*.key (Private Key)
Het *.key bestand is de backup van de private key en bevat dus ook alleen maar de private key. Op Windows systemen kan de private key niet geëxporteerd worden uit een certificaat. Met OpenSSL (opensource-implementatie van het SSL/TLS protocol) is het echter wel mogelijk om de private key te exporteren. De private key wordt aangemaakt in hetzelfde proces als de *.csr wordt aangemaakt.

Certificaat: Nee, alleen de private key
Incl. Root Certificaten: Nee
Incl. Intermediate Certificaten: Nee
Incl. Private Key: Ja
Incl. Public Key: Nee
Versleuteling: Base64
Herkenbaar aan: “—– BEGIN RSA PRIVATE KEY —–” en “—– END RSA PRIVATE KEY —–“ tags

*.crl (Certificate Revocation List)
Tijdens de controle van het certificaat zal de computer of browser nakijken of het certificaat nog geldig is en niet vroegtijdig is ingetrokken. Als dat wel zo is dan is het certificaat aanwezig in de “Certificate Revocation List”. Deze CSR bestanden worden geleverd door de CA’s en gedownload tijdens de controle. Self-Signed certificaten hebben meestal geen CRL veld en worden dus ook niet gecontroleerd tegen een CRL lijst.

Certificaat: Nee
Incl. Root Certificaten: Nee
Incl. Intermediate Certificaten: Nee
Incl. Private Key: Nee
Incl. Public Key: Nee

Conclusie

Er valt veel te vertellen over digitale certificaten en waarom digitale certificaten de veiligheid waarborgen. Zoals altijd is veiligheid zo zwak als de zwakste schakel en kan er (zo leert het verleden ons) nog heel wat mis gaan. Digitale certificaten zijn echter al vele jaren een belangrijke schakel en naar verwachting zullen we nog lange tijd met digitale certificaten blijven werken. Hopelijk vonden jullie dit artikel verhelderend. Zo ja, schroom dan niet om het delen!

Dankjewel voor het lezen.