https://developers.wiki.kennisnet.nl/api.php?action=feedcontributions&user=Klein01&feedformat=atomKennisnet Developers Documentatie - Gebruikersbijdragen [nl]2024-03-19T07:01:43ZGebruikersbijdragenMediaWiki 1.35.13https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/versleuteling_bsn&diff=10985OSO:2018/beveiliging/versleuteling bsn2021-06-21T10:54:09Z<p>Klein01: Versie 10971 van Klein01 (overleg) ongedaan gemaakt</p>
<hr />
<div>=== Versleuteling persoonsgebonden nummer (de zoeksleutel) ===<br />
<br />
In het onderwijs wordt een persoonsgebonden nummer (PGN) gebruikt, meestal het BSN. In sommige gevallen hebben leerlingen (nog) geen BSN, bijvoorbeeld asielzoekers of leerlingen die niet in Nederland wonen. In dit geval krijgen ze een tijdelijk onderwijsnummer. <br />
<br />
In [http://wetten.overheid.nl/BWBR0002399/2016-01-18#TiteldeelI_Artikel1 dit stuk] van de wet staat:<br />
<br />
'''persoonsgebonden nummer (PGN):'''<br />
<br />
het ''burgerservicenummer (BSN)'', bedoeld in [http://wetten.overheid.nl/BWBR0022428/2014-01-06#Hoofdstuk1_Artikel1 artikel 1, onder b, van de Wet algemene bepalingen burgerservicenummer], dan wel het door Onze Minister uitgegeven ''onderwijsnummer'', bedoeld in [http://wetten.overheid.nl/BWBR0002399/2016-01-18#TiteldeelII_AfdelingI_HoofdstukI_Paragraaf1_Artikel27b artikel 27b, vierde lid]<br />
<br />
<br />
Een BSN moet voldoen aan een variant op de 11-proef. Het bsn kan op de volgende wijze gecontroleerd worden: (9*p1 + 8*p2 + 7*p3 + 6*p4 + 5*p5 + 4*p6 + 3*p7 + 2*p8 - p9) MOD11 = 0.<br />
<br />
Een onderwijsnummer moet ook voldoen aan een variant op de 11-proef. Het onderwijsnummer kan op de volgende wijze gecontroleerd worden: (9*p1 + 8*p2 + 7*p3 + 6*p4 + 5*p5 + 4*p6 + 3*p7+ 2*p8) MOD11 = p9 + 5.<br />
Het onderwijsnummer begint altijd met een 1.<br />
<br />
In de Overstapservice is het niet toegestaan om het PGN te versturen naar het Traffic Center. Daarom bevatten interacties met het Traffic Center nooit het PGN, maar een afgeleide identificatie, de zoeksleutel genaamd.<br />
De zoeksleutel wordt afgeleid uit het PGN van de leerling. Om te voorkomen dat onbevoegden deze zoeksleutel weer tot het PGN kunnen herleiden is de zoeksleutel altijd asymmetrisch versleuteld. De versleuteling is gebaseerd op het [http://www.kennislink.nl/publicaties/encryptie-rsa-en-mceliece RSA algoritme] en er wordt dus gebruik gemaakt van een sleutelpaar. Er is een publieke sleutel welke bekend is bij elke leverancier en een privé sleutel welke alleen bekend is bij Kennisnet. Kennisnet kan de zoeksleutel ontsleutelen tot het PGN om te kunnen voldoen aan de zorgplicht (=> waar is een leerling heen gegaan?). Leveranciers kunnen de publieke sleutel verkrijgen bij [mailto:oso-support@kennisnetsupport.nl OSO-support].<br />
<br />
De zoeksleutel is de versleutelde combinatie van het prefix van 4 cijfers en het PGN van 9 cijfers.<br />
<br />
{| class="wikitable"<br />
! typenummer/prefix<br />
! betekenis<br />
|-<br />
| 2318<br />
| dit typenummergeeft aan dat het om een burgerservicenummer (BSN) gaat.<br />
Een voorbeeld van een BSN is 173999529. <br />
Het getal 2318173999529 moet versleuteld worden tot de zoeksleutel.<br />
|-<br />
| 3872 <br />
| dit typenummer geeft aan dat het om een tijdelijk onderwijsnummer gaat.<br />
Een voorbeeld van een onderwijsnummer is 101211151.<br />
Het getal 3872101211151 moet versleuteld worden tot de zoeksleutel.<br />
|}<br />
<br />
Voorbeeld: leerling heeft BSN 111222333, dan moet de combinatie 2318111222333 versleuteld worden tot zoeksleutel.<br />
<br />
Hieronder volgt een voorbeeld van een (nep) RSA publieke sleutel.<br />
<syntaxhighlight lang="xml" enclose="div"><br />
<RSAKeyValue><br />
<Modulus>0EVKqqr5JyI4tYnOO1sDbazqyJY78rpBcvrcmbimjRkcwkpQ1knwVKURccH5oaSdhaXptg+9QcBqbC0p3SLym7f3hyeLCJvxNEV4JPZ7L5GbnsC8Ux5HxLinW/B6mF8jMYh5du5X7OKytNA2qlGdwe7qM</Modulus><br />
<Exponent>AQA2</Exponent><br />
</RSAKeyValue><br />
</syntaxhighlight><br />
<br />
De uitkomst van de versleuteling is de zoeksleutel. Deze sleutel wordt in het overdrachtsrequest meegestuurd. Bijvoorbeeld:<br />
<br />
<syntaxhighlight lang="xml" enclose="div"><br />
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://xml.eld.nl/schemas/Overstapservice/VERSIENUMMER"><br />
<soapenv:Header/><br />
<soapenv:Body><br />
<ns:overdrachtRequest><br />
<ns:bronBrin>00YY</ns:bronBrin><br />
<ns:bronAanleverpuntIndex>0</ns:bronAanleverpuntIndex><br />
<ns:doelBrin>00YY</ns:doelBrin><br />
<ns:doelAanleverpuntIndex>102</ns:doelAanleverpuntIndex><br />
<ns:zoeksleutel>xz/Zn95R9aSdJ/BeNSQs231pogl9evDlUO8NIuAEKhfHWjV...dT4BA7MkT3EBuYUEtPcRtBXY=</ns:zoeksleutel><br />
<ns:overdrachtsoort>overdrachtbinnenbrin</ns:overdrachtsoort><br />
</ns:overdrachtRequest><br />
</soapenv:Body><br />
</soapenv:Envelope><br />
</syntaxhighlight><br />
<br />
{{Info|De zoeksleutel moet base64 encoded worden doorgegeven in het overdrachtsrequest en in het sessiecontrolerequest. In OSO moet hiervoor de 'standaard' Base64 content-transfer-encoding (zoals beschreven in RFC 4648, hoofdstuk 4), worden toegepast. NB: Deze encoding wijkt af van die toegepast in bijlagen(!).}}<br />
{{Info|Een bronsysteem moet ervoor zorgen dat de zoeksleutel zoals deze wordt ontvangen van het doelsysteem wordt doorgegeven aan het TC. Er mogen GEEN bewerkingen of conversies toe worden gepast op de inhoud op het formaat van de zoeksleutel om te voorkomen dat het TC de sessie onterecht ongeldig verklaard.}}<br />
<br />
<br />
<br />
<br />
[[Category:Book OSO|821]]<br />
[[Categorie:Overstapservice Onderwijs]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/Beveiliging/FAQ&diff=10984OSO:2017/Beveiliging/FAQ2021-06-21T10:53:25Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/client_authentication_windows&diff=10983OSO:2017/beveiliging/client authentication windows2021-06-21T10:53:17Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2016/Wijzigingen_in_PKI_Infrastructuur_OSO%2716&diff=10982OSO:2016/Wijzigingen in PKI Infrastructuur OSO'162021-06-21T10:52:56Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging&diff=10981OSO:2018/beveiliging2021-06-21T10:52:05Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/FAQ&diff=10980OSO:2018/beveiliging/FAQ2021-06-21T10:51:54Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/geldigheid&diff=10979OSO:2018/beveiliging/geldigheid2021-06-21T10:51:49Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/Procedure_bij_(vermoeden_van)_misbruik&diff=10978OSO:2018/beveiliging/Procedure bij (vermoeden van) misbruik2021-06-21T10:51:44Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/controle_procedure&diff=10977OSO:2018/beveiliging/controle procedure2021-06-21T10:51:38Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/informatiebeveiliging_per_interactie&diff=10976OSO:2018/beveiliging/informatiebeveiliging per interactie2021-06-21T10:51:32Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/protocollen&diff=10975OSO:2018/beveiliging/protocollen2021-06-21T10:51:24Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/certificaat_validatie&diff=10974OSO:2018/beveiliging/certificaat validatie2021-06-21T10:51:18Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/client_certificaten&diff=10973OSO:2018/beveiliging/client certificaten2021-06-21T10:51:12Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/certificaten_webservice&diff=10972OSO:2018/beveiliging/certificaten webservice2021-06-21T10:51:08Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/versleuteling_bsn&diff=10971OSO:2018/beveiliging/versleuteling bsn2021-06-21T10:51:03Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/opzet_paginas&diff=10970OSO:2018/beveiliging/opzet paginas2021-06-21T10:50:59Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/scope&diff=10969OSO:2018/beveiliging/scope2021-06-21T10:50:53Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2018/beveiliging/uitgangspunten&diff=10968OSO:2018/beveiliging/uitgangspunten2021-06-21T10:50:46Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging&diff=10967OSO:2017/beveiliging2021-06-21T10:50:04Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/geldigheid&diff=10966OSO:2017/beveiliging/geldigheid2021-06-21T10:49:53Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/Procedure_bij_(vermoeden_van)_misbruik&diff=10965OSO:2017/beveiliging/Procedure bij (vermoeden van) misbruik2021-06-21T10:49:47Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/controle_procedure&diff=10964OSO:2017/beveiliging/controle procedure2021-06-21T10:49:40Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/informatiebeveiliging_per_interactie&diff=10963OSO:2017/beveiliging/informatiebeveiliging per interactie2021-06-21T10:49:35Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/protocollen&diff=10962OSO:2017/beveiliging/protocollen2021-06-21T10:49:27Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/certificaat_validatie&diff=10961OSO:2017/beveiliging/certificaat validatie2021-06-21T10:49:22Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/client_certificaten&diff=10960OSO:2017/beveiliging/client certificaten2021-06-21T10:49:18Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/certificaten_webservice&diff=10959OSO:2017/beveiliging/certificaten webservice2021-06-21T10:49:13Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/versleuteling_bsn&diff=10958OSO:2017/beveiliging/versleuteling bsn2021-06-21T10:49:08Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/opzet_paginas&diff=10957OSO:2017/beveiliging/opzet paginas2021-06-21T10:49:03Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/scope&diff=10956OSO:2017/beveiliging/scope2021-06-21T10:48:57Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=OSO:2017/beveiliging/uitgangspunten&diff=10955OSO:2017/beveiliging/uitgangspunten2021-06-21T10:48:51Z<p>Klein01: De pagina is leeggehaald</p>
<hr />
<div></div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/controle_procedure&diff=10954Standaarden:Beveiligd Gegevenstransport/controle procedure2021-06-21T10:46:14Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
== Controle procedure naleving beveiligingseisen ==<br />
De implementatie engineer bij Kennisnet zal naleving van de in het PvE genoemde eisen controleren. Deze controle bestaat uit de jaarlijkse kwalificatie na oplevering van de nieuwe functionaliteiten en eisen, ontwikkeld voor een specifieke keten. Daarnaast zal de implementatie engineer periodiek steekproeven houden om de kwaliteit van de keten te waarborgen.<br/><br />
Deze tests verlopen middels voorgeschreven scripts, waardoor er een uniforme controle uitgevoerd kan worden.<br />
<br />
De testprocedure bestaat uit minimaal een:<br />
* Functionele test: werkt de koppeling tussen LAS en TC en tussen LAS en LAS zoals voorgeschreven<br />
* Technische test: worden alle beveiligingseisen zoals opgenomen op deze wiki daadwerkelijk correct uitgevoerd<br />
<br />
=== Technische test ===<br />
In hoofdlijnen opgesomd wat er binnen de technische test gecheckt wordt:<br />
* Klopt het server certificaat van het systeem waarop het aanleverpunt wordt aangeboden?<br />
** Is het certificaat nog geldig?<br />
** Komt servername in het certificaat overeen met de domeinnaam in de url?<br />
** Is het certificaat en de certificaatketen te valideren tegen het root CA certificaat?<br />
** Is het certificaat niet ingetrokken (revoked) door de CA?<br />
** Welke hash signatuur wordt er gebruikt?<br />
* Wordt SNI gesupport?<br />
* Wat voor private key wordt er gebruikt en met welke sleutellengte?<br />
* Geeft de server aan in de TLS handshake of deze bepaalde client certificaten verwacht?<br />
* Ondersteunt de server 'secure renegotiation'?<br />
* Ondersteunt de server 'secure client-initiated renegotiation'?<br />
* Ondersteunt de server 'insecure client-initiated renegotiation'?<br />
* Ondersteunt de server OCSP stapling?<br />
* Ondersteunt de server serverside cipher ordering?<br />
* Ondersteunt de server TLS compression?<br />
* Ondersteunt de server session resumption caching?<br />
* Ondersteunt de server session resumption tickets?<br />
* Ondersteunt de server SCSV fallback?<br />
* Ondersteunt de server HSTS?<br />
* Is de server vatbaar voor de CCS vulnerability?<br />
* Is de server vatbaar voor TLS poodle?<br />
* Is de server vatbaar voor Heartbleed?<br />
* Accepteert de server alleen de voor de keten geaccepteerde client certificaten?<br />
** Test met een PKIoverheid certificaat<br />
** Test met een random ander client certificaat verkregen uit een legitieme CA in de markt<br />
** Test met een self-signed certificaat<br />
* Welke TLS/SSL protocollen ondersteunt de server?<br />
* Welke ciphersuites ondersteunt de server?<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/protocollen&diff=10953Standaarden:Beveiligd Gegevenstransport/protocollen2021-06-21T10:46:04Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
== HTTPS ==<br />
==== Eisen ====<br />
* Er '''moet''' gebruik gemaakt worden van HTTPS<br />
* Er '''moet''' gebruik gemaakt worden van een Fully Qualified Domain Name<br />
* Er '''moet''' gebruik gemaakt worden van TCP port 443<br />
* Er '''mag geen''' gebruik gemaakt worden van redirects die vanaf http (port 80) redirecten naar https (port 443).<br />
==== Verklaring ====<br />
De verbindingen binnen de keten moeten van A tot Z beveiligd verlopen, hiervoor wordt HTTPS gebruikt. Om betrouwbaar te communiceren met partijen hebben deze een server certificaat nodig welke deze in de markt aanschaffen. Dit certificaat bevat de, of meerdere, domeinnaam of -namen. De betrouwbaarheid wordt vergroot door alleen gebruik te maken van volledige en traceerbare domeinnamen, Fully Qualified Domain Names (FQDN). HTTPS is door het IANA gestandaardiseerd op port 443, waar bij elke keten dan ook gebruik van wordt gemaakt. Hiervan mag om compatibiliteitsredenen niet afgeweken worden.<br/><br />
Er mag geen redirect beschikbaar zijn welke de webservice calls redirect vanaf port 80 naar port 443. Als er op dezelfde host zowel http als https beschikbaar is, moet er een foutmelding teruggegeven worden als er webservice calls op http binnenkomen.<br />
400 Bad Request<br />
Plain text http not supported, use https.<br />
<br />
De reden hiervoor is dat een call over http direct al payload bevat waar datalekken risicovol kunnen zijn. Om te voorkomen dat verkeerd geconfigureerde clients toch kunnen doorgaan met het gebruik maken van deze onveilige redirect functie, mag er helemaal geen redirect gedaan worden. De client is hierdoor gedwongen zijn configuratie aan te passen.<br />
<br />
== HSTS ==<br />
==== Eisen ====<br />
* Het gebruik van de [https://nl.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS] HTTP header is '''niet verplicht'''<br />
* De maatregelen die door HSTS worden voorgeschreven, worden al expliciet vereist in andere delen van het de eisen<br />
==== Verklaring ====<br />
HSTS wordt alleen gebruikt door webbrowsers, waardoor verplichte implementatie en validatie niet het gewenste effect zal opleveren. Echter, de meeste eisen die HSTS oplegt worden al door het PvE afgedekt.<br />
<br />
== TLS ==<br />
=== Versie ===<br />
==== Eisen ====<br />
* TLSv1.2 '''moet''' ondersteund worden. TLSv1.3 '''mag''' ondersteund worden<br />
* Lagere TLS versies '''mogen niet''' ondersteund worden<br />
* Aan deze eis '''moet''' aan zowel de vragende (client) als wel de leverende (server) kant binnen de keten voldaan worden<br />
<br />
==== Verklaring ====<br />
TLSv1.3 en TLSv1.2 zijn de beste protocollen beschikbaar om communicatie tussen publieke http based webservices te beveiligen. SSLv2 en SSLv3 zijn al langere tijd niet meer veilig, echter zal dit ook [https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf niet lang meer duren] voor TLSv1.<br/><br />
De belangrijkste voordelen van TLSv1.2 en hoger boven TLSv1.1 zijn dat er in v1.2 een flink aantal [https://www.wolfssl.com/wolfSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html verbeteringen] zijn doorgevoerd in de hashing functies, de requirements binnen het protocol een stuk strakker zijn gemaakt en er een aantal sterke AES gebaseerde ciphers bij zijn gekomen die meteen gebruikt worden binnen de keten. In TLS1.3 is daarnaast afscheid genomen van veel verouderde ciphers. Waar TLSv1.2 nog backward compatible is gehouden, is dit voor TLSv1.3 niet meer zo.<br/><br />
Zowel de client als server moeten aan dezelfde TLS specificaties voldoen om te voorkomen dat een [https://nl.wikipedia.org/wiki/Man-in-the-middle-aanval Man in the Middle] aanval kan slagen door gebruik te maken van zwaktes aan een van beider zijden.<br />
<br />
==== Mogelijke oplossing ====<br />
'''Serverside'''<br />
* De webserver staat in de configuratie van de webserver (bijvoorbeeld IIS of Apache) bij TLS alleen TLSv1.2 toe, waardoor clients met andere versies nooit een verbinding kunnen opzetten<br />
<br />
=== Ciphersuites en PFS ===<br />
==== Eisen ====<br />
Kennisnet ondersteunt alleen de volgende ciphersuites (IANA naamgeving):<br />
# 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384<br />
# 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256<br />
# 0xC0,0x28 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384<br />
# 0xC0,0x27 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256<br />
# 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256<br />
<br/><br />
<br />
Kennisnet ondersteunt voor DHE '''alleen''' de voorgedefinieerde DHE groepen uit [https://tools.ietf.org/html/rfc7919 RFC 7919].<br/><br />
Als een systeem DHE hanteert moet deze ondersteuning bieden voor '''minimaal''' 2048bit DHE groepen.<br />
<br />
Ciphersuites welke niet genoemd zijn '''mogen niet''' gebruikt worden.<br />
<br />
==== Verklaring ====<br />
Het gebruik van de in RFC 7919 voorgedefinieerde groepen heeft sterk de voorkeur boven eigen gegenereerde of "built in" ciphers zoals gedefinieerd in RFCs 2409, 3526, of 5114. Bijvoorbeeld Apache t/m 2.2 maakt hier gebruik van. Als eigen parameters niet zijn in te stellen, gebruik dan '''niet''' de DHE ciphers.<br/><br/><br />
Gebruik bij DHE groepen altijd een groep welke tenminste dezelfde lengte heeft als de RSA privésleutel die gebruikt wordt voor het certificaat.<br />
De ciphersuite lijst is gebaseerd op de [https://wiki.mozilla.org/Security/Server_Side_TLS aangeraden configuratie] van de Mozilla Foundation. Alleen de DSS gebaseerde ciphers zijn hier nog uit verwijderd aangezien deze inherent onveilig zijn (max 1024bit).<br/><br/><br />
De ciphersuites welke zijn toegestaan of zelfs verplicht zijn, ondersteunen allen [https://nl.wikipedia.org/wiki/Perfect_forward_secrecy PFS]. Hierdoor zijn de verstuurde versleutelde datastromen ook in de toekomst nog veilig, ook al zou onverhoopt toch een keer ergens een privésleutel uitlekken. Het verschil tussen traditionele versleuteling en "vluchtige" (ephemeral) versleuteling is dat in plaats van 1 sleutel voor alle versleutelde communicatie (de RSA privésleutel), er per communicatiesessie er een nieuwe sleutel (middels [https://www.youtube.com/watch?v=YEBfamv-_do Diffie-Hellman]) wordt gegenereerd. Deze sleutel is alleen geldig zolang deze sessie duurt. Na het verlopen van deze sessie heeft zowel de client als de server de sleutel niet meer en zal eventueel opgeslagen data uit de datastroom vrijwel onmogelijk nog teruggehaald kunnen worden. Ephemeral ciphersuites zijn te herkennen aan de suffix E in ECDHE en DHE.<br />
<br />
Ciphers die niet op de toegestane lijst staan '''mogen niet''' gebruikt worden. Legacy ciphers waarbij gebruik gemaakt wordt van bijvoorbeeld RC4 of 3DES zijn onveilig en als vanzelfsprekend niet toegestaan te gebruiken. Lees meer over de problemen met RC4 en 3DES op respectievelijk in [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2808 CVE-2015-2808] en in [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2183 CVE-2016-2183]<br />
<br />
==== Mogelijke oplossing ====<br />
In Apache 2.4.8 en nieuwer kunnen DHE parameters worden ingeladen.<br />
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"<br />
<br />
In sommige oudere versies van Apache kan ook de inhoud van dhparams.pem toegevoegd worden onderaan in het certificaat bestaand (appenden).<br/><br />
Lees meer voorbeelden op de [https://weakdh.org/sysadmin.html deployment guide]<br />
<br />
=== Cipher volgorde ===<br />
==== Eisen ====<br />
* De server '''moet''' de cipher order bepalen<br />
* De sterkste ciphersuite '''moet''' bovenaan de keuzelijst staan, aflopend naar de 'zwakste' onderaan de lijst<br />
<br />
==== Verklaring ====<br />
De server in een communicatieproces bepaalt uiteindelijk hoe sterk de versleuteling van de verbinding met de client wordt. De server wijst eventueel zelfs de verbinding met de client af als er geen sterke versleuteling tussen beide overeengekomen kan worden. De server moet dan ook garant staan voor de sterkst mogelijke configuratie die binnen de keten nodig wordt geacht.<br />
De server heeft een statische lijst met cipher suites die worden toegestaan en bepaalt hoe deze lijst in onderhandeling met de client wordt afgelopen. De sterkste match tussen server en client moet gekozen worden. <br/><br />
Binnen de keten worden alleen sterke ciphers toegestaan, echter is er ook nog een performance verschil tussen verschillende suites. Dit heeft voor zowel client als server impact, dus ook hier heeft de server, in opvolging van de eisen, invloed op de keuze van de snelste ciphers.<br />
==== Mogelijke oplossing ====<br />
In Apache kan de cipher volgorde geforceerd worden middels<br />
SSLHonorCipherOrder on<br />
In IIS kan dit geregeld worden zoals beschreven in [http://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/ deze guide]<br />
<br />
=== Renegotiation ===<br />
==== Eisen ====<br />
* Secure renegotiation '''moet''' worden ondersteund<br />
* Insecure client-renegotiation '''mag niet''' ondersteund worden<br />
* Secure client-renegotiation '''mag niet''' ondersteund worden<br />
==== Verklaring ====<br />
Heronderhandeling over de TLS parameters mag nooit geïnitieerd worden vanuit de client, alleen vanuit de server. De server bepaalt of en zo ja wanneer dit moet gebeuren.<br />
<br />
=== Compression ===<br />
==== Eisen ====<br />
* TLS compression '''moet''' uitgeschakeld zijn op de server en aan de client kant<br />
==== Verklaring ====<br />
In de meeste TLS modules is dit inmiddels functioneel al uitgeschakeld en daardoor onmogelijk te gebruiken. Mits dit toch bruikbaar is, is het voor een aanvaller mogelijk om achter geheime informatie te komen die versleuteld is in het berichten verkeer.<br />
De precieze werking gaat te diep voor deze wiki, maar is [http://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor hier] terug te lezen.<br />
<br />
=== Sessie hervatting ===<br />
==== Eisen ====<br />
* Sessie hervatting '''mag''' ondersteund worden<br />
* Sessie hervatting '''kan''' extra risico's met zich meebrengen, gebruik het alleen als bewuste keuze!<br />
<br />
==== Verklaring ====<br />
Sessie hervatting heeft als doel een stuk van de TLS handshake over te slaan omdat de sessieparameters aan zowel client als server kant in cache gehouden worden. Verbindingen tussen client en server die veelvuldig geopend en gesloten worden hebben hiermee een performance voordeel. Er dient wel rekening gehouden te worden met cachingtijden en de opslag van deze cache. Op het moment dat de sessie opgeslagen wordt, worden tijdelijke sleutels welke alleen gedurende de lifetime van de sessie bestaan toch gepersisteerd. Hierdoor is het mogelijk dat een derde deze cache op de server of zelfs een shared storage systeem kan uitlezen. Sessiesleutels kunnen hierdoor dan ook alsnog gecompromitteerd worden.<br />
Het veiligst doch traagst is het volledig uitschakelen van sessie hervatting.<br />
<br />
=== ServerNameIndication ===<br />
==== Eisen ====<br />
* ServerNameIndication (SNI) '''moet''' door elk systeem dat acteert als client geïmplementeerd zijn<br />
* ServerNameIndication (SNI) '''mag''' door elk systeem dat acteert als server geïmplementeerd zijn<br />
==== Verklaring ====<br />
Een SSL certificaat wordt geïnstalleerd om een http verbinding te beveiligen. Hierbij wordt de volledige verbinding versleuteld op sessie niveau. Dit vindt plaats nog voordat er middels HTTP uitgewisseld is om welke hostname het gaat. Hierdoor is het voor de webserver onmogelijk om te bepalen voor welke domein het certificaat opgevraagd wordt. De webserver geeft het standaard certificaat of zelfs helemaal geen certificaat terug. <br /><br />
SNI zorgt ervoor dat op sessie niveau, tijdens het opzetten van de versleutelde verbinding, al een extensie wordt meegestuurd met de hostname erin. TLS kan hierdoor bepalen voor welk certificaat een client de verbinding opzet en het juiste certificaat mee terugsturen.<br/><br />
Dit ziet er als hiernaast uit: [[Bestand:Tls-sni.png]]<br/><br />
Elke client moet dit binnen de keten ondersteunen omdat er reeds leveranciers zijn die server-side SNI nodig hebben om het juiste certificaat te kunnen retourneren aan de client.<br />
<br/><br />
Ter illustratie schematisch weergegeven hoe de communicatiestroom er met en zonder SNI uitziet:<br />
<br/>'''Zonder''' SNI:<br />
[[Bestand:Client-server-wo-sni.png]]<br/><br />
<br/>'''Met''' SNI:<br />
[[Bestand:Client-server-sni.png]]<br/><br />
Weblinks over SNI-configuratie<br />
* [https://blogs.msdn.microsoft.com/kaushal/2012/09/04/server-name-indication-sni-with-iis-8-windows-server-2012/ Artikel over het configureren van SNI op IIS 8 (Windows Server 2012)]<br />
* [https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI Artikel over het configureren van SNI op Apache2.x]<br />
<br />
=== Certificate Authorities (issuers) ===<br />
==== Eisen ====<br />
* In de TLS handshake fase is het '''wenselijk''' dat de server naar client een lijst met geaccepteerde CA's (issuers) teruggeeft<br />
==== Verklaring ====<br />
Het is in een communicatieproces wenselijk dat een server richting een client aangeeft wat er van deze wordt verwacht. Binnen TLS bestaat er in de handshake procedure de mogelijkheid de client middels het 'certificate_authorities' veld mee te geven welke certificaat leveranciers geaccepteerd worden als uitgever van het client certificaat. Een client kan hierdoor automatisch in de keystore het gewenste certificaat selecteren of juist vroegtijdig constateren dat het niet over een certificaat beschikt wat de server accepteert. Het veld is echter niet verplicht binnen TLS en zo ook niet voor de partijen binnen de keten.<br />
<br />
Wanneer het veld gevoerd wordt door een server, moet het zich houden aan de [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Leverancier_van_certificaten|lijst van leveranciers]].<br />
<br />
Kennisnet voert voor de keten webservices zelf altijd het 'certificate_authorities' veld in de handshake.<br />
<br />
=== Fallback SCSV (protocol downgrade attack prevention) ===<br />
==== Eisen ====<br />
* Fallback SCSV wordt '''niet''' vereist<br />
==== Verklaring ====<br />
Het gebruik van [https://wiki.openssl.org/index.php/SSL_MODE_SEND_FALLBACK_SCSV Fallback SCSV] is nuttig als er TLS protocol versie downgrades mogelijk zijn naar bijvoorbeeld TLSv1 of SSLv3. Binnen de keten is dit echter niet het geval. Alleen TLSv1.2 wordt toegestaan.<br />
<br />
=== Public key pinning ===<br />
==== Eisen ====<br />
* Public key pinning wordt '''niet''' ondersteund / vereist<br />
==== Verklaring ====<br />
Public key pinning ([https://timtaubert.de/blog/2014/10/http-public-key-pinning-explained/ Public key pinning] / [https://bjornjohansen.no/public-key-pinning Linux Implementatie]) wordt niet ondersteund.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie&diff=10952Standaarden:Beveiligd Gegevenstransport/certificaat validatie2021-06-21T10:45:53Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
== Rijkwijdte ==<br />
De genoemde validatie eisen hebben betrekking op alle voorkomende certificaten in de keten, te weten:<br />
* Client certificaat<br />
* Intermediate CA van het client certificaat, mits deze gebruikt wordt in de keten<br />
* Root CA van het client certificaat<br />
* Server certificaat<br />
* Intermediate CA van het server certificaat<br />
* Root CA van het server certificaat<br />
<br />
== Verloopdatum ==<br />
=== Eisen ===<br />
* Er '''moet''' gecontroleerd worden of de verloopdatum van geen enkel certificaat in de keten verlopen is<br />
* Als een van de certificaten verlopen is, '''moet''' de verbinding direct verbroken worden<br />
=== Verklaring ===<br />
Certificaten hebben een vastgestelde geldigheidsperiode. Ze mogen niet voor en niet na de in het certificaat opgenomen periode gebruikt worden. Zie ook [[OSO:2018/beveiliging/certificaten_webservice#Geldigheidsduur_.28maximale_termijn.29|de eisen]]<br />
<br />
== Intrekkingsstatus ==<br />
=== Eisen ===<br />
* De intrekkingsstatus van een certificaat '''moet''' gecontroleerd worden<br />
* Als een certificaat ingetrokken is '''moet''' direct de verbinding verbroken worden<br />
=== Verklaring ===<br />
Elke keer dat een certificaat geraadpleegd wordt moet gecontroleerd worden of de CA het niet heeft ingetrokken. Dit kan namelijk gebeuren omdat de partij van wie het certificaat is heeft besloten het terug te trekken omdat het een oud certificaat is dat is vervangen. Erger nog is als er iets mis is met deze partij dan wel de CA en dat de situatie niet meer te vertrouwen is, dan kan ook een certificaat worden teruggetrokken.<br/><br />
Ingetrokken certificaten mogen nooit gebruikt worden en zullen ook nooit meer in gebruik genomen worden. Er zal altijd een nieuw certificaat voor in de plaats moeten komen alvorens er weer gecommuniceerd mag worden met de partij van wie het certificaat was.<br />
<br />
== Validatie certificaat keten ==<br />
=== Eisen ===<br />
* Bij elke vorm van beveiligde communicatie '''moet''' altijd de gehele certificaat keten gecontroleerd worden op correct functioneren<br />
=== Verklaring ===<br />
De certificaat keten moet voordat gecommuniceerd wordt altijd worden gecontroleerd. Is het intermediate certificaat wel uitgegeven door een CA in de lokale [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Leveranciers_van_certificaten|truststore]]? Is het certificaat van de wederpartij wel uitgegeven door de door hen meegeleverde CA? [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Certificaat_keten|Zie ook de eisen aan de server]]<br />
<br />
== Certificaat voor de webservice geldig op het aangegeven domein? ==<br />
=== Eisen ===<br />
* Het server certificaat dat uitgegeven is voor een specifiek domein '''moet''' overeenkomen met het domein in de URL. Er '''mag geen''' mismatch zijn tussen het domein waarvoor het certificaat bedoeld is en het domein dat opgevraagd wordt.<br />
* De verbinding '''moet''' direct verbroken worden bij een domein mismatch.<br />
=== Verklaring ===<br />
Het server certificaat is uitgegeven met als doel een specifiek domein te beschermen. Als client is het dan ook de bedoeling alle afwijkingen hierop af te wijzen. Als het domein in het certificaat niet overeenkomt met het domein waar de verbinding mee wordt opgezet, dan moet de verbinding worden afgewezen. Mogelijk is er aan de serverkant van de wederpartij iets mis met de configuratie of in het slechtste geval de verbinding of gehele server gecompromitteerd.<br />
<br />
== Client certificaat geldig binnen de keten? ==<br />
=== Eisen ===<br />
* Het client certificaat dat wordt ontvangen door de webserver wanneer een client zich wil authentiseren met zijn certificaat '''moet''' uitgegeven zijn door de CA of CA's die zijn geaccepteerd als certificaat leverancier binnen de keten.<br />
* De verbinding '''moet''' verbroken worden als het client certificaat niet van een geaccepteerde CA afkomstig is.<br />
=== Verklaring ===<br />
De client certificaten binnen representeren een identiteit waarop vertrouwd moet kunnen worden. Deze identiteit wordt vastgesteld middels een vastomlijnde procedure, waar maar 1 of enkele CA's toe zijn gemachtigd om dit te doen. Op het moment dat een client certificaat is uitgegeven door een andere partij, ontstaat er geen vertrouwensrelatie tussen client en server. De server dient hierop de verbinding te verbreken.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/client_certificaten&diff=10951Standaarden:Beveiligd Gegevenstransport/client certificaten2021-06-21T10:45:40Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
Elke keten maakt gebruik van het "SaaS certificaat". Dit betekent dat voor elke koppeling naar een interface binnen de keten TLS client authenticatie door het softwarepakket nodig is. De school hoeft hiervoor dus niets te doen. De instantie die verantwoordelijk is voor de uitgifte van deze certificaten is [https://pkioverheid.nl/ PKI Overheid]. Een software leverancier die actief is binnen de een keten moet zichzelf voorzien van zo'n certificaat. <br/><br />
Validatie binnen de keten vindt plaats door te checken of:<br />
* Het certificaat is uitgegeven door de correcte CA<br />
* Het certificaat een OIN/HRN bevat dat gewhitelist is voor communicatie binnen de keten<br />
<br />
Elke keten implementeert zijn eigen registratiesysteem waarin alle voor deze keten gekwalificeerde systemen zijn opgenomen. Binnen dit register worden de gekwalificeerde OIN/HRNs opgenomen welke in het PKIo certificaat zijn gepubliceerd. Om in het register gewhitelist te worden dient het aangesloten systeem eerst gekwalificeerd te worden door Kennisnet. In het register wordt de lijst van aangesloten Leveranciers bijgehouden en hun relatie met scholen (via Aanleverpunten).<br />
<br />
== Leverancier van certificaten ==<br />
=== Eisen ===<br />
* Het client certificaat '''moet''' uitgegeven worden door een geaccrediteerd uitgever van "Staat der Nederlanden" certificaten.<br />
* Het client certificaat '''moet''' ondertekend zijn door:<br />
** "Staat der Nederlanden Private Services CA - G1"<br />
** "Staat der Nederlanden Domein Server CA 2020"<br />
* De service die de client certificaat validatie afdwingt '''moet''' exact de 2 bovenstaande certificaat uitgevers accepteren<br />
* De service die de client certificaat validatie afdwingt '''moet''' valideren dat de intermediate CA het client certificaat daadwerkelijk ondertekend heeft<br />
* Het client certificaat '''moet''' een OIN/HRN bevatten, in het veld subject.serialNumber<br />
<br />
=== Verklaring ===<br />
Er zijn [https://www.logius.nl/diensten/pkioverheid/aanschaffen/ een aantal CSP's] die namens de Staat der Nederlanden certificaten mogen uitgeven. Dit zijn commerciële partijen met elk hun eigen aanvraagprocedures en kosten. Het root CA blijft echter altijd "Staat der Nederlanden EV Root CA" of "Staat der Nederlanden Private Root CA - G1". Al deze certificaat ketens moeten worden ondersteund door alle aangesloten systemen. Informatie over deze certificaten is na te lezen op [https://www.logius.nl/standaarden/pkioverheid/certificaten/ de site van Logius].<br/><br />
Elke keten valideert de client certificaten alleen tegen bovengenoemde intermediate certificaten. Onder root CA Staat der Nederlanden worden nog meer typen certificaten uitgegeven dan de door ons gebruikte service certificaten, bijvoorbeeld persoonscertificaten. Deze typen worden binnen deze ketens niet geaccepteerd, dus dat is dan ook de reden om niet tegen het root CA certificaat te valideren, maar tegen een sub certificaat onder Staat der Nederlanden.<br/><br />
Op eerder genoemde site van Logius zijn de kenmerken van de certificaten in te zien en zijn de certificaten zelf ook te downloaden.<br/><br />
<br/><br />
De gebruikte certificaten vallen onder de [https://www.logius.nl/diensten/digikoppeling/ Digikoppeling standaard] en zijn daarmee universeel inzetbaar voor communicatie met steeds meer overheidsdiensten. Meer informatie over de standaardisatie van deze certificaten is [https://www.logius.nl/fileadmin/logius/ns/diensten/digikoppeling/aansluitdocumentatie/Digikoppeling_Gebruik_en_achtergrond_certificaten_v1_4.pdf hier] te lezen. Voor de ketens is het OIN/HRN van belang. Lees met name vanaf pagina 23 door om te begrijpen hoe het OIN/HRN werkt.<br />
<br />
=== Aanvullende informatie betreffende CSPs ===<br />
Let op dat er een servercertificaat van PKIoverheid wordt gekozen. Hierbij moet je ervoor zorgen dat het OIN/HRN ingevuld is. Standaard wordt dit nummer op basis van het KvK-nummer gegenereerd, maar controleer dit goed. Zonder dit nummer is het certificaat niet bruikbaar!!<br/><br />
Het standaard nummer is gebaseerd op het KVK nummer (00000003KvKnummer0000) en heet een HRN. Deze is alleen van toepassing voor bedrijven. Let op dat in geval van bedrijfsfusies, holdingen, etc, het juiste KvK-nummer wordt gebruikt!<br/><br />
Mocht de organisatie geen bedrijf zijn maar een overheidsgerelateerde organisatie, dan dient een OIN aangevraagd te worden. Alle OINs zijn in te zien in het [https://register.digikoppeling.nl/overview/index register]. Het spreekt voor zich dat het OIN bekend moet zijn alvorens het certificaat aangevraagd kan worden.<br/><br/><br />
Lees voor aanvragen bij KPN ook de [https://certificaat.kpn.com/files/overig/kpn-pkioverheid-toelichting-aanvraag-servercertificaat.pdf handleiding] door.<br />
<br />
== Geldigheidsduur ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Geldigheidsduur_.28maximale_termijn.29|certificaten voor de webservice]].<br />
== Sterkte sleutel ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Sterkte_en_type_sleutel|certificaten voor de webservice]].<br />
== Wisselen sleutel ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Wisselen_sleutel|certificaten voor de webservice]].<br />
== Ondertekeningsalgoritme ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Ondertekeningsalgoritme|certificaten voor de webservice]].<br />
== Certificaat keten ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Certificaat_keten|certificaten voor de webservice]].<br />
== Gebruik van het certificaat ==<br />
Het door PKI Overheid uitgegeven certificaat wordt alleen gebruikt op de Kwalificatie- en Productie omgeving. Op de Sandbox omgeving worden certificaten gebruikt die nog wel door Kennisnet worden gegenereerd, maar verder geen enkele geldigheid op andere omgevingen of andere ketens vertegenwoordigen. Deze kunnen dan ook alleen ter test ingezet worden op Sandbox.<br />
Deze test certificaten kunnen worden aangevraagd via [mailto:support@kennisnet.nl Kennisnet support]<br />
<br />
== Aanmelden van het certificaat ==<br />
Het gekochte PKI Overheid certificaat moet bij Kennisnet worden aangemeld om zodoende het OIN/HRN te whitelisten op het Traffic-center. Dit kan door het certificaat aan te melden bij Kennisnet Support. '''Let op: lever ALLEEN het certificaat, niet een pfx, p12, private key of wat anders op. Alleen het publieke deel in de vorm van een crt of pem bestand.'''<br />
<br />
== Implementatie Client Certificate Authentication ==<br />
De developers wiki beschrijft op een abstract niveau aan welke eisen systemen binnen de keten moeten voldoen. In enkele gevallen is het echter toch gewenst een voorbeeld implementatie uit te werken. Dit geldt sterk voor de client certificate authenticatie op Windows systemen. Hierop is besloten voor IIS 8.5 een concrete uitwerking te maken. Deze is te lezen in de handreiking voor beheerders van Windows gebaseerde systemen: [[Standaarden:Beveiligd_Gegevenstransport/client_authentication_windows|handleiding client authentication voor Windows]].<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10950Standaarden:Beveiligd Gegevenstransport/certificaten webservice2021-06-21T10:45:33Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een PKIoverheid certificaat voor machine to machine verkeer (Private Root CA) mag '''maximaal 3 jaar''' geldig zijn<br />
* Een PKIoverheid certificaat voor human to machine verkeer (Publieke server services) mag '''maximaal 1 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. Voor de Publieke server services geldt dat de uitgegeven certificaten onder de regels van het CA/B vallen. Hierdoor geldt een maximale leeftijd van 1 jaar voor alle certificaten. Voor de Private Root certificaten is dit anders. Deze certificaten vallen niet onder de CA/B regels en hebben daarom een afwijkende afspraak.<br />
<br />
Lees er [https://logius.nl/diensten/pkioverheid/verschil-public-en-private hier] meer over<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal [[Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat|voorbeelden]] uitgewerkt voor de meest voorkomende situaties. Dit kan uiteraard niet uitputtend zijn, dus neem voor specifieke vragen hieromtrent altijd contact op met de leverancier van het betreffende systeem.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/opzet_paginas&diff=10949Standaarden:Beveiligd Gegevenstransport/opzet paginas2021-06-21T10:45:21Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
De wiki pagina's zijn opgezet met een pagina per thema en per themapagina onderverdeeld in hoofdstukken per configuratie item. De items zijn onderverdeeld in '''Eisen''' met daaronder '''Verklaring'''.<br/><br />
De binnen de eisen genoemde bullets worden expliciet gemaakt door hier dik gedrukt te noemen:<br />
* '''moet'''<br />
* '''mag niet'''<br />
* En varianten hierop<br />
<br />
Hiermee wordt expliciet gemaakt dat aan deze eis, of onverwijld en volledig voldaan moet worden, of dat iets geen goed idee is, of dat iets niet gedaan mag worden. Het niet voldoen aan een eis vormt een blocker bij de kwalificatie.<br/><br />
Het is ook mogelijk dat de eis iets subtieler is:<br />
* '''onwenselijk''': Hetgeen genoemd is moet je eigenlijk niet willen en wordt afgeraden te doen. Het is echter (nog) geen blocker voor kwalificatie<br />
* '''acceptabel''': Hetgeen genoemd is voldoende sterk om veilig en betrouwbaar te gebruiken, echter zal dit niet een lange termijn oplossing zijn. Verbetering is wenselijk<br />
* '''zeer wenselijk''': Hetgeen genoemd is veilig en betrouwbaar, waardoor het ook op langere termijn blijft voldoen<br />
<br />
De verklaring onder de eisen legt vervolgens uit hoe de eisen gelezen moeten worden, soms toegelicht met voorbeelden. Ook refereert de verklaring naar externe stukken waarin terug te lezen is waarom en bepaalde beveiligingseisen tot stand zijn gekomen.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/scope&diff=10948Standaarden:Beveiligd Gegevenstransport/scope2021-06-21T10:45:13Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
== Scope van de beveiligingsmaatregelen ==<br />
Binnen de scope van de beschreven beveiligingsmaatregelen vallen alle systemen die verantwoordelijk zijn voor de be- en verwerking van gegevens in een keten. <br/><br />
Ter indicatie onder andere, maar niet uitsluitend, de volgende type systemen vallen hieronder:<br />
* Administratieve systemen zoals Leerling Administratie Systemen (LAS), Samenwerkingsverbandsystemen (SWV) en Reginale Platforms (RP)<br />
* De webservices welke in een keten geraadpleegd worden<br />
* Regie systemen binnen een keten (systemen welke routering, en autorisatie van berichtverkeer verzorgen)<br />
<br />
De identificatie en het gedrag van eindgebruikers valt niet binnen de scope van de beveiligingsmaatregelen. Dit behoort expliciet toe aan de beveiligingsmaatregelen die worden opgelegd aan de specifieke systemen.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/uitgangspunten&diff=10947Standaarden:Beveiligd Gegevenstransport/uitgangspunten2021-06-21T10:45:03Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
== Uitgangspunten voor de beveiliging van gegevenstransport ==<br />
De beveiliging van het gegevenstransport is gekoppeld aan overkoepelend beleid. Middels het beleid geven we aan wat we willen bereiken. Specifiek voor de beveiliging van het gegevenstransport vinden we onderstaande standpunten het belangrijkst:<br />
* We willen persoonsgegevens zo goed mogelijk beschermen tegen diefstal, misbruik en ongeoorloofde aanpassing<br />
* We willen garanderen dat de overdracht van persoonsgegevens verloopt binnen alle door de wetgever gestelde eisen die gelden worden aan de omgang met persoonsgegevens<br />
* We willen dat de overdracht van persoonsgegevens niet alleen veilig verloopt, maar ook voorziet in administratieve lastenverlichting binnen ketens<br />
* We willen de toegang tot data en systemen binnen de ketens alleen verlenen aan systemen die we vertrouwen<br />
* We willen dat alle activiteiten binnen de ketens herleidbaar zijn tot een verantwoordelijke persoon<br />
<br/><br />
Deze standpunten vinden hun uitwerking in deze sectie van de wiki.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport&diff=10946Standaarden:Beveiligd Gegevenstransport2021-06-21T10:44:39Z<p>Klein01: </p>
<hr />
<div>'''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]'''<br />
<br />
# [[Standaarden:Beveiligd_Gegevenstransport/uitgangspunten|Uitgangspunten beveiliging: Waarom doen we dit?]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/scope|Scope]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/opzet_paginas|Opzet beveiligingspagina's]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/certificaten webservice|Certificaten webservice adres]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Leveranciers_van_certificaten|Leveranciers van certificaten]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Geldigheidsduur_.28maximale_termijn.29|Geldigheidsduur (maximale termijn)]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Type_certificaat|Type certificaat (domain, wildcard, SAN)]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Sterkte_en_type_sleutel|Sterkte en type sleutel]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Wisselen_sleutel|Wisselen sleutel]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Ondertekeningsalgoritme|Ondertekeningsalgoritme]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Type_CSP_validatie_.28DV.2C_OV.2C_EV.29|Type CSP validatie (DV, OV, EV)]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Certificaat_keten|Certificaat keten]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten|Client certificaten]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Leverancier_van_certificaten|Leverancier van certificaten]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Geldigheidsduur|Geldigheidsduur]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Sterkte_sleutel|Sterkte sleutel]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Wisselen_sleutel|Wisselen sleutel]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Ondertekeningsalgoritme|Ondertekeningsalgoritme]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Gebruik_van_het_certificaat|Gebruik van het certificaat]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Aanmelden_van_het_certificaat|Aanmelden van het certificaat]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/client_certificaten#Implementatie_Client_Certificate_Authentication|Implementatie client certificate authentication]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie|Certificaat validatie]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie#Verloopdatum|Verloopdatum]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie#Intrekkingsstatus|Intrekkingsstatus]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie#Validatie_certificaat_keten|Validatie certificaat keten]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie#Certificaat_voor_de_webservice_geldig_op_het_aangegeven_domein.3F|Certificaat voor de webservice geldig op het aangegeven domein?]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/certificaat_validatie#Client_certificaat_geldig_binnen_de_keten.3F|Client certificaat geldig binnen de keten?]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/protocollen|Protocollen]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/protocollen#HTTPS|HTTPS]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/protocollen#HSTS|HSTS]]<br />
#* [[Standaarden:Beveiligd_Gegevenstransport/protocollen#TLS|TLS]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/controle_procedure|Controle procedure]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/Procedure bij (vermoeden van) misbruik|Procedure bij (vermoeden van) misbruik]]<br />
# [[Standaarden:Beveiligd_Gegevenstransport/FAQ|Veel gestelde vragen over beveiliging]]<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/client_certificaten&diff=10907Standaarden:Beveiligd Gegevenstransport/client certificaten2021-02-08T10:57:42Z<p>Klein01: /* Verklaring */</p>
<hr />
<div>Elke keten maakt gebruik van het "SaaS certificaat". Dit betekent dat voor elke koppeling naar een interface binnen de keten TLS client authenticatie door het softwarepakket nodig is. De school hoeft hiervoor dus niets te doen. De instantie die verantwoordelijk is voor de uitgifte van deze certificaten is [https://pkioverheid.nl/ PKI Overheid]. Een software leverancier die actief is binnen de een keten moet zichzelf voorzien van zo'n certificaat. <br/><br />
Validatie binnen de keten vindt plaats door te checken of:<br />
* Het certificaat is uitgegeven door de correcte CA<br />
* Het certificaat een OIN/HRN bevat dat gewhitelist is voor communicatie binnen de keten<br />
<br />
Elke keten implementeert zijn eigen registratiesysteem waarin alle voor deze keten gekwalificeerde systemen zijn opgenomen. Binnen dit register worden de gekwalificeerde OIN/HRNs opgenomen welke in het PKIo certificaat zijn gepubliceerd. Om in het register gewhitelist te worden dient het aangesloten systeem eerst gekwalificeerd te worden door Kennisnet. In het register wordt de lijst van aangesloten Leveranciers bijgehouden en hun relatie met scholen (via Aanleverpunten).<br />
<br />
== Leverancier van certificaten ==<br />
=== Eisen ===<br />
* Het client certificaat '''moet''' uitgegeven worden door een geaccrediteerd uitgever van "Staat der Nederlanden" certificaten.<br />
* Het client certificaat '''moet''' ondertekend zijn door:<br />
** "Staat der Nederlanden Private Services CA - G1"<br />
** "Staat der Nederlanden Domein Server CA 2020"<br />
* De service die de client certificaat validatie afdwingt '''moet''' exact de 2 bovenstaande certificaat uitgevers accepteren<br />
* De service die de client certificaat validatie afdwingt '''moet''' valideren dat de intermediate CA het client certificaat daadwerkelijk ondertekend heeft<br />
* Het client certificaat '''moet''' een OIN/HRN bevatten, in het veld subject.serialNumber<br />
<br />
=== Verklaring ===<br />
Er zijn [https://www.logius.nl/diensten/pkioverheid/aanschaffen/ een aantal CSP's] die namens de Staat der Nederlanden certificaten mogen uitgeven. Dit zijn commerciële partijen met elk hun eigen aanvraagprocedures en kosten. Het root CA blijft echter altijd "Staat der Nederlanden EV Root CA" of "Staat der Nederlanden Private Root CA - G1". Al deze certificaat ketens moeten worden ondersteund door alle aangesloten systemen. Informatie over deze certificaten is na te lezen op [https://www.logius.nl/standaarden/pkioverheid/certificaten/ de site van Logius].<br/><br />
Elke keten valideert de client certificaten alleen tegen bovengenoemde intermediate certificaten. Onder root CA Staat der Nederlanden worden nog meer typen certificaten uitgegeven dan de door ons gebruikte service certificaten, bijvoorbeeld persoonscertificaten. Deze typen worden binnen deze ketens niet geaccepteerd, dus dat is dan ook de reden om niet tegen het root CA certificaat te valideren, maar tegen een sub certificaat onder Staat der Nederlanden.<br/><br />
Op eerder genoemde site van Logius zijn de kenmerken van de certificaten in te zien en zijn de certificaten zelf ook te downloaden.<br/><br />
<br/><br />
De gebruikte certificaten vallen onder de [https://www.logius.nl/diensten/digikoppeling/ Digikoppeling standaard] en zijn daarmee universeel inzetbaar voor communicatie met steeds meer overheidsdiensten. Meer informatie over de standaardisatie van deze certificaten is [https://www.logius.nl/fileadmin/logius/ns/diensten/digikoppeling/aansluitdocumentatie/Digikoppeling_Gebruik_en_achtergrond_certificaten_v1_4.pdf hier] te lezen. Voor de ketens is het OIN/HRN van belang. Lees met name vanaf pagina 23 door om te begrijpen hoe het OIN/HRN werkt.<br />
<br />
=== Aanvullende informatie betreffende CSPs ===<br />
Let op dat er een servercertificaat van PKIoverheid wordt gekozen. Hierbij moet je ervoor zorgen dat het OIN/HRN ingevuld is. Standaard wordt dit nummer op basis van het KvK-nummer gegenereerd, maar controleer dit goed. Zonder dit nummer is het certificaat niet bruikbaar!!<br/><br />
Het standaard nummer is gebaseerd op het KVK nummer (00000003KvKnummer0000) en heet een HRN. Deze is alleen van toepassing voor bedrijven. Let op dat in geval van bedrijfsfusies, holdingen, etc, het juiste KvK-nummer wordt gebruikt!<br/><br />
Mocht de organisatie geen bedrijf zijn maar een overheidsgerelateerde organisatie, dan dient een OIN aangevraagd te worden. Alle OINs zijn in te zien in het [https://register.digikoppeling.nl/overview/index register]. Het spreekt voor zich dat het OIN bekend moet zijn alvorens het certificaat aangevraagd kan worden.<br/><br/><br />
Lees voor aanvragen bij KPN ook de [https://certificaat.kpn.com/files/overig/kpn-pkioverheid-toelichting-aanvraag-servercertificaat.pdf handleiding] door.<br />
<br />
== Geldigheidsduur ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Geldigheidsduur_.28maximale_termijn.29|certificaten voor de webservice]].<br />
== Sterkte sleutel ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Sterkte_en_type_sleutel|certificaten voor de webservice]].<br />
== Wisselen sleutel ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Wisselen_sleutel|certificaten voor de webservice]].<br />
== Ondertekeningsalgoritme ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Ondertekeningsalgoritme|certificaten voor de webservice]].<br />
== Certificaat keten ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Certificaat_keten|certificaten voor de webservice]].<br />
== Gebruik van het certificaat ==<br />
Het door PKI Overheid uitgegeven certificaat wordt alleen gebruikt op de Kwalificatie- en Productie omgeving. Op de Sandbox omgeving worden certificaten gebruikt die nog wel door Kennisnet worden gegenereerd, maar verder geen enkele geldigheid op andere omgevingen of andere ketens vertegenwoordigen. Deze kunnen dan ook alleen ter test ingezet worden op Sandbox.<br />
Deze test certificaten kunnen worden aangevraagd via [mailto:support@kennisnet.nl Kennisnet support]<br />
<br />
== Aanmelden van het certificaat ==<br />
Het gekochte PKI Overheid certificaat moet bij Kennisnet worden aangemeld om zodoende het OIN/HRN te whitelisten op het Traffic-center. Dit kan door het certificaat aan te melden bij Kennisnet Support. '''Let op: lever ALLEEN het certificaat, niet een pfx, p12, private key of wat anders op. Alleen het publieke deel in de vorm van een crt of pem bestand.'''<br />
<br />
== Implementatie Client Certificate Authentication ==<br />
De developers wiki beschrijft op een abstract niveau aan welke eisen systemen binnen de keten moeten voldoen. In enkele gevallen is het echter toch gewenst een voorbeeld implementatie uit te werken. Dit geldt sterk voor de client certificate authenticatie op Windows systemen. Hierop is besloten voor IIS 8.5 een concrete uitwerking te maken. Deze is te lezen in de handreiking voor beheerders van Windows gebaseerde systemen: [[Standaarden:Beveiligd_Gegevenstransport/client_authentication_windows|handleiding client authentication voor Windows]].<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/client_certificaten&diff=10906Standaarden:Beveiligd Gegevenstransport/client certificaten2021-02-08T10:57:06Z<p>Klein01: /* Eisen */</p>
<hr />
<div>Elke keten maakt gebruik van het "SaaS certificaat". Dit betekent dat voor elke koppeling naar een interface binnen de keten TLS client authenticatie door het softwarepakket nodig is. De school hoeft hiervoor dus niets te doen. De instantie die verantwoordelijk is voor de uitgifte van deze certificaten is [https://pkioverheid.nl/ PKI Overheid]. Een software leverancier die actief is binnen de een keten moet zichzelf voorzien van zo'n certificaat. <br/><br />
Validatie binnen de keten vindt plaats door te checken of:<br />
* Het certificaat is uitgegeven door de correcte CA<br />
* Het certificaat een OIN/HRN bevat dat gewhitelist is voor communicatie binnen de keten<br />
<br />
Elke keten implementeert zijn eigen registratiesysteem waarin alle voor deze keten gekwalificeerde systemen zijn opgenomen. Binnen dit register worden de gekwalificeerde OIN/HRNs opgenomen welke in het PKIo certificaat zijn gepubliceerd. Om in het register gewhitelist te worden dient het aangesloten systeem eerst gekwalificeerd te worden door Kennisnet. In het register wordt de lijst van aangesloten Leveranciers bijgehouden en hun relatie met scholen (via Aanleverpunten).<br />
<br />
== Leverancier van certificaten ==<br />
=== Eisen ===<br />
* Het client certificaat '''moet''' uitgegeven worden door een geaccrediteerd uitgever van "Staat der Nederlanden" certificaten.<br />
* Het client certificaat '''moet''' ondertekend zijn door:<br />
** "Staat der Nederlanden Private Services CA - G1"<br />
** "Staat der Nederlanden Domein Server CA 2020"<br />
* De service die de client certificaat validatie afdwingt '''moet''' exact de 2 bovenstaande certificaat uitgevers accepteren<br />
* De service die de client certificaat validatie afdwingt '''moet''' valideren dat de intermediate CA het client certificaat daadwerkelijk ondertekend heeft<br />
* Het client certificaat '''moet''' een OIN/HRN bevatten, in het veld subject.serialNumber<br />
<br />
=== Verklaring ===<br />
Er zijn [https://www.logius.nl/diensten/pkioverheid/aanschaffen/ een aantal CSP's] die namens de Staat der Nederlanden certificaten mogen uitgeven. Dit zijn commerciële partijen met elk hun eigen aanvraagprocedures en kosten. Het root CA blijft echter altijd "Staat der Nederlanden Root CA - G3", " Staat der Nederlanden EV Root CA" of "Staat der Nederlanden Private Root CA - G1". Al deze certificaat ketens moeten worden ondersteund door alle aangesloten systemen. Informatie over deze certificaten is na te lezen op [https://www.logius.nl/standaarden/pkioverheid/certificaten/ de site van Logius].<br/><br />
Elke keten valideert de client certificaten alleen tegen bovengenoemde intermediate certificaten. Onder root CA Staat der Nederlanden worden nog meer typen certificaten uitgegeven dan de door ons gebruikte service certificaten, bijvoorbeeld persoonscertificaten. Deze typen worden binnen deze ketens niet geaccepteerd, dus dat is dan ook de reden om niet tegen het root CA certificaat te valideren, maar tegen een sub certificaat onder Staat der Nederlanden.<br/><br />
Op eerder genoemde site van Logius zijn de kenmerken van de certificaten in te zien en zijn de certificaten zelf ook te downloaden.<br/><br />
<br/><br />
De gebruikte certificaten vallen onder de [https://www.logius.nl/diensten/digikoppeling/ Digikoppeling standaard] en zijn daarmee universeel inzetbaar voor communicatie met steeds meer overheidsdiensten. Meer informatie over de standaardisatie van deze certificaten is [https://www.logius.nl/fileadmin/logius/ns/diensten/digikoppeling/aansluitdocumentatie/Digikoppeling_Gebruik_en_achtergrond_certificaten_v1_4.pdf hier] te lezen. Voor de ketens is het OIN/HRN van belang. Lees met name vanaf pagina 23 door om te begrijpen hoe het OIN/HRN werkt.<br />
<br />
=== Aanvullende informatie betreffende CSPs ===<br />
Let op dat er een servercertificaat van PKIoverheid wordt gekozen. Hierbij moet je ervoor zorgen dat het OIN/HRN ingevuld is. Standaard wordt dit nummer op basis van het KvK-nummer gegenereerd, maar controleer dit goed. Zonder dit nummer is het certificaat niet bruikbaar!!<br/><br />
Het standaard nummer is gebaseerd op het KVK nummer (00000003KvKnummer0000) en heet een HRN. Deze is alleen van toepassing voor bedrijven. Let op dat in geval van bedrijfsfusies, holdingen, etc, het juiste KvK-nummer wordt gebruikt!<br/><br />
Mocht de organisatie geen bedrijf zijn maar een overheidsgerelateerde organisatie, dan dient een OIN aangevraagd te worden. Alle OINs zijn in te zien in het [https://register.digikoppeling.nl/overview/index register]. Het spreekt voor zich dat het OIN bekend moet zijn alvorens het certificaat aangevraagd kan worden.<br/><br/><br />
Lees voor aanvragen bij KPN ook de [https://certificaat.kpn.com/files/overig/kpn-pkioverheid-toelichting-aanvraag-servercertificaat.pdf handleiding] door.<br />
<br />
== Geldigheidsduur ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Geldigheidsduur_.28maximale_termijn.29|certificaten voor de webservice]].<br />
== Sterkte sleutel ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Sterkte_en_type_sleutel|certificaten voor de webservice]].<br />
== Wisselen sleutel ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Wisselen_sleutel|certificaten voor de webservice]].<br />
== Ondertekeningsalgoritme ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Ondertekeningsalgoritme|certificaten voor de webservice]].<br />
== Certificaat keten ==<br />
Zie hiervoor de eisen bij de [[Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice#Certificaat_keten|certificaten voor de webservice]].<br />
== Gebruik van het certificaat ==<br />
Het door PKI Overheid uitgegeven certificaat wordt alleen gebruikt op de Kwalificatie- en Productie omgeving. Op de Sandbox omgeving worden certificaten gebruikt die nog wel door Kennisnet worden gegenereerd, maar verder geen enkele geldigheid op andere omgevingen of andere ketens vertegenwoordigen. Deze kunnen dan ook alleen ter test ingezet worden op Sandbox.<br />
Deze test certificaten kunnen worden aangevraagd via [mailto:support@kennisnet.nl Kennisnet support]<br />
<br />
== Aanmelden van het certificaat ==<br />
Het gekochte PKI Overheid certificaat moet bij Kennisnet worden aangemeld om zodoende het OIN/HRN te whitelisten op het Traffic-center. Dit kan door het certificaat aan te melden bij Kennisnet Support. '''Let op: lever ALLEEN het certificaat, niet een pfx, p12, private key of wat anders op. Alleen het publieke deel in de vorm van een crt of pem bestand.'''<br />
<br />
== Implementatie Client Certificate Authentication ==<br />
De developers wiki beschrijft op een abstract niveau aan welke eisen systemen binnen de keten moeten voldoen. In enkele gevallen is het echter toch gewenst een voorbeeld implementatie uit te werken. Dit geldt sterk voor de client certificate authenticatie op Windows systemen. Hierop is besloten voor IIS 8.5 een concrete uitwerking te maken. Deze is te lezen in de handreiking voor beheerders van Windows gebaseerde systemen: [[Standaarden:Beveiligd_Gegevenstransport/client_authentication_windows|handleiding client authentication voor Windows]].<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10905Standaarden:Beveiligd Gegevenstransport/certificaten webservice2021-02-08T10:55:59Z<p>Klein01: /* Verklaring */</p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een PKIoverheid certificaat voor machine to machine verkeer (Private Root CA) mag '''maximaal 3 jaar''' geldig zijn<br />
* Een PKIoverheid certificaat voor human to machine verkeer (Publieke server services) mag '''maximaal 1 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. Voor de Publieke server services geldt dat de uitgegeven certificaten onder de regels van het CA/B vallen. Hierdoor geldt een maximale leeftijd van 1 jaar voor alle certificaten. Voor de Private Root certificaten is dit anders. Deze certificaten vallen niet onder de CA/B regels en hebben daarom een afwijkende afspraak.<br />
<br />
Lees er [https://logius.nl/diensten/pkioverheid/verschil-public-en-private hier] meer over<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal [[Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat|voorbeelden]] uitgewerkt voor de meest voorkomende situaties. Dit kan uiteraard niet uitputtend zijn, dus neem voor specifieke vragen hieromtrent altijd contact op met de leverancier van het betreffende systeem.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10904Standaarden:Beveiligd Gegevenstransport/certificaten webservice2021-02-08T10:55:27Z<p>Klein01: /* Verklaring */</p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een PKIoverheid certificaat voor machine to machine verkeer (Private Root CA) mag '''maximaal 3 jaar''' geldig zijn<br />
* Een PKIoverheid certificaat voor human to machine verkeer (Publieke server services) mag '''maximaal 1 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. Voor de Publieke server services geldt dat de uitgegeven certificaten onder de regels van het CA/B vallen. Hierdoor geldt een maximale leeftijd van 1 jaar voor alle certificaten. Voor de Private Root certificaten is dit anders. Deze certificaten vallen niet onder de CA/B regels en hebben daarom een afwijkende afspraak.<br />
<br />
Lees er [https://logius.nl/diensten/pkioverheid/verschil-public-en-private hier] meer over<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (G3 of private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal [[Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat|voorbeelden]] uitgewerkt voor de meest voorkomende situaties. Dit kan uiteraard niet uitputtend zijn, dus neem voor specifieke vragen hieromtrent altijd contact op met de leverancier van het betreffende systeem.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10903Standaarden:Beveiligd Gegevenstransport/certificaten webservice2021-02-08T10:52:30Z<p>Klein01: /* Geldigheidsduur (maximale termijn) */</p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een PKIoverheid certificaat voor machine to machine verkeer (Private Root CA) mag '''maximaal 3 jaar''' geldig zijn<br />
* Een PKIoverheid certificaat voor human to machine verkeer (Publieke server services) mag '''maximaal 1 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. Voor de Publieke server services geldt dat de uitgegeven certificaten onder de regels van het CA/B vallen. Hierdoor geldt een maximale leeftijd van 1 jaar voor alle certificaten. Voor de Private Root certificaten is dit anders. Deze certificaten vallen niet onder de CA/B regels en hebben daarom een afwijkende afspraak.<br />
<br />
Lees er [https://logius.nl/diensten/pkioverheid/verschil-public-en-private hier] meer over<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (G3 of private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Staat der Nederlanden - G3<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Root CA - G3<br />
*** Domein Organisatie Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Organisatie Services CA - G3<br />
**** Digidentity BV PKIoverheid Organisatie Server CA - G3<br />
**** KPN PKIoverheid Organisatie Services CA - G3<br />
**** KPN BV PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIoverheid Organisatie Services CA - G3<br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
'''Update 03-09-2020''' De diensten van Kennisnet kunnen inmiddels omgaan met certificaten uit de drie bovengenoemde certificaat ketens. Dit betekent echter niet dat dit geldt voor alle dienstleveranciers in de educatieve keten. Certificaten die vallen onder de Private Root CA worden op het moment van schrijven nog maar beperkt ondersteund door ketenpartijen. Dit heeft als gevolg dat uitwisselingen hierdoor kunnen mislukken. Totdat elke partij de certificaten uit de Private Root keten accepteert is het verstandig om gebruik te maken van de oude G3 server services certificaten.<br />
<br />
<br />
Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal [[Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat|voorbeelden]] uitgewerkt voor de meest voorkomende situaties. Dit kan uiteraard niet uitputtend zijn, dus neem voor specifieke vragen hieromtrent altijd contact op met de leverancier van het betreffende systeem.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10775Standaarden:Beveiligd Gegevenstransport/certificaten webservice2020-09-07T08:01:34Z<p>Klein01: </p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een certificaat voor de webservice mag '''maximaal 2 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. <br />Gezien de elkaar snel opvolgende berichten betreffende de veiligheid van certificaten (denk aan de SHA1 hashing, onbetrouwbaar geworden CA's, etc.) is een maximale validiteit van 2 jaar gekozen. Hiermee wordt het Certificate Authority and Browser Forum (CA/B) [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.2.pdf gevolgd]<br />
<br />
De validiteit van maximaal 2 jaar is een wijziging die ingaat per maart 2018. Voor alle uitgegeven certificaten van voor deze datum geldt nog een maximale geldigheid van 3 jaar. Alle vanaf maart uitgegeven certificaten zijn nog maximaal 825 dagen geldig (dit is inclusief overloop termijn van 95 dagen).<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (G3 of private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Staat der Nederlanden - G3<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Root CA - G3<br />
*** Domein Organisatie Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Organisatie Services CA - G3<br />
**** Digidentity BV PKIoverheid Organisatie Server CA - G3<br />
**** KPN PKIoverheid Organisatie Services CA - G3<br />
**** KPN BV PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIoverheid Organisatie Services CA - G3<br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
'''Update 03-09-2020''' De diensten van Kennisnet kunnen inmiddels omgaan met certificaten uit de drie bovengenoemde certificaat ketens. Dit betekent echter niet dat dit geldt voor alle dienstleveranciers in de educatieve keten. Certificaten die vallen onder de Private Root CA worden op het moment van schrijven nog maar beperkt ondersteund door ketenpartijen. Dit heeft als gevolg dat uitwisselingen hierdoor kunnen mislukken. Totdat elke partij de certificaten uit de Private Root keten accepteert is het verstandig om gebruik te maken van de oude G3 server services certificaten.<br />
<br />
<br />
Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal [[Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat|voorbeelden]] uitgewerkt voor de meest voorkomende situaties. Dit kan uiteraard niet uitputtend zijn, dus neem voor specifieke vragen hieromtrent altijd contact op met de leverancier van het betreffende systeem.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat&diff=10774Standaarden:Beveiligd Gegevenstransport/import root certificaat2020-09-07T08:00:40Z<p>Klein01: Nieuwe pagina aangemaakt met 'Om de certificaat keten voor de PKIoverheid Staat der Nederlanden Private Root CA - G1 werkend te maken op systemen zijn meer handelingen nodig dan voor de andere P...'</p>
<hr />
<div>Om de certificaat keten voor de PKIoverheid Staat der Nederlanden Private Root CA - G1 werkend te maken op systemen zijn meer handelingen nodig dan voor de andere PKIoverheid certificaten. Dit komt omdat de Private Root CA niet standaard herkend wordt in systemen. Dit moet handmatig gerealiseerd worden. In onderstaand artikel wordt hiervoor voor de meest gebruikte systemen een aanzet gegeven. Gezien de variaties en specials die per systeem kunnen bestaan is dit artikel dan ook lang niet uitputtend. Voor inhoudelijke vragen over het importeren van root certificaten verwijzen we graag door naar de leverancier van het gebruikte systeem.<br />
<br />
Het certificaat wat we gebruiken is het ''Staat der Nederlanden Private Root CA - G1 stamcertificaat''. Genaamd PrivateRootCA-G1.cer<br />
<br />
== Linux ==<br />
Het certificaat wat je bij PKIoverheid download is in het DER formaat, een binair formaat. Dit wordt vaak niet direct geaccepteerd, het moet eerst omgezet worden in PEM formaat, wat een tekstgebaseerd formaat is. Het makkelijkst is om dit middels openssl te doen.<br />
<br />
Converteer het DER bestand naar PEM:<br />
openssl x509 -inform DER -in PrivateRootCA-G1.cer -out PrivateRootCA-G1.crt -text<br />
<br />
Gebruik vervolgens het .crt bestand voor de rest van de stappen.<br />
<br />
Run de volgende commando's om het certificaat bekend te maken op het systeem.<br />
sudo mkdir /usr/local/share/ca-certificates/extra<br />
sudo cp PrivateRootCA-G1.crt /usr/local/share/ca-certificates/extra/PrivateRootCA-G1.crt<br />
sudo update-ca-certificates<br />
<br />
== Windows ==<br />
Als er gebruik gemaakt wordt van een Active Directory dan is het handig om het certificaat direct daar te importeren zodat het certificaat direct op alle machines bekend is. Mocht dit niet kunnen of onwenselijk zijn dan kan het certificaat ook lokaal geïmporteerd worden.<br />
* Dubbelklik het certificaat bestand, en klik Import Certificate<br />
* Verander Store Location naar Local Machine<br />
* Accepteer een eventuele UAC melding<br />
* In het volgende scherm, selecteer een specifieke certificate store: Trusted Root Certification Authorities<br />
* De import wizard is klaar, certificaat is geïmporteerd.<br />
* Het kan zijn dat de server hierna nog herstart moet worden (volledige herstart van het systeem)<br />
<br />
== Java ==<br />
Java maakt geen gebruik van de vertrouwde root certificaten op het onderliggende systeem. Java heeft zijn eigen keystore waar het certificaat toegevoegd moet worden.<br />
Onder Linux staat de tool 'keytool' meestal wel op een locatie welke in het $PATH bekend is. Zo niet, run<br />
find / -name keytool<br />
Onder Windows zal je naar de locatie moeten navigeren in de commandprompt (bijv. cmd). Meestal staat de JRE in Program Files geïnstalleerd.<br />
<br />
Voor Linux:<br />
sudo keytool -importcert -alias staat_der_nederlanden_private_root_g1 -keystore $(readlink -e $(dirname $(readlink -e $(which keytool)))/../lib/security/cacerts) -storepass changeit -file PrivateRootCA-G1.cer<br />
<br />
Voor Windows:<br />
Zorg dat je met een commandprompt in de JRE directory staat.<br />
bin\keytool -importcert -alias staat_der_nederlanden_private_root_g1 -keystore lib\security\cacerts -storepass changeit -file PrivateRootCA-G1.cer<br />
<br />
Type in de opkomende prompt '''yes''' om het certificaat te vertrouwen.<br />
<br />
Vervolgens is het certificaat terug te vinden middels keytool:<br />
keytool -list -keystore BOVENSTAAND_PATH_NAAR_CACERTS -storepass changeit</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10773Standaarden:Beveiligd Gegevenstransport/certificaten webservice2020-09-07T07:54:41Z<p>Klein01: /* Certificaat keten */</p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een certificaat voor de webservice mag '''maximaal 2 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. <br />Gezien de elkaar snel opvolgende berichten betreffende de veiligheid van certificaten (denk aan de SHA1 hashing, onbetrouwbaar geworden CA's, etc.) is een maximale validiteit van 2 jaar gekozen. Hiermee wordt het Certificate Authority and Browser Forum (CA/B) [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.2.pdf gevolgd]<br />
<br />
De validiteit van maximaal 2 jaar is een wijziging die ingaat per maart 2018. Voor alle uitgegeven certificaten van voor deze datum geldt nog een maximale geldigheid van 3 jaar. Alle vanaf maart uitgegeven certificaten zijn nog maximaal 825 dagen geldig (dit is inclusief overloop termijn van 95 dagen).<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (G3 of private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Staat der Nederlanden - G3<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Root CA - G3<br />
*** Domein Organisatie Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Organisatie Services CA - G3<br />
**** Digidentity BV PKIoverheid Organisatie Server CA - G3<br />
**** KPN PKIoverheid Organisatie Services CA - G3<br />
**** KPN BV PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIoverheid Organisatie Services CA - G3<br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
'''Update 03-09-2020''' De diensten van Kennisnet kunnen inmiddels omgaan met certificaten uit de drie bovengenoemde certificaat ketens. Dit betekent echter niet dat dit geldt voor alle dienstleveranciers in de educatieve keten. Certificaten die vallen onder de Private Root CA worden op het moment van schrijven nog maar beperkt ondersteund door ketenpartijen. Dit heeft als gevolg dat uitwisselingen hierdoor kunnen mislukken. Totdat elke partij de certificaten uit de Private Root keten accepteert is het verstandig om gebruik te maken van de oude G3 server services certificaten.<br />
<br />
Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal [[Standaarden:Beveiligd_Gegevenstransport/import_root_certificaat|voorbeelden]] uitgewerkt voor de meest voorkomende situaties. Dit kan uiteraard niet uitputtend zijn, dus neem voor specifieke vragen hieromtrent altijd contact op met de leverancier van het betreffende systeem.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10764Standaarden:Beveiligd Gegevenstransport/certificaten webservice2020-09-03T18:41:39Z<p>Klein01: /* Verklaring */</p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een certificaat voor de webservice mag '''maximaal 2 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. <br />Gezien de elkaar snel opvolgende berichten betreffende de veiligheid van certificaten (denk aan de SHA1 hashing, onbetrouwbaar geworden CA's, etc.) is een maximale validiteit van 2 jaar gekozen. Hiermee wordt het Certificate Authority and Browser Forum (CA/B) [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.2.pdf gevolgd]<br />
<br />
De validiteit van maximaal 2 jaar is een wijziging die ingaat per maart 2018. Voor alle uitgegeven certificaten van voor deze datum geldt nog een maximale geldigheid van 3 jaar. Alle vanaf maart uitgegeven certificaten zijn nog maximaal 825 dagen geldig (dit is inclusief overloop termijn van 95 dagen).<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (G3 of private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Staat der Nederlanden - G3<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Root CA - G3<br />
*** Domein Organisatie Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Organisatie Services CA - G3<br />
**** Digidentity BV PKIoverheid Organisatie Server CA - G3<br />
**** KPN PKIoverheid Organisatie Services CA - G3<br />
**** KPN BV PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIoverheid Organisatie Services CA - G3<br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
'''Update 03-09-2020''' De diensten van Kennisnet kunnen inmiddels omgaan met certificaten uit de drie bovengenoemde certificaat ketens. Dit betekent echter niet dat dit geldt voor alle dienstleveranciers in de educatieve keten. Certificaten die vallen onder de Private Root CA worden op het moment van schrijven nog maar beperkt ondersteund door ketenpartijen. Dit heeft als gevolg dat uitwisselingen hierdoor kunnen mislukken. Totdat elke partij de certificaten uit de Private Root keten accepteert is het verstandig om gebruik te maken van de oude G3 server services certificaten.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01https://developers.wiki.kennisnet.nl/index.php?title=Standaarden:Beveiligd_Gegevenstransport/certificaten_webservice&diff=10763Standaarden:Beveiligd Gegevenstransport/certificaten webservice2020-09-03T18:40:44Z<p>Klein01: /* Verklaring */</p>
<hr />
<div>== Leveranciers van certificaten ==<br />
Certificaten worden uitgegeven door CA's (certificate authorities), via CSPs (Certificate Service Providers). De root CA's moeten vertrouwd worden door het systeem welke versleutelde verbindingen opzet. Om te bepalen welke CA's vertrouwd worden, wordt een [https://ccadb.org/ standaard lijst aan CA's] gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.<br/><br />
De CA's op deze lijst mogen certificaten uitgeven, dan wel een CSP middels delegatie certificaten laten uitgeven die gebruikt worden om de publieke webservices te beveiligen. Deze certificaten worden gekocht op domeinnaam door de SaaS leverancier.<br />
<br />
== Geldigheidsduur (maximale termijn) ==<br />
=== Eisen ===<br />
* Een certificaat voor de webservice mag '''maximaal 2 jaar''' geldig zijn<br />
=== Verklaring ===<br />
Certificaten zijn een technisch middel om te bewijzen welke identiteit een partij heeft en vormen de aanzet om te komen tot een versleutelde verbinding. Net als een echte ID kaart of paspoort, verlopen certificaten. Dit wordt gedaan om te voorkomen dat na verloop van tijd technisch kwalitatief ondermaatse certificaten in omloop blijven. Op het moment dat een certificaat niet langer betrouwbaar meer is, heeft deze automatisch voor een beveiligde keten geen toegevoegde waarde meer. <br />Gezien de elkaar snel opvolgende berichten betreffende de veiligheid van certificaten (denk aan de SHA1 hashing, onbetrouwbaar geworden CA's, etc.) is een maximale validiteit van 2 jaar gekozen. Hiermee wordt het Certificate Authority and Browser Forum (CA/B) [https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.2.pdf gevolgd]<br />
<br />
De validiteit van maximaal 2 jaar is een wijziging die ingaat per maart 2018. Voor alle uitgegeven certificaten van voor deze datum geldt nog een maximale geldigheid van 3 jaar. Alle vanaf maart uitgegeven certificaten zijn nog maximaal 825 dagen geldig (dit is inclusief overloop termijn van 95 dagen).<br />
<br />
== Type certificaat ==<br />
=== Eisen ===<br />
* Een certificaat voor een enkel domein is '''zeer wenselijk'''<br />
* Een SAN (Subject Alternative Name) certificaat is '''acceptabel'''<br />
* Een Wildcard certificaat is '''onwenselijk'''<br />
<br />
=== Verklaring ===<br />
Een certificaat welke alleen geldig is voor een specifiek domein heeft maar een enkele plaats waar de privésleutel is opgeslagen, waardoor kans op diefstal beperkt of ongecontroleerde verspreiding is. Bij een SAN certificaat is de spreidingskans van de privésleutel al weer groter. In een SAN certificaat zijn expliciet de (sub)domeinen vastgelegd waarvoor het certificaat geldt. De privésleutel kan mogelijk op meerdere niet gerelateerde systemen actief zijn, waardoor kans op diefstal of onbeveiligde verspreiding groter is.<br/><br />
Een wildcard certificaat is onwenselijk, aangezien dit certificaat geldt voor alle subdomeinen onder het genoemde domein in het certificaat. Hierdoor is de spreidingsvlak van het certificaat oncontroleerbaar en loopt de privésleutel een aanzienlijk risico op diefstal of onveilige verspreiding. Het valt dan ook af te raden om wildcard certificaten in te zetten. Mocht dit wel noodzakelijk zijn voor de dienstverlening, dan moeten er binnen de organisatie duidelijke afspraken en technische maatregelen getroffen worden om de sleutel veilig te houden.<br />
<br />
== Sterkte en type sleutel ==<br />
=== Eisen ===<br />
* Een RSA sleutel '''moet''' minimaal 2048bit en maximaal 4096bit lengte zijn<br />
* Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:<br />
** secp256r1<br />
** secp384r1<br />
** secp521r1<br />
* Een privésleutel '''moet''' veilig bewaard worden:<br />
** '''Alleen leesbaar''' door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)<br />
** '''Niet gedupliceerd''' naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)<br />
** Bij voorkeur beveiligd middels een wachtwoord<br />
<br />
=== Verklaring ===<br />
De sleutels die gebruikt worden voor zowel de publieke webservices (server certificaat) als wel de client certificaten welke gebruikt worden voor authenticatie van de client in de TLS sessie, moeten voldoen aan minimale sterkte eisen. De RSA privésleutel zal vrijwel overal gehanteerd worden. Hierbij is een sleutelsterkte van tenminste 2048bit noodzakelijk voor betrouwbare communicatie tussen partijen. Het verdient echter wel de aanbeveling om wanneer dit kan een sterkere sleutel te hanteren, bijvoorbeeld 3072bit of maximaal 4096bit. De reden dat er een maximum aan zit is omdat:<br />
* Calculatie met grote sleutels een CPU intensieve operatie is, waarbij efficiency ten opzichte van het bereikte resultaat goed afgewogen moet zijn. 4096bit is met de huidige stand van de techniek zeker sterk genoeg en zal dat nog lang blijven<br />
* Grote sleutels niet altijd ondersteund worden door software bibliotheken en TLS offloading hardware, waardoor compatibiliteitsproblemen kunnen ontstaan. Er moeten dan onevenredig grote investeringen gedaan worden om dit te corrigeren terwijl er op voorlopig geen toegevoegde waarde is<br />
De veiligheid van de een keten valt of staat met de beveiliging van sleutels. Elke sleutel waarmee versleuteling, ondertekening, authenticatie, etc. wordt gedaan moet beveiligd zijn tegen ongeoorloofd gebruik. Dit geldt voor zowel externe gebruikers van het systeem als wel interne medewerkers zoals bijv. beheerders van het systeem.<br />
<br />
==== Mogelijke oplossing ====<br />
Onder Linux wordt een private sleutel bijvoorbeeld gegenereerd middels openssl. De veiligste keuze, genereert een RSA sleutel met 4096bit lengte en voorzien van een wachtwoord.<br />
{{UserCmd|openssl genrsa -des3 -out private.pem 4096}}<br />
Hetzelfde, maar dan zonder wachtwoord<br />
{{UserCmd|openssl genrsa -out private.pem 4096}}<br />
Het gebruik van een wachtwoord is veiliger maar omslachtiger. Elke keer als de webserver herstart en de sleutel laadt, moet het wachtwoord opnieuw ingevoerd worden. Uiteraard kan het proces automatisch gevoed worden met het wachtwoord, maar dan wordt alsnog ergens het wachtwoord opgeslagen. Mocht hiervoor gekozen worden, zorg dan in ieder geval dat het wachtwoord en de sleutel fysiek van elkaar gescheiden worden.<br />
<br />
== Wisselen sleutel ==<br />
=== Eisen ===<br />
* Als het certificaat vernieuwd wordt '''moet''' de privésleutel ook opnieuw gegenereerd worden<br />
=== Verklaring ===<br />
Een certificaat verloopt van nature omdat er zo een dwang ontstaat om een nieuw certificaat te genereren dat voldoet aan de dan weer geldende eisen van de techniek. Daarnaast zou dit ook moeten gelden voor privésleutels. De sleutelsterkte kan bijvoorbeeld sterker worden waardoor dit zinvol is. Daarnaast bestaat ook het risico dat de sleutel inmiddels te vaak getransporteerd is en het verstandig is de oude sleutel te vernietigen.<br />
<br />
== Ondertekeningsalgoritme ==<br />
=== Eisen ===<br />
* Ondertekening van certificaten '''moet''' gebeuren met tenminste SHA256<br />
=== Verklaring ===<br />
SHA1 is [https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know volledig in de ban] gedaan omdat het onbetrouwbaar is als ondertekeningsalgoritme. De uitkomst van het algoritme is te voorspellen en dus onzichtbaar aan te passen, waardoor namaak ondertekeningen mogelijk zijn.<br />
<br />
== Type CSP validatie (DV, OV, EV) ==<br />
=== Eisen ===<br />
* Domain Validation is '''onwenselijk'''<br />
* Organisation Validation '''wenselijk'''<br />
* Extended Validation '''zeer wenselijk'''<br />
<br />
=== Verklaring ===<br />
Domein gevalideerde certificaten bieden weinig houvast betreffende de identiteit van een partij. Het certificaat wordt uitgegeven na het doorlopen van een volledig geautomatiseerd proces welke maar beperkte garantie geeft over de identiteit van de aanvrager. De enige controle die gedaan wordt is of de aanvrager iets met het domein kan doen (bijvoorbeeld mail ontvangen op het hostmaster mail adres). Dit is voor een vertrouwensketen onvoldoende en dus onwenselijk.<br/><br />
<br/><br />
Organisatie gevalideerde certificaten geven wat meer informatie over de identiteit van een partij. Het certificaat bevat ten eerste daadwerkelijk identiteitsinformatie over de aanvragende partij. Daarnaast wordt uitgifte controle door de CA ook (deels) met de hand uitgevoerd. Er vindt bijvoorbeeld telefonische controle plaats of er worden (identiteits)papieren van de aanvrager vereist. De waarde van dit type certificaten is dan ook vele malen groter dan een domein gevalideerd certificaat en daarom op zijn minst wenselijk om te gebruiken.<br/><br />
<br/><br />
Extended gevalideerde certificaten hebben de zwaarste vorm van validatie voordat ze worden uitgegeven, maar zeggen ook het meest over de houder van het certificaat. In een browser is zo'n certificaat ook te herkennen aan de groene balk in de adresbalk. Er vindt een intensieve controle plaats door de CA voordat een EV certificaat wordt uitgegeven. Hierbij dienen minimaal aanvullende bewijsstukken te worden opgeleverd over de identiteit van de aanvrager en de organisatie waarvoor deze werkt. Dit type certificaat zegt dan ook het meest over de betrouwbaarheid van het uitgegeven certificaat. In een beveiligde keten is dit type certificaat dan ook zeer wenselijk om te hanteren.<br />
<br />
== Certificaat keten ==<br />
=== Eisen ===<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client<br />
* Er '''moet''' een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver<br />
<br />
=== Verklaring ===<br />
Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie. <br/>Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.<br/><br />
<br/><br />
Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:<br/><br />
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - '''root, zit in de truststore'''<br/><br />
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - '''intermediate, moet worden meegestuurd'''<br/><br />
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - '''uw certificaat, moet worden meegestuurd'''<br/><br />
<br/><br />
Bovenstaande is indicatief. De werkelijke implementatie hangt af van de keuze voor een CSP en welke generatie certificaten er gekozen wordt (G3 of private services of public services 2020). Daarnaast is het mogelijk dat er nog een extra issuer certificaat in de boom aanwezig is. Ook deze issuer moet dan worden meegestuurd.<br/><br />
<br />
* De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op [https://cert.pkioverheid.nl/ de site van PKIoverheid]. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:<br/><br />
** Staat der Nederlanden - G3<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Root CA - G3<br />
*** Domein Organisatie Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Organisatie Services CA - G3<br />
**** Digidentity BV PKIoverheid Organisatie Server CA - G3<br />
**** KPN PKIoverheid Organisatie Services CA - G3<br />
**** KPN BV PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIOverheid Organisatie Server CA - G3<br />
**** QuoVadis PKIoverheid Organisatie Services CA - G3<br />
** Private Root CA (per medio 2020 de standaard voor m2m)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden Private Root CA - G1<br />
*** Domein Private Services, maar alleen de volgende:<br />
**** Staat der Nederlanden Private Services CA - G1<br />
**** KPN PKIoverheid Private Services CA - G1<br />
**** QuoVadis PKIoverheid Private Services CA - G1<br />
**** Digidentity BV PKIoverheid Private Services CA - G1<br />
** Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)<br />
*** Stamcertificaat<br />
**** Staat der Nederlanden EV Root CA<br />
*** Intermediair Domein Server CA 2020<br />
**** QuoVadis PKIoverheid Server CA 2020<br />
**** Digidentity PKIoverheid Server CA 2020<br />
**** KPN PKIoverheid Server CA 2020<br />
* De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.<br/><br />
<br />
'''Update 03-09-2020''' De diensten van Kennisnet kunnen inmiddels omgaan met certificaten uit de drie bovengenoemde certificaat ketens. Dit betekent echter niet dat dit geldt voor alle dienstleveranciers in de educatieve keten. Certificaten die vallen onder de Private Root CA worden op het moment van schrijven nog maar beperkt ondersteund door ketenpartijen. Dit heeft als gevolg dat uitwisselingen hierdoor kunnen mislukken. Totdat elke partij de certificaten uit de Private Root keten accepteert is het verstandig om gebruik te maken van de publieke server services certificaten.<br />
<br />
[[Categorie:Standaarden]]</div>Klein01