[{"data":1,"prerenderedAt":1798},["ShallowReactive",2],{"sc:header-data-nl":3,"sc:footer-data-nl":101,"glossary-posts-nl":138,"content-nl-list-c077398beed29":1797},{"lang":4,"home":5,"navigation":14,"contact":95},"en",{"name":6,"imgLight":7,"img":8,"languages":9},"home","/products/scepman/scepman-logo-all-white.svg","/products/scepman/scepman-logo-rgb.svg",{"nl":10},{"title":11,"url":12,"alt":13},"Home","/nl","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"nl":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"nl":22},{"title":23,"url":24},"Prijzen","/nl/pricing",{"name":26,"languages":27},"partner",{"nl":28},{"title":29,"url":30},"Partners","/nl/partner",{"name":32,"languages":33,"children":36},"support-hub",{"nl":34},{"title":35},"Support Hub",[37,53,68],{"name":38,"children":39},"support-hub-group-1",[40,47],{"name":41,"target":42,"languages":43},"docs","_blank",{"nl":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"nl":50},{"title":51,"url":52},"FAQ","/nl/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"nl":59},{"title":60,"url":61},"Support Ticket","https://support.scepman.com/support/tickets/new?ticket_form=technical_support_request_%28scepman%29",{"name":63,"target":42,"languages":64},"drop-a-question",{"nl":65},{"title":66,"url":67},"Drop a Question","https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29",{"name":69,"children":70},"support-hub-group-3",[71,77],{"name":72,"languages":73},"glossary",{"nl":74},{"title":75,"url":76},"Woordenlijst","/nl/glossary",{"name":78,"languages":79},"blog",{"nl":80},{"title":81,"url":82},"Blog","/nl/blog",{"name":84,"languages":85},"events",{"nl":86},{"title":87,"url":88},"Evenementen","/nl/events",{"name":90,"languages":91},"about",{"nl":92},{"title":93,"url":94},"Over ons","/nl/about-us",{"name":96,"languages":97},"contact",{"nl":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksNl":132},"sales@SCEPman.com",[105],{"img":106,"alt":107,"url":108},"/products/scepman/scepman-logo-yellow.svg","SCEPman Logo","/",[110,114,118],{"icon":111,"url":112,"title":113},"fa-x-twitter","https://twitter.com/scepman_","X",{"icon":115,"url":116,"title":117},"fa-youtube","https://www.youtube.com/channel/UCKnLYxlQFhzdXkDADV_Unrg","Youtube",{"icon":119,"url":120,"title":121},"fa-linkedin","https://www.linkedin.com/showcase/scepman","LinkedIn",[123,126,129],{"title":124,"url":125,"target":42},"Privacy","https://www.glueckkanja.com/en/privacy",{"title":127,"url":128,"target":42},"Imprint","https://www.glueckkanja.com/en/imprint",{"title":130,"url":131,"target":42},"Contact & Locations","https://www.glueckkanja.com/en/company/contact-and-locations",[133,134,136],{"title":124,"url":125,"target":42},{"title":135,"url":128,"target":42},"Juridische informatie",{"title":137,"url":131,"target":42},"Contact en locaties",[139,477,850,1109,1345],{"id":140,"title":141,"author":142,"body":143,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":460,"moment":142,"navigation":472,"path":473,"seo":474,"stem":475,"tags":142,"webcast":458,"__hash__":476},"content_nl/glossary/cryptography.md","Cryptografie",null,{"type":144,"value":145,"toc":433},"minimal",[146,151,163,170,198,204,226,230,233,236,245,248,256,295,299,302,306,309,313,316,320,323,326,330,334,337,363,367,370,387,391,394,398,401,405,408,413],[147,148,150],"h2",{"id":149},"welke-twee-soorten-sleutelgebaseerde-versleuteling-bestaan-er","Welke twee soorten sleutelgebaseerde versleuteling bestaan er?",[152,153,154,155,159,160],"p",{},"De twee belangrijkste soorten sleutelgebaseerde versleuteling zijn ",[156,157,158],"strong",{},"symmetrische versleuteling"," en ",[156,161,162],{},"asymmetrische versleuteling.",[164,165,167],"h3",{"id":166},"symmetrische-versleuteling",[156,168,169],{},"Symmetrische versleuteling",[171,172,173,180,186,192],"ul",{},[174,175,176,179],"li",{},[156,177,178],{},"Sleutelgebruik",": gebruikt één enkele sleutel voor zowel versleutelen als ontsleutelen.",[174,181,182,185],{},[156,183,184],{},"Snelheid",": over het algemeen sneller en efficiënter.",[174,187,188,191],{},[156,189,190],{},"Beveiliging",": de grootste uitdaging is om de sleutel veilig tussen de partijen te delen.",[174,193,194,197],{},[156,195,196],{},"Voorbeelden",": AES (Advanced Encryption Standard), DES (Data Encryption Standard).",[164,199,201],{"id":200},"asymmetrische-versleuteling",[156,202,203],{},"Asymmetrische versleuteling",[171,205,206,211,216,221],{},[174,207,208,210],{},[156,209,178],{},": gebruikt een sleutelpaar, namelijk een publieke sleutel om te versleutelen en een privésleutel om te ontsleutelen.",[174,212,213,215],{},[156,214,184],{},": trager dan symmetrische versleuteling, doordat de berekeningen complexer zijn.",[174,217,218,220],{},[156,219,190],{},": veiliger voor sleuteldistributie, omdat de privésleutel nooit wordt gedeeld.",[174,222,223,225],{},[156,224,196],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[164,227,229],{"id":228},"welk-type-versleuteling-geldt-als-veiliger","Welk type versleuteling geldt als veiliger?",[152,231,232],{},"Beide schema's gelden als veilig, in die zin dat geen enkele huidige computer het cijfer kan breken als je een modern algoritme met voldoende sleutellengte gebruikt.",[152,234,235],{},"Welk type versleuteling beter is, hangt af van het gebruiksscenario, maar veel scenario's vragen om asymmetrische versleuteling, omdat daarbij een sleutelpaar wordt gebruikt: een publieke sleutel om te versleutelen en een privésleutel om te ontsleutelen. De privésleutel blijft geheim, wat de beveiliging versterkt, want die hoeft nooit te worden gedeeld.",[164,237,239,240],{"id":238},"welk-type-versleuteling-is-beter-voor-grote-hoeveelheden-data","Welk type versleuteling is beter voor grote hoeveelheden data? ",[241,242],"a",{"href":243,"id":244},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[152,246,247],{},"Symmetrische versleuteling, omdat die sneller is.",[164,249,251,252],{"id":250},"hoe-verloopt-hybride-versleuteling-in-grote-lijnen","Hoe verloopt hybride versleuteling in grote lijnen? ",[241,253],{"href":254,"id":255},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[257,258,259,265,271,277,283,289],"ol",{},[174,260,261,264],{},[156,262,263],{},"Sleutelgeneratie",": de afzender genereert een verse symmetrische sleutel (ook wel sessiesleutel genoemd) om het eigenlijke bericht te versleutelen.",[174,266,267,270],{},[156,268,269],{},"Berichtversleuteling",": de afzender versleutelt de leesbare tekst met de symmetrische sleutel en produceert zo een cijfertekst.",[174,272,273,276],{},[156,274,275],{},"Sleutelversleuteling",": vervolgens versleutelt de afzender de symmetrische sleutel met de publieke sleutel van de ontvanger (asymmetrische versleuteling).",[174,278,279,282],{},[156,280,281],{},"Verzending",": de afzender stuurt zowel het versleutelde bericht (de cijfertekst) als de versleutelde symmetrische sleutel naar de ontvanger.",[174,284,285,288],{},[156,286,287],{},"Sleutelontsleuteling",": de ontvanger gebruikt zijn privésleutel om de symmetrische sleutel te ontsleutelen.",[174,290,291,294],{},[156,292,293],{},"Berichtontsleuteling",": ten slotte gebruikt de ontvanger de ontsleutelde symmetrische sleutel om de cijfertekst te ontsleutelen en de oorspronkelijke tekst terug te halen.",[147,296,298],{"id":297},"hashalgoritmen","Hashalgoritmen",[152,300,301],{},"Een hashalgoritme is een wiskundige functie die invoergegevens van willekeurige omvang omzet in een tekenreeks van vaste lengte, meestal een reeks letters en cijfers. Die uitvoer heet een hashwaarde of digest.",[164,303,305],{"id":304},"wat-is-een-botsing","Wat is een botsing?",[152,307,308],{},"Een botsing bij hashing treedt op wanneer twee verschillende stukken data via een hashalgoritme dezelfde hashwaarde opleveren. Dat kan problematisch zijn, want het hoofddoel van een hashalgoritme is juist om verschillende invoergegevens uniek weer te geven.",[164,310,312],{"id":311},"wat-is-een-mac","Wat is een MAC?",[152,314,315],{},"Message Authentication Code (MAC): in de cryptografie is een MAC een kort stukje informatie waarmee een bericht wordt geauthenticeerd en de integriteit ervan wordt geborgd. Het bevestigt dat het bericht niet is gewijzigd en bevestigt de identiteit van de afzender.",[164,317,319],{"id":318},"wat-is-het-verschil-tussen-een-mac-en-een-hmac","Wat is het verschil tussen een MAC en een HMAC?",[152,321,322],{},"MAC: een algemene term voor een code die de integriteit en authenticiteit van een bericht verifieert, op basis van blokcijfers of hashfuncties.",[152,324,325],{},"HMAC: een specifiek type MAC dat gebruikmaakt van een cryptografische hashfunctie en een geheime sleutel, met sterkere beveiligingseigenschappen.",[147,327,329],{"id":328},"asymmetrische-cryptografie","Asymmetrische cryptografie",[164,331,333],{"id":332},"hoe-verloopt-het-ondertekenen-van-een-bericht-in-grote-lijnen","Hoe verloopt het ondertekenen van een bericht in grote lijnen?",[152,335,336],{},"Het ondertekenen van berichten is een cryptografisch proces waarmee de authenticiteit en integriteit van een bericht worden geverifieerd.",[257,338,339,345,351,357],{},[174,340,341,344],{},[156,342,343],{},"Hash maken:"," de afzender genereert een unieke digitale vingerafdruk (hash) van het bericht met een cryptografische hashfunctie (bijvoorbeeld SHA-256). Die hash geeft de inhoud van het bericht uniek weer.",[174,346,347,350],{},[156,348,349],{},"Ondertekenen:"," de afzender versleutelt deze hash met zijn privésleutel en maakt daarmee de digitale handtekening. Zo kan de handtekening alleen worden gemaakt door iemand die toegang heeft tot de privésleutel van de afzender.",[174,352,353,356],{},[156,354,355],{},"Versturen:"," de digitale handtekening wordt aan het bericht gehecht en beide worden naar de ontvanger gestuurd. Ook de publieke sleutel van de afzender wordt meegeleverd voor de verificatie.",[174,358,359,362],{},[156,360,361],{},"Verificatie:"," de ontvanger gebruikt de publieke sleutel van de afzender om de digitale handtekening te ontsleutelen en zo de oorspronkelijke hash terug te halen. Vervolgens genereert de ontvanger een nieuwe hash van het ontvangen bericht en vergelijkt die met de ontsleutelde hash. Komen ze overeen, dan staat vast dat het bericht niet is gewijzigd en is de identiteit van de afzender geverifieerd.",[164,364,366],{"id":365},"wat-zijn-de-drie-functies-van-asymmetrische-versleuteling","Wat zijn de drie functies van asymmetrische versleuteling?",[152,368,369],{},"Asymmetrische versleuteling, ook bekend als publiekesleutelcryptografie, vervult verschillende belangrijke functies bij het beveiligen van communicatie en gegevens.",[257,371,372,377,382],{},[174,373,374],{},[156,375,376],{},"Versleutelen en ontsleutelen",[174,378,379],{},[156,380,381],{},"Digitale handtekeningen",[174,383,384],{},[156,385,386],{},"Sleuteluitwisseling",[164,388,390],{"id":389},"rsa","RSA",[152,392,393],{},"RSA, kort voor Rivest-Shamir-Adleman, is een breed gebruikt publiekesleutelcryptosysteem voor veilige gegevensoverdracht. Het is vernoemd naar de bedenkers Ronald Rivest, Adi Shamir en Leonard Adleman, die het in 1977 introduceerden.",[164,395,397],{"id":396},"diffie-hellman","Diffie-Hellman",[152,399,400],{},"De Diffie-Hellman-sleuteluitwisseling is een methode in de cryptografie om cryptografische sleutels veilig uit te wisselen via een openbaar kanaal. Ze werd in 1976 ontwikkeld door Whitfield Diffie en Martin Hellman. Het belangrijkste doel van de Diffie-Hellman-sleuteluitwisseling is twee partijen in staat te stellen om veilig een gedeelde geheime sleutel op te bouwen waarmee ze de daaropvolgende communicatie kunnen versleutelen.",[164,402,404],{"id":403},"digital-signature-algorithm-dsa","Digital Signature Algorithm (DSA)",[152,406,407],{},"Het Digital Signature Algorithm (DSA) is een cryptografisch algoritme met publieke sleutels waarmee digitale handtekeningen worden gemaakt en geverifieerd. Het werd in 1991 voorgesteld door het National Institute of Standards and Technology (NIST) als onderdeel van de Digital Signature Standard (DSS).",[409,410,412],"h4",{"id":411},"hoe-het-werkt","Hoe het werkt",[257,414,415,421,427],{},[174,416,417,420],{},[156,418,419],{},"Sleutelgeneratie:"," DSA genereert een sleutelpaar: een privésleutel om te ondertekenen en een publieke sleutel om te verifiëren.",[174,422,423,426],{},[156,424,425],{},"Ondertekenen",": de afzender gebruikt zijn privésleutel om een digitale handtekening op een bericht te zetten. Die handtekening is uniek voor zowel het bericht als de privésleutel.",[174,428,429,432],{},[156,430,431],{},"Verificatie",": de ontvanger gebruikt de publieke sleutel van de afzender om de authenticiteit van de handtekening te verifiëren en daarmee de integriteit en herkomst van het bericht.",{"title":434,"searchDepth":435,"depth":435,"links":436},"",2,[437,445,450],{"id":149,"depth":435,"text":150,"children":438},[439,441,442,443,444],{"id":166,"depth":440,"text":169},3,{"id":200,"depth":440,"text":203},{"id":228,"depth":440,"text":229},{"id":238,"depth":440,"text":239},{"id":250,"depth":440,"text":251},{"id":297,"depth":435,"text":298,"children":446},[447,448,449],{"id":304,"depth":440,"text":305},{"id":311,"depth":440,"text":312},{"id":318,"depth":440,"text":319},{"id":328,"depth":435,"text":329,"children":451},[452,453,454,455,456],{"id":332,"depth":440,"text":333},{"id":365,"depth":440,"text":366},{"id":389,"depth":440,"text":390},{"id":396,"depth":440,"text":397},{"id":403,"depth":440,"text":404},"md",false,"post",{"lang":461,"titleClass":462,"blogtitlepic":463,"socialimg":464,"customExcerpt":465,"asideNav":466,"maxContent":472},"nl","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","De kern van de uitdaging bij het enrollment van certificaten is hoe je het apparaat of de gebruiker authenticeert dat of die het certificaat aanvraagt. Met het certificaat bevestigt de CA dat de certificaathouder bepaalde eigenschappen heeft en dat ze de echtheid daarvan heeft gecontroleerd",{"menuItems":467},[468,470],{"href":469,"text":298},"#hashalgoritmen",{"href":471,"text":329},"#asymmetrische-cryptografie",true,"/glossary/cryptography",{"title":141,"description":434},"glossary/cryptography","s9HPrmhZAp_FiAecDUBMvQVrakLrTknPmSplWE7-G8A",{"id":478,"title":479,"author":142,"body":480,"cta":142,"description":484,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":834,"moment":142,"navigation":472,"path":846,"seo":847,"stem":848,"tags":142,"webcast":458,"__hash__":849},"content_nl/glossary/enrollment-methods.md","Enrollmentmethoden",{"type":144,"value":481,"toc":821},[482,485,488,491,520,610,612,616,626,630,648,651,654,658,661,664,687,691,694,697,710,714,717,720,723,726,729,732,741,744,748,752,755,761,765,774,777,780,783,800,811,814,817],[152,483,484],{},"Een kerneigenschap van enrollmentprotocollen voor certificaten is daarom hoe ze de aanvrager van een certificaat authenticeren. Afhankelijk van waarvoor het certificaat wordt gebruikt, is het ene of het andere protocol gunstiger.",[152,486,487],{},"Een andere belangrijke eigenschap is de verspreiding in de praktijk. De enrollmentmethode of het protocol moet voor het beoogde gebruiksscenario zowel door de CA als aan de clientzijde worden ondersteund.",[152,489,490],{},"De meest gebruikte enrollmentprotocollen zijn:",[171,492,493,499,502,505,511,514,517],{},[174,494,495],{},[241,496,498],{"href":497},"scep","SCEP",[174,500,501],{},"ACME",[174,503,504],{},"EST",[174,506,507],{},[241,508,510],{"href":509},"microsoft-rpc-dcom","RPC/DCOM van Microsoft",[174,512,513],{},"SOAP van Microsoft",[174,515,516],{},"Handmatig enrollment op de webpagina van de CA",[174,518,519],{},"Andere propriëtaire protocollen",[521,522,523,524],"table",{},"\n    ",[525,526,527,523,549,530,570,523,590],"tbody",{},[528,529,530,531,530,534,530,537,530,540,530,543,530,546,523],"tr",{},"\n        ",[532,533],"th",{},[532,535,536],{},"DCOM en RPC (propriëtair van Microsoft)",[532,538,539],{},"WS-Trust Enrollment Extension SOAP Enrollment",[532,541,542],{},"Automatic Certificate Management Environment (ACME)",[532,544,545],{},"Simple Certificate Enrollment Protocol (SCEP)",[532,547,548],{},"Enrollment over Secure Transport (EST)",[528,550,530,551,530,555,530,558,530,561,530,564,530,567,523],{},[552,553,554],"td",{},"Specificaties",[552,556,557],{},"Microsoft OpenSpec1",[552,559,560],{},"Microsoft OpenSpec2",[552,562,563],{},"RFC 8555",[552,565,566],{},"Informeel, nu RFC 8894",[552,568,569],{},"RFC 7030 (+ …)",[528,571,530,572,530,575,530,578,530,581,530,584,530,587,523],{},[552,573,574],{},"Implementatie",[552,576,577],{},"Serverzijde: Active Directory CS Clientzijde: Windows",[552,579,580],{},"Serverzijde: ADCS, andere? Clientzijde: Windows",[552,582,583],{},"Serverzijde: Let’s Encrypt Clientzijde: veel",[552,585,586],{},"Veel server- en clientimplementaties",[552,588,589],{},"Nauwelijks verspreid",[528,591,530,592,530,595,530,598,530,601,530,604,530,607,523],{},[552,593,594],{},"Authenticatie",[552,596,597],{},"AD-authenticatie",[552,599,600],{},"AD-authenticatie\\* (formeel hoeven gebruikersnaam en wachtwoord niet in AD te staan)",[552,602,603],{},"DNS-authenticatie",[552,605,606],{},"“SCEP Challenge”",[552,608,609],{},"CBA of HTTP Basic/Digest-authenticatie",[147,611,498],{"id":497},[164,613,615],{"id":614},"geschiedenis-en-specificatie","Geschiedenis en specificatie",[152,617,618,619,625],{},"Cisco bedacht het Simple Certificate Enrollment Protocol (SCEP) als eerste. Hoewel er destijds geen standaard bestond, raakte het breed verspreid in MDM-systemen. Cisco ging zelfs verder en ontwierp een opvolger, Enrollment over Secure Transport (EST), om SCEP te vervangen. EST werd daardoor veel eerder een publieke standaard, in RFC 7030, dan SCEP, dat pas veel later werd gestandaardiseerd in ",[241,620,624],{"href":621,"rel":622},"https://www.rfc-editor.org/rfc/rfc8894.html",[623],"nofollow","RFC 8894",", toen het al de de-factostandaard was voor certificaatenrollment in MDM-systemen.",[164,627,629],{"id":628},"technologie","Technologie",[152,631,632,633,637,638,642,643,647],{},"SCEP is HTTP-gebaseerd. Een SCEP-request is een versleutelde en ondertekende ",[241,634,636],{"href":635},"important-data-formats#pkcs7","PKCS#7"," die via een GET- of POST-request naar de SCEP-service wordt gestuurd. De service antwoordt met een SCEP-response, opnieuw een versleutelde en ondertekende PKCS#7. Het request bevat een ",[241,639,641],{"href":640},"important-data-formats#pkcs10","PKCS#10","-certificaataanvraag, de response bevat het uitgegeven ",[241,644,646],{"href":645},"important-data-formats#x509","X.509-certificaat",".",[164,649,594],{"id":650},"authenticatie",[152,652,653],{},"Het PKCS#10-request bevat een “SCEP Challenge” die de ondertekeningsaanvraag authenticeert en autoriseert via een out-of-bandmethode, afhankelijk van de specifieke SCEP-service. In de praktijk worden vandaag drie soorten SCEP Challenges gebruikt:",[409,655,657],{"id":656},"statische-scep-challenge","Statische SCEP Challenge",[152,659,660],{},"De eenvoudigste variant is een statische wachtwoordzin. Komt de SCEP Challenge in de PKCS#10 overeen met een vooraf vastgelegde waarde op de SCEP-service, dan wordt het certificaat uitgegeven, anders wordt het request geweigerd. Het probleem met deze methode is dat vrijwel niet te controleren valt of de aangevraagde eigenschappen van het certificaat bij de aanvrager passen. Voor dit probleem bestaat zelfs een CVE.",[152,662,663],{},"Deze methoden zijn verder te onderscheiden:",[257,665,666,674,681],{},[174,667,668,669,673],{},"Bij een ",[670,671,672],"em",{},"direct"," SCEP-enrollment communiceert de entiteit waarvoor het certificaat wordt uitgegeven, rechtstreeks met de SCEP-service. Een MDM-systeem draagt bijvoorbeeld een Android-telefoon op om een SCEP-enrollment uit te voeren met de SCEP Challenge “SecurePassword”. De Android-telefoon genereert een CSR, hopelijk met de juiste waarden, en voegt “SecurePassword” toe als SCEP Challenge. Vervolgens stuurt hij de CSR naar de SCEP-service en ontvangt het uitgegeven certificaat terug.",[174,675,676,677,680],{},"Een ",[670,678,679],{},"transparante SCEP-proxy"," werkt net als een HTTP-reverseproxy. Omdat SCEP versleuteld en ondertekend is, kan die niet echt in de SCEP-requests of -responses kijken en ze ook niet wijzigen, maar wel op basis van netwerkgrenzen sturen wie wanneer certificaten mag aanvragen.",[174,682,676,683,686],{},[670,684,685],{},"protocoladapter-SCEP-proxy"," is een systeem dat namens een ander systeem certificaten via SCEP aanvraagt. Een MDM-systeem als JAMF kan bijvoorbeeld namens een iPhone een certificaat aanvragen bij een SCEP-service. Zodra het het certificaat en de privésleutel heeft, kan het het certificaat via een ander protocol uitrollen. Zo heeft alleen het MDM-systeem toegang tot de SCEP Challenge en kan het ook de inhoud van het certificaat sturen.",[409,688,690],{"id":689},"dynamische-scep-challenge","Dynamische SCEP Challenge",[152,692,693],{},"In dit geval is elke SCEP Challenge maar geldig voor één enkele certificaataanvraag. Daardoor kan de SCEP-service het SCEP-request herkennen en verifiëren of de aangevraagde certificaateigenschappen overeenkomen met wat voor dat specifieke request is toegestaan.",[152,695,696],{},"In de praktijk zijn er doorgaans twee manieren waarop een MDM-systeem en een SCEP-CA een SCEP Challenge voor een request afspreken:",[257,698,699,707],{},[174,700,701,702],{},"Het MDM-systeem vraagt bij de SCEP-service een eenmalige code aan voor een SCEP-request wanneer het er een nodig heeft.\n",[257,703,704],{},[174,705,706],{},"Een voorbeeld is Microsoft NDES. NDES heeft een aparte adminpagina die met AD-inloggegevens wordt geauthenticeerd. Bij elke toegang tot die pagina maakt en toont NDES een nieuwe eenmalige code die voor één SCEP-request kan worden gebruikt. In deze configuratie controleert NDES echter geen enkele eigenschap van het certificaat, omdat de eenmalige code generiek is.",[174,708,709],{},"Het MDM-systeem genereert een eenmalige code wanneer het een beheerd systeem opdraagt om via SCEP een certificaat aan te vragen. Komt het SCEP-request binnen bij de SCEP-service, dan moet die de eenmalige code bij het MDM-systeem ophalen, meestal via een webhook, en controleren of die overeenkomt met de SCEP Challenge in het request. Voor dit protocol bestaat geen standaard, dus moeten het MDM-systeem en de SCEP-service onderling een formaat afspreken, en het hangt van de implementatie af of eigenschappen van het request worden gecontroleerd.",[409,711,713],{"id":712},"ondertekende-metadata","Ondertekende metadata",[152,715,716],{},"Er geldt vrijwel geen lengtebeperking voor de SCEP Challenge. Het hoeft dus geen voor mensen leesbare “wachtwoordzin” te zijn, maar het kan ook een BLOB zijn.",[152,718,719],{},"Intune gebruikt een ondertekende en versleutelde XML als SCEP Challenge. Intune maakt die XML aan de serverkant en stuurt hem naar een clientapparaat wanneer het een certificaat wil laten uitgeven en het SCEP-request wil laten aanmaken.",[152,721,722],{},"De SCEP-service moet het volledige PKCS#10-request naar een Intune SCEP Challenge-service sturen. Die SCEP Challenge-service beschikt over de privésleutel om de XML te ontsleutelen en over de publieke sleutel om te controleren of die door een echte Intune-service is gemaakt.",[152,724,725],{},"De XML bevat metadata over het request, bijvoorbeeld hoe het Subject eruit hoort te zien. Dat wordt enerzijds afgeleid van het SCEP-configuratieprofiel en anderzijds van de specifieke objectgegevens van de gebruiker of het apparaat voor wie of waarvoor het certificaat moet worden uitgegeven.",[152,727,728],{},"Het SCEP-configuratieprofiel kan bijvoorbeeld CN={{DeviceId}} als subject instellen. Vraagt het apparaat met id xyz een certificaat aan, dan zegt de XML dat het subject CN=xyz moet zijn. De SCEP Challenge-service vergelijkt vervolgens de informatie uit de XML met het subject in het PKCS#10-request. De validatie mislukt als de subjects verschillen en slaagt als dit en de andere eigenschappen overeenkomen.",[152,730,731],{},"De SCEP-service geeft het certificaat alleen uit als de validatie slaagt.",[152,733,734,735,740],{},"Microsoft heeft ",[241,736,739],{"href":737,"rel":738},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[623],"een artikel"," waarin deze verificatie wordt uitgelegd.",[152,742,743],{},"Microsoft NDES ondersteunt dit met een aanvullende NDES-policymodule, andere SCEP-CA's ondersteunen dit al dan niet van huis uit.",[147,745,747],{"id":746},"microsoft-rpcdcom","Microsoft RPC/DCOM",[164,749,751],{"id":750},"geschiedenis","Geschiedenis",[152,753,754],{},"Microsoft Active Directory Certificate Services (ADCS), soms alleen “Microsoft CA” genoemd, is de CA-software die in Windows Server is ingebouwd. De software werd oorspronkelijk aan het eind van het vorige millennium ontwikkeld en kreeg de tien tot vijftien jaar daarna nog enkele uitbreidingen.",[152,756,757,758,760],{},"Een alternatief is SOAP van Microsoft of ",[241,759,498],{"href":497},", die Microsoft respectievelijk Web Enrollment en NDES noemt.",[164,762,764],{"id":763},"specificatie-en-verspreiding","Specificatie en verspreiding",[152,766,767,768,773],{},"Voor zover wij weten implementeren geen andere CA-systemen dit protocol, hoewel Microsoft inmiddels ",[241,769,772],{"href":770,"rel":771},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[623],"de specificatie in Microsoft OpenSpec"," heeft gepubliceerd. Aan de clientzijde heeft Windows ingebouwde ondersteuning voor het protocol, andere platformen worden niet ondersteund.",[164,775,629],{"id":776},"technologie-1",[152,778,779],{},"De belangrijkste enrollmentmethode is een propriëtair protocol op basis van RPC of DCOM.",[152,781,782],{},"Ook autoenrollment gebruikt dit protocol. Om autoenrollment te laten werken heb je nodig:",[171,784,785,788,791,794,797],{},[174,786,787],{},"een apparaat dat lid is van het domein.",[174,789,790],{},"Group Policy die autoenrollment inschakelt,",[174,792,793],{},"een Enterprise CA (in tegenstelling tot stand-alone)",[174,795,796],{},"die een certificaatsjabloon uitgeeft waarvoor",[174,798,799],{},"de gebruiker of het apparaat de rechten enroll en autoenroll heeft.",[152,801,802,803,807,808,647],{},"Standaard wordt er elke 8 uur op autoenrollments gecontroleerd, al kun je dat afdwingen met ",[804,805,806],"code",{},"certutil -pulse"," of vaak beter met ",[804,809,810],{},"gpupdate -force",[164,812,594],{"id":813},"authenticatie-1",[152,815,816],{},"Dit protocol gebruikt de authenticatieprotocollen die in Active Directory zijn ingebouwd, dat wil zeggen dat gebruikers en computers zich authenticeren met hun AD-inloggegevens.",[818,819,820],"style",{},"\n    table {border: 2px solid white}\n    th, td {border: solid black; padding-left: 1em; padding-right: 1em; font-size: smaller}\n",{"title":434,"searchDepth":435,"depth":435,"links":822},[823,828],{"id":497,"depth":435,"text":498,"children":824},[825,826,827],{"id":614,"depth":440,"text":615},{"id":628,"depth":440,"text":629},{"id":650,"depth":440,"text":594},{"id":746,"depth":435,"text":747,"children":829},[830,831,832,833],{"id":750,"depth":440,"text":751},{"id":763,"depth":440,"text":764},{"id":776,"depth":440,"text":629},{"id":813,"depth":440,"text":594},{"lang":461,"seoTitle":835,"titleClass":462,"socialimg":836,"blogtitlepic":837,"customExcerpt":838,"keywords":839,"asideNav":840,"maxContent":472},"Enrollmentmethoden voor certificaten: SCEP, ACME, EST en Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Ontdek hoe het enrollment van certificaten werkt met SCEP, ACME, EST, Microsoft RPC en handmatige methoden. Vergelijk de enrollmentprotocollen van een PKI voor veilige certificaatuitgifte.","enrollmentmethoden voor certificaten, SCEP, ACME, EST, Microsoft RPC, enrollmentprotocol voor certificaten, certificaatenrollment in een PKI, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, Microsoft certificaatenrollment",{"menuItems":841},[842,844],{"href":843,"text":498},"#scep",{"href":845,"text":747},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":479,"description":484},"glossary/enrollment-methods","43Qyi4_jcAeSUt9ONd0PEy8RZYztowNqKxV5-Jj2WNU",{"id":851,"title":852,"author":142,"body":853,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":1087,"moment":142,"navigation":472,"path":1105,"seo":1106,"stem":1107,"tags":142,"webcast":458,"__hash__":1108},"content_nl/glossary/important-data-formats.md","Belangrijke dataformaten",{"type":144,"value":854,"toc":1070},[855,859,878,885,888,892,896,899,902,905,909,912,916,919,922,930,933,937,945,948,951,954,965,969,982,986,989,992,995,998,1006,1010,1013,1016,1019,1030,1034,1037,1041,1050,1053,1061,1064],[147,856,858],{"id":857},"x509","X.509",[152,860,861,862,865,866,871,872,877],{},"X.509 is ",[670,863,864],{},"de"," standaard voor digitale certificaten. Er waren ooit concurrenten zoals ",[241,867,870],{"href":868,"rel":869},"https://www.rfc-editor.org/rfc/rfc4880",[623],"OpenPGP",", maar die worden tegenwoordig veel minder gebruikt. Al is X.509 eigenlijk niet de juiste standaard. X.509 is namelijk een ITU-T-standaard, terwijl de definities die er echt toe doen onderdeel zijn van ",[241,873,876],{"href":874,"rel":875},"https://www.rfc-editor.org/rfc/rfc5280",[623],"RFC 5280",", oftewel een standaard van de IETF en niet van ITU-T. Die RFC definieert het “PKI Profile for the Internet” op basis van X.509, en dat is het enige profiel dat er in de praktijk echt toe doet.",[152,879,880,881,884],{},"Een digitaal certificaat maakt gebruik van asymmetrische cryptografie en in het bijzonder van digitale handtekeningen. Het meest voorkomende gebruiksscenario voor digitale certificaten is vandaag serverauthenticatie. Iedereen heeft er al mee gewerkt, waarschijnlijk meestal zonder te weten dat het om een X.509-certificaat ging: elke keer dat je een HTTP",[156,882,883],{},"S","-website bezoekt, brengt de browser een TLS-verbinding met de webserver tot stand. De webserver gebruikt een X.509-certificaat om te bewijzen wie hij is. Wanneer mensen bijvoorbeeld de website van hun bank bezoeken om geld over te maken, willen ze zeker weten dat ze echt met hun bank communiceren. Aanvallers zouden zich kunnen voordoen als de banksite, het wachtwoord en de TAN van de gebruiker kunnen lezen en het geld vervolgens naar een eigen rekening kunnen overmaken. HTTPS helpt dat te voorkomen, want de aanvallers hebben het X.509-certificaat van de webserver van de bank niet. Zegt de browser dat je een bepaald domein bezoekt via een HTTPS-verbinding, dan borgt het certificaat dat je echt verbonden bent met een webserver van iemand die dat domein bezit.",[152,886,887],{},"Hoe doet het certificaat dat? Het certificaat bevat wat metadata, de publieke sleutel van een cryptografisch sleutelpaar en een handtekening van een certificaatautoriteit. Laten we die drie onderdelen langslopen:",[164,889,891],{"id":890},"inhoud-van-een-x509-certificaat","Inhoud van een X.509-certificaat",[409,893,895],{"id":894},"metadata","Metadata",[152,897,898],{},"De metadata van het X.509-certificaat leggen onder meer vast voor welke periode het geldig is, waarvoor het certificaat mag worden gebruikt en aan wie het is uitgegeven. Bij een TLS-servercertificaat bevatten ze in het bijzonder het domein van de webserver. De browser vergelijkt het domein dat hij probeerde te bezoeken met dat in het certificaat. Komen ze niet overeen, dan gaat de browser niet verder maar toont hij een waarschuwing. Is het certificaat verlopen, dan toont hij ook een waarschuwing.",[152,900,901],{},"Vreemd genoeg toonden browsers vaak geen waarschuwing als je een HTTP-site zonder TLS bezocht, terwijl dat nog minder veilig is. Bezocht je een webserver met een ongeldig X.509-certificaat, dan kon het om een simpele configuratiefout gaan en was je misschien wel degelijk beschermd tegen aanvallers die je verbinding afluisteren, terwijl een HTTP-verbinding helemaal geen bescherming biedt.",[152,903,904],{},"Op dit punt is wel vooruitgang geboekt, bijvoorbeeld met certificate pinning. Maar dat is gevorderde stof, dus laten we naar de andere twee onderdelen van een X.509-certificaat kijken.",[409,906,908],{"id":907},"publieke-sleutel","Publieke sleutel",[152,910,911],{},"Het certificaat bevat het publieke deel van een asymmetrisch sleutelpaar. De cryptografie stelt de webserver, of algemener de certificaathouder bij een ander gebruiksscenario, in staat om te bewijzen dat hij ook het private deel van het sleutelpaar bezit, zonder dat deel prijs te geven aan de verbindende client of aan wie dan ook. Zo kan de client er zeker van zijn dat de webserver werkelijk de eigenaar van het certificaat is en niet iemand die het gekopieerd heeft. Het certificaat zelf kopiëren is namelijk vrij eenvoudig, want de webserver stuurt er een kopie van naar iedereen die verbinding probeert te maken. De privésleutel stelen is lastig tot onmogelijk, want die verlaat de webserver nooit. Er zijn verschillende methoden om het stelen van de privésleutel nog moeilijker te maken, zoals HSM's en TPM's.",[409,913,915],{"id":914},"handtekening-van-een-certificaatautoriteit","Handtekening van een certificaatautoriteit",[152,917,918],{},"Aan de metadata kan de client zien dat het certificaat geschikt is voor het specifieke gebruiksscenario. De publieke sleutel laat zien dat de tegenpartij werkelijk de eigenaar van het certificaat is. Maar een aanvaller zou gewoon een nieuw sleutelpaar en een nieuw certificaat kunnen maken die ook aan die twee criteria voldoen. Hoe weet een client dan dat het certificaat te vertrouwen is?",[152,920,921],{},"Het certificaat bevat een cryptografische handtekening van een ander sleutelpaar, dat hoort bij het certificaat van een certificaatautoriteit (CA). Dat CA-certificaat kan op dezelfde manier worden gecontroleerd en is zelf ook door een certificaat ondertekend. De client kan deze “vertrouwensketen” volgen van het zogenoemde bladcertificaat tot aan het Root CA-certificaat, dat hij herkent aan het feit dat het zelfondertekend is: de handtekening van het certificaat komt van zijn eigen sleutelpaar. Meestal zijn dat maar één of twee stappen, dus zijn er ook maar één of twee CA-certificaten bij betrokken.",[152,923,924,925,929],{},"CA's moeten zorgvuldig controleren of de metadata kloppen wanneer ze ",[241,926,928],{"href":927},"enrollment-methods/","een certificaat uitgeven",". Wil je bijvoorbeeld een TLS-servercertificaat voor je eigen domein, dan moet je de CA bewijzen dat je echt de eigenaar bent. Afhankelijk van hoe grondig die controle is, krijg je een basiscertificaat of een Extended Validation-certificaat (EV).",[152,931,932],{},"Elke browser en elk besturingssysteem wordt geleverd met een lijst van vooraf vastgelegde vertrouwde Root CA's. Gebruikers en beheerders kunnen extra vertrouwde Root CA's toevoegen. Sommige Root CA's worden alleen voor bepaalde doeleinden vertrouwd, andere genieten een algemener vertrouwen. De client controleert of de vertrouwensketen eindigt bij een vertrouwde Root CA. Is dat zo, zijn alle certificaten in de vertrouwensketen nog geldig en zeggen de metadata dat ze volgens hun doel worden gebruikt, dan wordt het bladcertificaat van de webserver vertrouwd en komt de verbinding tot stand.",[164,934,936],{"id":935},"geldigheid-van-x509-certificaten","Geldigheid van X.509-certificaten",[152,938,939,940,944],{},"Bij X.509-certificaten draait alles om vertrouwen dat moet worden opgebouwd. Zoals uitgelegd is één criterium voor vertrouwen dat een certificaat moet aanknopen bij een vertrouwde Root CA. Een ander is dat het zich binnen zijn geldigheidsduur bevindt. Meestal betekent dat dat het niet verlopen is, maar een certificaat kan, doorgaans door technische fouten, ook nog niet geldig zijn. Er is nog een criterium: de CA die het certificaat heeft uitgegeven, mag het niet hebben ingetrokken. Omdat dat een onderwerp op zich is, hebben we er een ",[241,941,943],{"href":942},"other-stuff/certificate-lifecycle-management","apart artikel"," over.",[147,946,636],{"id":947},"pkcs7",[152,949,950],{},"PKCS#7 is het Zwitserse zakmes onder de cryptografische dataformaten en kan vrijwel alles bevatten: versleutelde berichten, ondertekende berichten, ondertekende en versleutelde berichten, certificaten en privésleutels",[152,952,953],{},"Dat is meteen het grote nadeel van dit formaat. Krijgt een applicatie of gebruiker een PKCS#7, dan is op zichzelf niet duidelijk wat ermee moet gebeuren. Een paar belangrijke gebruiksscenario's:",[171,955,956,959,962],{},[174,957,958],{},"S/MIME-berichten zijn in feite e-mails met PKCS#7-bodies of -bijlagen.",[174,960,961],{},"SCEP-requests en -replies zijn allebei eigenlijk met PKCS#7 ondertekende berichten.",[174,963,964],{},"EST-responses zijn CMS-berichten.",[164,966,968],{"id":967},"codering","Codering",[152,970,971,972,976,977,981],{},"Veelgebruikte bestandsextensies zijn .p7b (",[241,973,975],{"href":974},"asn.1-and-pem#der-encoding","DER-gecodeerd","), .p7s (een ondertekend bericht of een berichthandtekening) en .p7m (een ondertekend en/of versleuteld bericht). De ",[241,978,980],{"href":979},"asn.1-and-pem#pem-encoding","PEM-codering"," met het label “PKCS7” is ook gedefinieerd, maar wordt zelden gebruikt.",[164,983,985],{"id":984},"tools","Tools",[152,987,988],{},"In Windows kun je PKCS#7-berichten openen met een dubbelklik, waarna de Crypto Shell Extensions ze voor je weergeven. Meestal kun je er echter alleen certificaten en hun privésleutels uit halen, en geen berichtinhoud.",[152,990,991],{},"Met tools als OpenSSL kun je deze bestanden naar andere formaten omzetten.",[147,993,641],{"id":994},"pkcs10",[152,996,997],{},"Een certificaataanvraag (Certificate Signing Request, CSR) zoals gedefinieerd in PKCS#10 is een bestand met een beschrijving van een certificaat dat je bij een certificaatautoriteit (CA) wilt aanvragen. Het heeft een vergelijkbare structuur als een X.509-certificaat, maar de handtekening van een CA ontbreekt. In plaats daarvan bevat het de handtekening van de certificaataanvrager. Het blijft een ander formaat, dus het is niet hetzelfde als een zelfondertekend certificaat.",[152,999,1000,1001,647],{},"Het kan binair DER-gecodeerd zijn of PEM-gecodeerd ",[241,1002,1005],{"href":1003,"rel":1004},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[623],"met het label “CERTIFICATE REQUEST”",[147,1007,1009],{"id":1008},"pkcs12","PKCS#12",[152,1011,1012],{},"PKCS#12 staat ook bekend als PFX, vooral in Windows-omgevingen. Veelgebruikte bestandsextensies zijn daarom .pfx en .p12. Het bevat X.509-certificaten en vrijwel altijd de bijbehorende privésleutels, al wordt dat technisch gezien niet afgedwongen.",[152,1014,1015],{},"Data in een PKCS#12-bestand is meestal met wachtwoorden versleuteld. Vaak is alleen de privésleutel versleuteld, zodat je de certificaten zonder de wachtwoorden zou kunnen uitpakken als je applicatie dat toelaat (de meeste doen dat niet). PKCS#12 is in Windows-omgevingen de meest gebruikelijke manier om een certificaat en de bijbehorende privésleutel in een bestand op te slaan. In Linux-omgevingen zijn PEM-gecodeerde PKCS#8-bestanden gebruikelijker.",[152,1017,1018],{},"Omdat de standaard veel mogelijkheden biedt om certificaten en privésleutels in geneste “safebags” op te slaan, kennen PKCS#12-bestanden een aantal compatibiliteitsproblemen, zoals:",[171,1020,1021,1024,1027],{},[174,1022,1023],{},"Windows staat erom bekend dat het privésleutels in een PKCS#12 koppelt aan alle certificaten die uit het bestand worden gehaald, en niet alleen aan het certificaat waarvoor ze bedoeld zijn. Bevat de PKCS#12 een certificaatketen, dan kan Windows tonen dat het de privésleutel voor het CA-certificaat heeft.",[174,1025,1026],{},"Op macOS kun je PKCS#12-bestanden niet importeren als de cryptografische algoritmen te nieuw zijn.",[174,1028,1029],{},"Het kan nodig zijn om de certificaten in een PKCS#12-bestand te versleutelen zodat ontvangende applicaties ze kunnen uitpakken. Sommige ondersteunen echter alleen heel oude en zwakke algoritmen, wat meestal geen probleem is omdat de informatie toch openbaar is. Maar OpenSSL 3.x ondersteunt die oude en kwetsbare algoritmen niet en weigert de PKCS#12 te openen.",[147,1031,1033],{"id":1032},"asn1-en-pem","ASN.1 en PEM",[152,1035,1036],{},"Abstract Syntax Notation One (ASN.1) is een taal om datastructuren te beschrijven. Er zijn een aantal vooraf gedefinieerde basisdatatypen, zoals integers of sequences, en de auteur van een protocol of bestandsformaat kan daarmee vervolgens eigen datatypen definiëren.",[164,1038,1040],{"id":1039},"der-codering","DER-codering",[152,1042,1043,1044,1049],{},"De ",[241,1045,1048],{"href":1046,"rel":1047},"https://www.itu.int/rec/T-REC-X.680/",[623],"ITU-T-standaard X.680"," definieert verschillende coderingen voor data die in ASN.1 is gespecificeerd. Voor X.509-gerelateerde data is DER de belangrijkste codering, omdat er maar één manier is om een type te coderen. Een hash van de binaire DER-weergave van het type heeft daardoor altijd dezelfde waarde, wat bijvoorbeeld belangrijk is bij het ondertekenen van ASN.1-gecodeerde data.",[164,1051,980],{"id":1052},"pem-codering",[152,1054,1055,1056,1060],{},"Voor veel, maar niet alle X.509-gerelateerde bestandstypen kun je het bestand binair opslaan in DER-codering of er een extra ",[241,1057,980],{"href":1058,"rel":1059},"https://datatracker.ietf.org/doc/html/rfc7468",[623]," overheen leggen. PEM gebruikt uitsluitend ASCII-tekens en kan daardoor eenvoudig via het klembord worden gekopieerd en geplakt of, enkele decennia geleden toen dat nog relevant was, per e-mail worden verstuurd.",[164,1062,985],{"id":1063},"tools-1",[152,1065,1066,1067,647],{},"Heb je een ASN.1-gecodeerd bestand en weet je niet welk type het is, of heb je geen applicatie die dat specifieke type aankan, dan kun je de ruwe ASN.1-structuur alsnog decoderen en bekijken wat erin staat. Op Windows kan het ingebouwde tool certutil dat met de opdracht ",[804,1068,1069],{},"certutil -decode",{"title":434,"searchDepth":435,"depth":435,"links":1071},[1072,1076,1080,1081,1082],{"id":857,"depth":435,"text":858,"children":1073},[1074,1075],{"id":890,"depth":440,"text":891},{"id":935,"depth":440,"text":936},{"id":947,"depth":435,"text":636,"children":1077},[1078,1079],{"id":967,"depth":440,"text":968},{"id":984,"depth":440,"text":985},{"id":994,"depth":435,"text":641},{"id":1008,"depth":435,"text":1009},{"id":1032,"depth":435,"text":1033,"children":1083},[1084,1085,1086],{"id":1039,"depth":440,"text":1040},{"id":1052,"depth":440,"text":980},{"id":1063,"depth":440,"text":985},{"lang":461,"seoTitle":1088,"titleClass":462,"blogtitlepic":1089,"socialimg":1090,"customExcerpt":1091,"keywords":1092,"asideNav":1093,"maxContent":472},"Belangrijke dataformaten: X.509, PKCS, ASN.1 en PEM uitgelegd","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Ontdek de belangrijkste cryptografie- en certificaatformaten, waaronder X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 en PEM.","belangrijke dataformaten, X.509-certificaat, PKCS-formaten, PKCS 7, PKCS 10, PKCS 12, ASN.1, PEM-formaat, digitale certificaten, public key infrastructure, PKI-formaten",{"menuItems":1094},[1095,1097,1099,1101,1103],{"href":1096,"text":858},"#x509",{"href":1098,"text":636},"#pkcs7",{"href":1100,"text":641},"#pkcs10",{"href":1102,"text":1009},"#pkcs12",{"href":1104,"text":1033},"#asn1-en-pem","/glossary/important-data-formats",{"title":852,"description":434},"glossary/important-data-formats","ej25RQ-H1TySzggKpRUJU5ua91V8pSt9hRf1E7jKgyA",{"id":1110,"title":1111,"author":142,"body":1112,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":1335,"moment":142,"navigation":472,"path":1341,"seo":1342,"stem":1343,"tags":142,"webcast":458,"__hash__":1344},"content_nl/glossary/public-key-infrastructure.md","Public Key Infrastructure",{"type":144,"value":1113,"toc":1324},[1114,1118,1126,1129,1161,1165,1168,1172,1175,1205,1208,1212,1215,1235,1238,1242,1249,1263,1268,1282,1286,1291,1304,1309,1321],[147,1115,1117],{"id":1116},"vertrouwen-opbouwen","Vertrouwen opbouwen",[164,1119,1121,1122,1125],{"id":1120},"hoe-geeft-een-client-aan-dat-hij-een-bepaalde-root-ca-vertrouwt","Hoe ",[156,1123,1124],{},"geeft"," een client aan dat hij een bepaalde Root CA vertrouwt?",[152,1127,1128],{},"Een client geeft zijn vertrouwen in een bepaalde Root CA (certificaatautoriteit) aan via een proces rond de certificaatketen van vertrouwen. Zo werkt het:",[171,1130,1131,1137,1143,1149,1155],{},[174,1132,1133,1136],{},[156,1134,1135],{},"Vooraf geïnstalleerde rootcertificaten:"," de meeste besturingssystemen en webbrowsers worden geleverd met een set vooraf geïnstalleerde rootcertificaten van vertrouwde CA's. Die rootcertificaten staan in een store met vertrouwde rootcertificaten.",[174,1138,1139,1142],{},[156,1140,1141],{},"Certificaatvalidatie:"," wanneer een client verbinding maakt met een server, bijvoorbeeld bij het bezoeken van een website, presenteert de server zijn TLS-certificaat. Dat certificaat is doorgaans ondertekend door een Intermediate CA, die op haar beurt is ondertekend door een Root CA.",[174,1144,1145,1148],{},[156,1146,1147],{},"Verificatie van de vertrouwensketen:"," de client verifieert de vertrouwensketen door te controleren of het gepresenteerde certificaat is ondertekend door een vertrouwde Root CA. Ook controleert hij of de Intermediate CA's in de keten worden vertrouwd.",[174,1150,1151,1154],{},[156,1152,1153],{},"Digitale handtekeningen:"," elk certificaat in de keten is digitaal ondertekend door de CA erboven. De client gebruikt de publieke sleutel van die CA om deze handtekeningen te verifiëren en zo vast te stellen dat er niet met de certificaten is geknoeid.",[174,1156,1157,1160],{},[156,1158,1159],{},"Vertrouwensbeslissing:"," is de volledige vertrouwensketen geldig en leidt die terug naar een vertrouwde Root CA, dan vertrouwt de client het certificaat van de server. Daarmee kan de veilige communicatie doorgaan.",[164,1162,1164],{"id":1163},"wat-is-het-voordeel-van-intermediate-cas-in-plaats-van-één-enkele-root-ca","Wat is het voordeel van Intermediate CA's in plaats van één enkele Root CA?",[152,1166,1167],{},"Voor infrastructuur-PKI's kan één enkele root juist voordelig zijn.",[164,1169,1171],{"id":1170},"hoe-komt-een-intermediate-ca-aan-zijn-certificaat","Hoe komt een Intermediate CA aan zijn certificaat?",[152,1173,1174],{},"Een Intermediate CA (certificaatautoriteit) komt aan zijn certificaat via een proces dat cross-signing heet, uitgevoerd door een Root CA. Zo werkt het:",[257,1176,1177,1183,1189,1194,1199],{},[174,1178,1179,1182],{},[156,1180,1181],{},"Certificate Signing Request (CSR):"," de organisatie die een Intermediate CA wil opzetten, genereert een CSR. Die CSR bevat de publieke sleutel en de identificerende gegevens van de Intermediate CA.",[174,1184,1185,1188],{},[156,1186,1187],{},"Indienen bij de Root CA:"," de CSR wordt ingediend bij een vertrouwde Root CA.",[174,1190,1191,1193],{},[156,1192,361],{}," de Root CA verifieert de identiteit en legitimiteit van de organisatie die het intermediate certificaat aanvraagt.",[174,1195,1196,1198],{},[156,1197,349],{}," zodra dat geverifieerd is, ondertekent de Root CA de CSR met haar privésleutel en maakt zo het intermediate certificaat. Dat ondertekende certificaat verbindt de Intermediate CA met de Root CA en legt daarmee een vertrouwensketen vast.",[174,1200,1201,1204],{},[156,1202,1203],{},"Uitgifte:"," de Root CA geeft het ondertekende intermediate certificaat uit aan de aanvragende organisatie, die het vervolgens kan gebruiken om eindentiteitscertificaten te ondertekenen, bijvoorbeeld TLS-certificaten voor websites.",[152,1206,1207],{},"Dit proces zorgt ervoor dat de Intermediate CA wordt vertrouwd dankzij zijn verbinding met de Root CA, die al wordt vertrouwd door browsers en besturingssystemen.",[164,1209,1211],{"id":1210},"wat-is-een-certificaatketen-en-hoe-werkt-die","Wat is een certificaatketen en hoe werkt die?",[152,1213,1214],{},"Een certificaatketen, ook bekend als vertrouwensketen, is een reeks certificaten die de authenticiteit en betrouwbaarheid van een digitaal certificaat borgt. Zo werkt het:",[171,1216,1217,1223,1229],{},[174,1218,1219,1222],{},[156,1220,1221],{},"Verificatieproces:"," wanneer een client, bijvoorbeeld een webbrowser, verbinding maakt met een server, presenteert de server zijn eindentiteitscertificaat. De client controleert vervolgens de certificaatketen om vast te stellen dat elk certificaat is ondertekend door het volgende certificaat in de keten, tot aan het rootcertificaat.",[174,1224,1225,1228],{},[156,1226,1227],{},"Vertrouwensketen:"," elk certificaat in de keten wordt geverifieerd met de publieke sleutel van het certificaat erboven. Dat gaat door tot aan het rootcertificaat, dat de client al vertrouwt.",[174,1230,1231,1234],{},[156,1232,1233],{},"Vertrouwen vaststellen:"," is de hele keten geldig en leidt die terug naar een vertrouwd rootcertificaat, dan vertrouwt de client het eindentiteitscertificaat en kan de veilige communicatie doorgaan.",[152,1236,1237],{},"Dit systeem borgt dat het eindentiteitscertificaat legitiem is en is uitgegeven door een vertrouwde autoriteit, waarmee de integriteit en beveiliging van digitale communicatie in stand blijven.",[164,1239,1241],{"id":1240},"welk-probleem-wil-de-extensie-basic-constraints-oplossen","Welk probleem wil de extensie Basic Constraints oplossen?",[152,1243,1244,1245,1248],{},"De extensie ",[156,1246,1247],{},"Basic Constraints"," in een digitaal certificaat pakt het probleem aan van het onderscheiden van verschillende soorten certificaten en hun rol binnen een public key infrastructure (PKI). Zo werkt het:",[171,1250,1251,1257],{},[174,1252,1253,1256],{},[156,1254,1255],{},"Herkenning van een certificaatautoriteit (CA):"," de extensie geeft aan of een certificaat een CA-certificaat is of een eindentiteitscertificaat. Dat onderscheid is cruciaal, want CA-certificaten kunnen andere certificaten uitgeven, eindentiteitscertificaten niet.",[174,1258,1259,1262],{},[156,1260,1261],{},"Padlengtebeperking:"," de extensie kan het aantal Intermediate CA's beperken dat onder deze CA in de certificaatketen mag bestaan. Zo worden overmatig lange certificaatketens voorkomen, die inefficiënt en mogelijk onveilig zijn.",[152,1264,1265],{},[156,1266,1267],{},"Opgeloste problemen:",[171,1269,1270,1276],{},[174,1271,1272,1275],{},[156,1273,1274],{},"Ongeautoriseerde certificaatuitgifte voorkomen:"," door duidelijk te markeren welke certificaten als CA mogen optreden, wordt voorkomen dat eindentiteitscertificaten andere certificaten uitgeven, waarmee de integriteit van de PKI behouden blijft.",[174,1277,1278,1281],{},[156,1279,1280],{},"De lengte van de certificaatketen beheersen:"," door de padlengte te beperken blijft de certificaatketen hanteerbaar en veilig, en worden mogelijke kwetsbaarheden van lange ketens voorkomen",[164,1283,1285],{"id":1284},"welke-mechanismen-gebruikt-ze-om-die-problemen-op-te-lossen"," Welke mechanismen gebruikt ze om die problemen op te lossen?",[152,1287,1244,1288,1290],{},[156,1289,1247],{}," in een digitaal certificaat gebruikt de volgende mechanismen om CA-certificaten van eindentiteitscertificaten te onderscheiden en de lengte van de certificaatketen te beheersen:",[171,1292,1293,1299],{},[174,1294,1295,1298],{},[156,1296,1297],{},"CA-vlag:"," deze vlag geeft aan of het certificaat een CA-certificaat (certificaatautoriteit) is of een eindentiteitscertificaat. Staat de vlag op TRUE, dan kan het certificaat worden gebruikt om andere certificaten te ondertekenen en is het dus een CA-certificaat. Staat die op FALSE, dan is het een eindentiteitscertificaat en kan het geen andere certificaten uitgeven.",[174,1300,1301,1303],{},[156,1302,1261],{}," deze geeft het maximale aantal niet-zelf uitgegeven intermediate certificaten aan dat in een geldig certificeringspad op dit certificaat mag volgen. Met die beperking begrenst de extensie de lengte van de certificaatketen, zodat die hanteerbaar en veilig blijft.",[152,1305,1306],{},[156,1307,1308],{},"Hoe deze mechanismen werken:",[171,1310,1311,1316],{},[174,1312,1313,1315],{},[156,1314,1297],{}," bij de uitgifte van een certificaat wordt de CA-vlag ingesteld volgens het beoogde gebruik van het certificaat. Tijdens de certificaatvalidatie controleren clients deze vlag om te bepalen of het certificaat mag worden vertrouwd om andere certificaten uit te geven.",[174,1317,1318,1320],{},[156,1319,1261],{}," deze waarde wordt tijdens het validatieproces gecontroleerd om te borgen dat de certificaatketen de opgegeven lengte niet overschrijdt. Is de keten te lang, dan geldt het certificaat als ongeldig.",[152,1322,1323],{},"Deze mechanismen helpen de integriteit en beveiliging van de public key infrastructure (PKI) in stand te houden, doordat alleen geautoriseerde certificaten andere certificaten kunnen uitgeven en overmatig lange certificaatketens worden voorkomen.",{"title":434,"searchDepth":435,"depth":435,"links":1325},[1326],{"id":1116,"depth":435,"text":1117,"children":1327},[1328,1330,1331,1332,1333,1334],{"id":1120,"depth":440,"text":1329},"Hoe geeft een client aan dat hij een bepaalde Root CA vertrouwt?",{"id":1163,"depth":440,"text":1164},{"id":1170,"depth":440,"text":1171},{"id":1210,"depth":440,"text":1211},{"id":1240,"depth":440,"text":1241},{"id":1284,"depth":440,"text":1285},{"lang":461,"seoTitle":1336,"titleClass":462,"socialimg":1337,"blogtitlepic":1338,"customExcerpt":1339,"keywords":1340,"maxContent":472},"Vertrouwen opbouwen in Public Key Infrastructure: het PKI-vertrouwensmodel voor certificaten","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Bouw vertrouwen op in de PKI met certificaatketens, Root CA en Intermediate CA, en veilige certificaatvalidatie.","vertrouwen opbouwen PKI, vertrouwen in public key infrastructure, certificaatketen van vertrouwen, vertrouwen in Root CA, vertrouwen in Intermediate CA, PKI-vertrouwensmodel, certificaatvalidatie, vertrouwde rootcertificaten, veilige certificaatverificatie, verificatie van de vertrouwensketen","/glossary/public-key-infrastructure",{"title":1111,"description":434},"glossary/public-key-infrastructure","oWAqpYH5zir1iEiLGXV-cJhZEpXCvyivAbxAX6GOjqA",{"id":1346,"title":1347,"author":142,"body":1348,"cta":142,"description":434,"eventid":142,"extension":457,"hideInRecent":458,"layout":459,"meta":1787,"moment":142,"navigation":472,"path":1793,"seo":1794,"stem":1795,"tags":142,"webcast":458,"__hash__":1796},"content_nl/glossary/use-cases-for-certificates.md","Gebruiksscenario's voor certificaten",{"type":144,"value":1349,"toc":1772},[1350,1354,1358,1372,1376,1408,1412,1443,1447,1453,1459,1463,1516,1520,1524,1538,1542,1554,1558,1561,1575,1579,1585,1596,1601,1612,1618,1629,1633,1653,1657,1660,1664,1684,1688,1705,1710,1730,1734,1737,1769],[147,1351,1353],{"id":1352},"transport-layer-security-tls","Transport Layer Security (TLS)",[164,1355,1357],{"id":1356},"welke-twee-vragen-moet-een-client-stellen-bij-ontvangst-van-een-certificaat-van-een-server","Welke twee vragen moet een client stellen bij ontvangst van een certificaat van een server?",[257,1359,1360,1366],{},[174,1361,1362,1365],{},[156,1363,1364],{},"Is het certificaat geldig en wordt het vertrouwd?"," De client moet verifiëren dat het certificaat is uitgegeven door een vertrouwde certificaatautoriteit (CA) en dat het niet is verlopen of ingetrokken. Daarbij controleert hij de geldigheidsduur van het certificaat en stelt hij vast dat het is ondertekend door een CA die de client vertrouwt.",[174,1367,1368,1371],{},[156,1369,1370],{},"Komt het certificaat overeen met de identiteit van de server?"," De client moet vaststellen dat de gegevens in het certificaat, zoals de Common Name (CN) of de Subject Alternative Name (SAN), overeenkomen met de domeinnaam van de server. Dat helpt bevestigen dat het certificaat inderdaad bedoeld is voor de server waarmee de client verbinding probeert te maken.",[164,1373,1375],{"id":1374},"hoe-valideert-de-client-dat-een-certificaat-te-vertrouwen-is","Hoe valideert de client dat een certificaat te vertrouwen is?",[257,1377,1378,1384,1390,1396,1402],{},[174,1379,1380,1383],{},[156,1381,1382],{},"De certificaatketen van vertrouwen controleren:"," de client verifieert de certificaatketen, die bestaat uit het certificaat van de server, eventuele intermediate certificaten en het rootcertificaat. Elk certificaat in de keten moet zijn ondertekend door de eerstvolgende hogere autoriteit, tot uiteindelijk bij een vertrouwd rootcertificaat.",[174,1385,1386,1389],{},[156,1387,1388],{},"De geldigheidsduur van het certificaat verifiëren:"," de client controleert de geldigheidsduur van het certificaat om vast te stellen dat het niet verlopen is en al wel geldig is. Daarbij kijkt hij naar de data “Not Before” en “Not After” in het certificaat.",[174,1391,1392,1395],{},[156,1393,1394],{},"Het certificaat koppelen aan de identiteit van de server:"," de client stelt vast dat de Common Name (CN) of de Subject Alternative Name (SAN) van het certificaat overeenkomt met de domeinnaam van de server. Dat bevestigt dat het certificaat bedoeld is voor de server waarmee de client verbinding maakt.",[174,1397,1398,1401],{},[156,1399,1400],{},"Controleren op intrekking:"," de client controleert of het certificaat is ingetrokken door de Certificate Revocation List (CRL) te raadplegen of het Online Certificate Status Protocol (OCSP) te gebruiken. Een ingetrokken certificaat wordt niet langer vertrouwd.",[174,1403,1404,1407],{},[156,1405,1406],{},"De digitale handtekening verifiëren:"," de client verifieert de digitale handtekening op het certificaat om vast te stellen dat er niet mee is geknoeid. Daarbij controleert hij de cryptografische handtekening tegen de publieke sleutel van de uitgevende CA.",[164,1409,1411],{"id":1410},"hoe-valideert-de-client-dat-de-server-de-echte-eigenaar-van-een-certificaat-is","Hoe valideert de client dat de server de echte eigenaar van een certificaat is?",[257,1413,1414,1420,1426,1432,1438],{},[174,1415,1416,1419],{},[156,1417,1418],{},"Verificatie van de certificaatketen:"," de client verifieert de certificaatketen en stelt vast dat elk certificaat in de keten is ondertekend door een vertrouwde certificaatautoriteit (CA). Die keten begint bij het certificaat van de server en eindigt bij een vertrouwd rootcertificaat.",[174,1421,1422,1425],{},[156,1423,1424],{},"Overeenkomst van de domeinnaam:"," de client controleert of de Common Name (CN) of de Subject Alternative Name (SAN) van het certificaat overeenkomt met de domeinnaam van de server. Zo staat vast dat het certificaat bedoeld is voor de server waarmee de client verbinding maakt.",[174,1427,1428,1431],{},[156,1429,1430],{},"Verificatie van de digitale handtekening:"," de client verifieert de digitale handtekening op het certificaat met de publieke sleutel van de uitgevende CA. Zo staat vast dat er niet met het certificaat is geknoeid en dat het inderdaad door een vertrouwde CA is uitgegeven.",[174,1433,1434,1437],{},[156,1435,1436],{},"Geldigheidsduur van het certificaat:"," de client controleert de geldigheidsduur van het certificaat om vast te stellen dat het op dit moment geldig is en niet verlopen.",[174,1439,1440,1401],{},[156,1441,1442],{},"Controle van de intrekkingsstatus:",[164,1444,1446],{"id":1445},"waarom-is-eigendom-belangrijk-als-je-al-hebt-gecontroleerd-dat-het-certificaat-wordt-vertrouwd","Waarom is eigendom belangrijk als je al hebt gecontroleerd dat het certificaat wordt vertrouwd?",[152,1448,1449,1452],{},[156,1450,1451],{},"Geldigheid en vertrouwen van het certificaat:"," deze stap stelt vast dat het certificaat is uitgegeven door een vertrouwde certificaatautoriteit (CA), dat het binnen zijn geldigheidsduur valt en dat het niet is ingetrokken. Het bevestigt dat het certificaat legitiem is en dat er niet mee is geknoeid.",[152,1454,1455,1458],{},[156,1456,1457],{},"Verificatie van de serveridentiteit:"," ook als een certificaat geldig is en wordt vertrouwd, moet worden bevestigd dat het hoort bij de server waarmee je verbinding maakt. Daarbij wordt gecontroleerd of de Common Name (CN) of de Subject Alternative Name (SAN) van het certificaat overeenkomt met de domeinnaam van de server. Deze stap stelt vast dat het certificaat bedoeld is voor die specifieke server, en voorkomt man-in-the-middle-aanvallen waarbij een aanvaller een geldig certificaat voor een ander domein presenteert.",[164,1460,1462],{"id":1461},"met-welke-twee-methoden-beantwoordt-de-client-deze-vraag-en-welke-twee-uitkomsten-leveren-die-op","Met welke twee methoden beantwoordt de client deze vraag en welke twee uitkomsten leveren die op?",[257,1464,1465,1492],{},[174,1466,1467,1470,1471,1474,1477,1478],{},[156,1468,1469],{},"Verificatie via het Domain Name System (DNS):"," de client controleert of de Common Name (CN) of de Subject Alternative Name (SAN) van het certificaat overeenkomt met de domeinnaam van de server. ",[1472,1473],"br",{},[156,1475,1476],{},"Uitkomst",":",[171,1479,1480,1486],{},[174,1481,1482,1485],{},[156,1483,1484],{},"Overeenkomst",": komen de namen overeen, dan kan de client de verbinding voortzetten in de zekerheid dat het certificaat voor die server bedoeld is. ",[174,1487,1488,1491],{},[156,1489,1490],{},"Geen overeenkomst",": komen de namen niet overeen, dan zal de client de verbinding waarschijnlijk verbreken of een waarschuwing tonen die op een mogelijk beveiligingsrisico wijst.",[174,1493,1494,1497,1498,1500,1477,1502],{},[156,1495,1496],{},"Verificatie via de public key infrastructure (PKI):"," de client verifieert de digitale handtekening op het certificaat met de publieke sleutel van de uitgevende certificaatautoriteit (CA). ",[1472,1499],{},[156,1501,1476],{},[171,1503,1504,1510],{},[174,1505,1506,1509],{},[156,1507,1508],{},"Geldige handtekening",": is de handtekening geldig, dan bevestigt dat dat er niet met het certificaat is geknoeid en dat het door een vertrouwde CA is uitgegeven.",[174,1511,1512,1515],{},[156,1513,1514],{},"Ongeldige handtekening:"," is de handtekening ongeldig, dan verbreekt de client de verbinding of toont hij een waarschuwing dat het certificaat mogelijk gecompromitteerd of frauduleus is.",[164,1517,1519],{"id":1518},"wat-bepaalt-welke-methode-wordt-gebruikt","Wat bepaalt welke methode wordt gebruikt?",[152,1521,1522],{},[156,1523,1469],{},[171,1525,1526,1532],{},[174,1527,1528,1531],{},[156,1529,1530],{},"Gebruik",": deze methode wordt altijd toegepast als onderdeel van de TLS-handshake. De client vergelijkt de Common Name (CN) of de Subject Alternative Name (SAN) van het certificaat met de domeinnaam van de server om vast te stellen dat ze overeenkomen.",[174,1533,1534,1537],{},[156,1535,1536],{},"Bepalende factoren:"," dit is een standaardonderdeel van het TLS-protocol en wordt automatisch door de client uitgevoerd bij het opzetten van een veilige verbinding.",[152,1539,1540],{},[156,1541,1496],{},[171,1543,1544,1549],{},[174,1545,1546,1548],{},[156,1547,1530],{},": ook deze methode wordt altijd toegepast tijdens de TLS-handshake. De client verifieert de digitale handtekening op het certificaat met de publieke sleutel van de uitgevende certificaatautoriteit (CA).",[174,1550,1551,1553],{},[156,1552,1536],{}," dit is eveneens een standaardonderdeel van het TLS-protocol. De client voert deze controle automatisch uit om vast te stellen dat het certificaat geldig is en dat er niet mee is geknoeid.",[147,1555,1557],{"id":1556},"welke-certificaten-moet-de-server-naar-de-client-sturen","Welke certificaten moet de server naar de client sturen?",[152,1559,1560],{},"Tijdens de TLS-handshake moet de server de volgende certificaten naar de client sturen:",[171,1562,1563,1569],{},[174,1564,1565,1568],{},[156,1566,1567],{},"Eindentiteitscertificaat:"," dit is het eigen certificaat van de server, waarmee hij zijn identiteit aan de client bewijst.",[174,1570,1571,1574],{},[156,1572,1573],{},"Intermediate certificaten:"," deze certificaten verbinden het eindentiteitscertificaat met het vertrouwde rootcertificaat. Ze helpen een vertrouwensketen op te bouwen van het certificaat van de server terug naar een vertrouwd rootcertificaat.",[147,1576,1578],{"id":1577},"wat-zijn-domain-validation-en-extended-validation-certificaten","Wat zijn Domain Validation- en Extended Validation-certificaten?",[152,1580,1581,1584],{},[156,1582,1583],{},"Domain Validation-certificaten (DV)"," zijn een type TLS-certificaat waarbij de certificaatautoriteit (CA) verifieert dat de aanvrager zeggenschap heeft over het domein. Dat gebeurt doorgaans zo:",[171,1586,1587,1590,1593],{},[174,1588,1589],{},"Reageren op een e-mail aan het administratieve contact van het domein.",[174,1591,1592],{},"Een DNS TXT-record toevoegen.",[174,1594,1595],{},"Een bestand naar de webserver uploaden.",[152,1597,1598],{},[156,1599,1600],{},"Belangrijkste kenmerken:",[171,1602,1603,1606,1609],{},[174,1604,1605],{},"Snelle uitgifte: ze kunnen snel worden uitgegeven, vaak binnen enkele minuten, omdat er minimale validatie voor nodig is.",[174,1607,1608],{},"Basisbeveiliging: ze bieden versleuteling en een basiszekerheid dat het domein in handen is van de partij die het certificaat aanvraagt.",[174,1610,1611],{},"Kostenefficiënt: vaak goedkoper of zelfs gratis, waardoor ze toegankelijk zijn voor kleine websites en persoonlijke projecten.",[152,1613,1614,1617],{},[156,1615,1616],{},"Extended Validation-certificaten (EV)"," zijn TLS-certificaten van een hoger niveau, waarvoor een strenger validatieproces geldt. De CA verifieert het juridische, fysieke en operationele bestaan van de partij die het certificaat aanvraagt. Daarbij hoort:",[171,1619,1620,1623,1626],{},[174,1621,1622],{},"De juridische identiteit en status van de partij bevestigen.",[174,1624,1625],{},"De fysieke en operationele aanwezigheid van de partij verifiëren.",[174,1627,1628],{},"Vaststellen dat de partij exclusieve rechten heeft om het domein te gebruiken.",[152,1630,1631],{},[156,1632,1600],{},[171,1634,1635,1641,1647],{},[174,1636,1637,1640],{},[156,1638,1639],{},"Hoge zekerheid:"," biedt gebruikers het hoogste niveau van vertrouwen en zekerheid, omdat er grondig wordt getoetst.",[174,1642,1643,1646],{},[156,1644,1645],{},"Zichtbare indicatoren:"," in sommige browsers toonden EV-certificaten vroeger de naam van de organisatie in de adresbalk, al komt dat nu minder vaak voor.",[174,1648,1649,1652],{},[156,1650,1651],{},"Extra vertrouwen:"," ideaal voor websites die gevoelige informatie verwerken, zoals financiële instellingen en e-commercesites.",[164,1654,1656],{"id":1655},"welke-zijn-veiliger"," Welke zijn veiliger?",[152,1658,1659],{},"Extended Validation-certificaten (EV) gelden over het algemeen als veiliger dan Domain Validation-certificaten (DV), vanwege het strenge validatieproces dat ze doorlopen. Hier volgt een vergelijking:",[152,1661,1662],{},[156,1663,1583],{},[171,1665,1666,1672,1678],{},[174,1667,1668,1671],{},[156,1669,1670],{},"Validatieniveau:"," verifieert alleen de zeggenschap over het domein.",[174,1673,1674,1677],{},[156,1675,1676],{},"Beveiliging:"," biedt basisversleuteling en basiszekerheid.",[174,1679,1680,1683],{},[156,1681,1682],{},"Gebruiksscenario:"," geschikt voor persoonlijke websites, blogs en kleine bedrijven.",[152,1685,1686],{},[156,1687,1616],{},[171,1689,1690,1695,1700],{},[174,1691,1692,1694],{},[156,1693,1670],{}," verifieert het juridische, fysieke en operationele bestaan van de partij.",[174,1696,1697,1699],{},[156,1698,1676],{}," biedt een hoger niveau van vertrouwen en zekerheid dankzij grondige toetsing.",[174,1701,1702,1704],{},[156,1703,1682],{}," ideaal voor financiële instellingen, e-commercesites en elke website die gevoelige informatie verwerkt.",[152,1706,1707],{},[156,1708,1709],{},"Waarom EV-certificaten veiliger zijn:",[171,1711,1712,1718,1724],{},[174,1713,1714,1717],{},[156,1715,1716],{},"Grondige toetsing:"," EV-certificaten vergen uitgebreide validatie, waardoor het lastiger is voor kwaadwillende partijen om ze te bemachtigen.",[174,1719,1720,1723],{},[156,1721,1722],{},"Vertrouwensindicatoren:"," hoewel het nu minder vaak voorkomt, toonden EV-certificaten vroeger de naam van de organisatie in de adresbalk van de browser, wat gebruikers zichtbare zekerheid gaf.",[174,1725,1726,1729],{},[156,1727,1728],{},"Meer zekerheid:"," het gedetailleerde verificatieproces borgt dat de partij achter het certificaat legitiem is, wat het risico op phishing en andere aanvallen verkleint.",[147,1731,1733],{"id":1732},"hoe-verloopt-intrekking-met-ocsp-stapling","Hoe verloopt intrekking met OCSP-stapling",[152,1735,1736],{},"OCSP-stapling verbetert het standaard-OCSP-proces door latency te verlagen en de privacy te vergroten. Zo werkt het:",[257,1738,1739,1745,1751,1757,1763],{},[174,1740,1741,1744],{},[156,1742,1743],{},"De server vraagt een OCSP-response op:"," de webserver vraagt periodiek de intrekkingsstatus van zijn certificaat op bij de OCSP-responder, een server die wordt beheerd door de certificaatautoriteit (CA). Dat gebeurt op de achtergrond en niet bij elke clientverbinding.",[174,1746,1747,1750],{},[156,1748,1749],{},"De OCSP-responder levert een response:"," de OCSP-responder stuurt een ondertekende OCSP-response met tijdstempel terug die de status van het certificaat aangeeft, bijvoorbeeld “good”, “revoked” of “unknown”. De server cachet die response.",[174,1752,1753,1756],{},[156,1754,1755],{},"TLS-handshake met gestapelde response:"," wanneer een client, bijvoorbeeld een webbrowser, een verbinding met de server opzet, voegt de server de gecachete OCSP-response toe aan de TLS-handshake. Dat heet het “staplen” van de response aan de handshake.",[174,1758,1759,1762],{},[156,1760,1761],{},"De client verifieert de OCSP-response:"," de client verifieert de gestapelde OCSP-response. Omdat de response door de CA is ondertekend, kan de client op de geldigheid ervan vertrouwen. Geeft de response aan dat het certificaat is ingetrokken, dan brengt de client geen veilige verbinding tot stand.",[174,1764,1765,1768],{},[156,1766,1767],{},"Periodieke updates:"," de server blijft zijn gecachete OCSP-response periodiek bijwerken, zodat hij tijdens de TLS-handshake altijd een actuele status kan leveren.",[152,1770,1771],{},"Dit proces beperkt de noodzaak voor clients om afzonderlijke OCSP-requests te doen, wat de prestaties en de privacy ten goede komt.",{"title":434,"searchDepth":435,"depth":435,"links":1773},[1774,1782,1783,1786],{"id":1352,"depth":435,"text":1353,"children":1775},[1776,1777,1778,1779,1780,1781],{"id":1356,"depth":440,"text":1357},{"id":1374,"depth":440,"text":1375},{"id":1410,"depth":440,"text":1411},{"id":1445,"depth":440,"text":1446},{"id":1461,"depth":440,"text":1462},{"id":1518,"depth":440,"text":1519},{"id":1556,"depth":435,"text":1557},{"id":1577,"depth":435,"text":1578,"children":1784},[1785],{"id":1655,"depth":440,"text":1656},{"id":1732,"depth":435,"text":1733},{"lang":461,"seoTitle":1788,"titleClass":462,"socialimg":1789,"blogtitlepic":1790,"customExcerpt":1791,"keywords":1792,"maxContent":472},"Transport Layer Security (TLS): gebruiksscenario's en validatie van certificaten","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Bescherm je website en je gebruikers met TLS-certificaten die servers verifiëren, vertrouwen opbouwen via certificaatketens en veilige, versleutelde verbindingen borgen.","TLS-certificaten, Transport Layer Security, gebruiksscenario's voor certificaten, validatie van TLS-certificaten, certificaatketen van vertrouwen, DV-certificaten, EV-certificaten, serverauthenticatie, veilige verbindingen, OCSP-stapling","/glossary/use-cases-for-certificates",{"title":1347,"description":434},"glossary/use-cases-for-certificates","iEeGv8v6D1-fzYTO6dveWJakY1Pyb7GFi4wCQvglsJY",{"list":138,"authors":142},1790098990063]