Standaarden:Beveiligd Gegevenstransport/client certificaten

Let op, deze voorschriften worden vervangen door de Uniforme Beveiligingsvoorschriften

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 PKI Overheid. Een software leverancier die actief is binnen de een keten moet zichzelf voorzien van zo'n certificaat.
Validatie binnen de keten vindt plaats door te checken of:

• Het certificaat is uitgegeven door de correcte CA
• Het certificaat een OIN/HRN bevat dat gewhitelist is voor communicatie binnen de keten

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).

Leverancier van certificaten

Eisen

• Het client certificaat moet uitgegeven worden door een geaccrediteerd uitgever van "Staat der Nederlanden" certificaten.
• Het client certificaat moet ondertekend zijn door:
  • "Staat der Nederlanden Private Services CA - G1"
  • "Staat der Nederlanden Domein Server CA 2020"
• De service die de client certificaat validatie afdwingt moet exact de 2 bovenstaande certificaat uitgevers accepteren
• De service die de client certificaat validatie afdwingt moet valideren dat de intermediate CA het client certificaat daadwerkelijk ondertekend heeft
• Het client certificaat moet een OIN/HRN bevatten, in het veld subject.serialNumber

Verklaring

Er zijn 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 de site van Logius.
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.
Op eerder genoemde site van Logius zijn de kenmerken van de certificaten in te zien en zijn de certificaten zelf ook te downloaden.

De gebruikte certificaten vallen onder de Digikoppeling standaard en zijn daarmee universeel inzetbaar voor communicatie met steeds meer overheidsdiensten. Meer informatie over de standaardisatie van deze certificaten is 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.

Aanvullende informatie betreffende CSPs

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!!
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!
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 register. Het spreekt voor zich dat het OIN bekend moet zijn alvorens het certificaat aangevraagd kan worden.

Lees voor aanvragen bij KPN ook de handleiding door.

Geldigheidsduur

Zie hiervoor de eisen bij de certificaten voor de webservice.

Sterkte sleutel

Zie hiervoor de eisen bij de certificaten voor de webservice.

Wisselen sleutel

Zie hiervoor de eisen bij de certificaten voor de webservice.

Ondertekeningsalgoritme

Zie hiervoor de eisen bij de certificaten voor de webservice.

Certificaat keten

Zie hiervoor de eisen bij de certificaten voor de webservice.

Gebruik van het certificaat

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. Deze test certificaten kunnen worden aangevraagd via Kennisnet support

Aanmelden van het certificaat

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.

Implementatie Client Certificate Authentication

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: handleiding client authentication voor Windows.