Standaarden:Beveiligd Gegevenstransport/certificaten webservice

Let op, deze voorschriften worden vervangen door de Uniforme Beveiligingsvoorschriften

Leveranciers van certificaten

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 standaard lijst aan CA's gehanteerd. Deze lijst wordt beheerd door de Mozilla Foundation, wordt geregeld bijgewerkt en is direct online in te zien.
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.

Geldigheidsduur (maximale termijn)

Eisen

• Een PKIoverheid certificaat voor machine to machine verkeer (Private Root CA) mag maximaal 3 jaar geldig zijn
• Een PKIoverheid certificaat voor human to machine verkeer (Publieke server services) mag maximaal 1 jaar geldig zijn

Verklaring

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.

Lees er hier meer over

Type certificaat

Eisen

• Een certificaat voor een enkel domein is zeer wenselijk
• Een SAN (Subject Alternative Name) certificaat is acceptabel
• Een Wildcard certificaat is onwenselijk

Verklaring

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

Sterkte en type sleutel

Eisen

• Een RSA sleutel moet minimaal 2048bit en maximaal 4096bit lengte zijn
• Mocht er gebruik gemaakt worden van elliptic curves als sleutel, dan moet dit minimaal een van volgende curves zijn:
  • secp256r1
  • secp384r1
  • secp521r1
• Een privésleutel moet veilig bewaard worden:
  • Alleen leesbaar door het proces dat de sleutel gebruikt (bijv. de webserver IIS of Apache)
  • Niet gedupliceerd naar andere systemen (CMDB, provisioning tools, templates, netwerkshares. etc)
  • Bij voorkeur beveiligd middels een wachtwoord

Verklaring

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:

• 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
• 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

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.

Mogelijke oplossing

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.

user@host $openssl genrsa -des3 -out private.pem 4096

Hetzelfde, maar dan zonder wachtwoord

user@host $openssl genrsa -out private.pem 4096

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.

Wisselen sleutel

Eisen

• Als het certificaat vernieuwd wordt moet de privésleutel ook opnieuw gegenereerd worden

Verklaring

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.

Ondertekeningsalgoritme

Eisen

• Ondertekening van certificaten moet gebeuren met tenminste SHA256

Verklaring

SHA1 is 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.

Type CSP validatie (DV, OV, EV)

Eisen

• Domain Validation is onwenselijk
• Organisation Validation wenselijk
• Extended Validation zeer wenselijk

Verklaring

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.

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.

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.

Certificaat keten

Eisen

• Er moet een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de webserver richting de client
• Er moet een certificaat keten met daarin alle intermediate certificaten worden meegeleverd door de client richting de webserver

Verklaring

Een certificaat keten bestaat uit het certificaat zelf, aangevuld met alle intermediate certificaten die worden meegeleverd door de CSP, de uitgevende instantie.
Het root certificaat moet niet meegeleverd worden, dat zit in de truststore van de andere partij.

Bij PKIoverheid bestaat de certificaat boom voor G2 certificaten bijvoorbeeld uit de issuers:
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2 - root, zit in de truststore
|- /C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Organisatie CA - G2 - intermediate, moet worden meegestuurd
|-- /C=NL/O=CSP Naam BV/OU=Issuing Certification Authority/CN=Naam CSP - PKI Overheid CA - G2 - intermediate, moet worden meegestuurd
|--- /C=NL/O=Uw organisatie/OU=Uw afdeling/CN=domein.tld/serialNumber=00000003KvKnummer0000 - uw certificaat, moet worden meegestuurd

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.

• De intermediate certificaten waar de server de ontvangen client certificaten tegen moet valideren zijn te downloaden op de site van PKIoverheid. De volgende intermediate certificaten moet worden gebruikt om client certificaten tegen te valideren:
  
  • Private Root CA (per medio 2020 de standaard voor m2m)
    • Stamcertificaat
      • Staat der Nederlanden Private Root CA - G1
    • Domein Private Services, maar alleen de volgende:
      • Staat der Nederlanden Private Services CA - G1
      • KPN PKIoverheid Private Services CA - G1
      • QuoVadis PKIoverheid Private Services CA - G1
      • Digidentity BV PKIoverheid Private Services CA - G1
  • Publieke server services (alleen gebruiken wanneer het certificaat ook gebruikt moet worden door browsers)
    • Stamcertificaat
      • Staat der Nederlanden EV Root CA
    • Intermediair Domein Server CA 2020
      • QuoVadis PKIoverheid Server CA 2020
      • Digidentity PKIoverheid Server CA 2020
      • KPN PKIoverheid Server CA 2020
• De intermediate certificaten die met het client certificaat moeten worden meegestuurd zijn te verkrijgen bij CSP waar het certificaat is gekocht.
  

Het importeren van root certificaten kan een lastige klus zijn. Hierom zijn er een aantal 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.