Certificaten: verschil tussen versies
(Deze pagina bevat een uitleg van het gebruik van certificaten en de Public Key Infrastructure (PKI). Voor het gebruik van certificaten binnen de koppelingconfiguratie, zie de praktische handleiding koppelingconfiguratie.) |
(geen verschil)
|
Versie van 5 jul 2016 om 08:11
Deze pagina bevat een uitleg van het gebruik van certificaten en de Public Key Infrastructure (PKI). Voor het gebruik van certificaten binnen de koppelingconfiguratie, zie de praktische handleiding koppelingconfiguratie.
Asymmetrische versleuteling
Bij het versturen van gevoelige informatie is het belangrijk dat niet zomaar iedereen kan meekijken. Daarom versleutelt het zaaksysteem de informatie die het over het internet verstuurt.
De persoon die de versleutelde informatie ontvangt, moet deze echter ook weer kunnen ontsleutelen. Daar is een sleutel voor nodig. Die sleutel kan niet zomaar over het internet worden verstuurd: als iemand anders de sleutel onderschept, kan hij zomaar al onze berichten lezen.
Gelukkig is er een oplossing om de sleutel veilig bij de andere partij te krijgen.
Die oplossing heet ‘asymmetrische versleuteling’.
De Public Key Exchange
In plaats van ieder bericht te versleutelen met ons eigen slot en de sleutel apart mee te sturen, draaien we het probleem om: we wisselen eerst onze sloten uit, versturen onze berichten met het slotje van de andere partij, en houden de sleutel zelf bij ons.
Voor we berichten gaan versturen, wisselen we dus ‘sloten’ uit (omdat het slotje eigenlijk een wiskundige rekensleutel is, heet deze verwarrend genoeg ‘public key’ in het Engels).
In feite sturen we dus een open slot naar de externe partij, en zeggen “als je veilig met ons wilt communiceren, gebruik dan dit slot”. Wij houden zelf de sleutel, en kunnen de versleutelde berichten die we ontvangen ontsleutelen. De andere partij doet dit ook. Als wij bijvoorbeeld naar DigiD praten, gebruiken we hun ‘slotje’. Zij ontsleutelen de berichten met hun eigen sleutel. Zo communiceren we altijd veilig.
De Certification authority (CA)
Dit publiek uitwisselen van sleutels kent echter een probleem: hoe weten we dat het slotje echt van de persoon is waarmee we willen praten? Misschien stuurt iemand ons wel een slot onder een valse naam. Dan praten we wel versleuteld, maar kan de verkeerde partij meelezen!
We moeten er dus voor zorgen dat de ‘publieke’ uitwisseling van de slotjes op veilige wijze gebeurd. Iemand die wij vertrouwen moet voor ons controleren dat het slotje dat wij ontvangen echt van de juiste partij komt. We vragen dus een derde partij mee te kijken, de Certification Authority (CA). De CA controleert of een slotje authentiek is en ondertekent allen als dat het geval is een beveiligingscertificaat. Dat certificaat bevat een verklaring die stelt “Hier is een public key. Deze public key is echt van Zaaksysteem.nl”.
Met een certificaat in de hand weet de ontvanger dat hij een ‘gecertificeerd’, veilig slotje heeft ontvangen.
Zo’n ondertekend certificaat moeten we zelf aanvragen bij de CA, via een zogenaamd Certificate Signing Request (CSR).
CSR
Het Certificate Signing Request bevat de volgende informatie:
Distinguished Name (DN)
This is fully qualified domain name that you wish to secure e.g. 'www.example.com’ or 'mail.example.com'. This includes the Common Name (CN) e.g. 'www' or 'mail'
Business name / Organization Usually the legal incorporated name of a company and should include any suffixes such as Ltd., Inc., or Corp.
Department Name / Organizational Unit e.g. HR, Finance, IT
Town/City e.g. London, Waterford, Paris, New York, Dhaka, Kochi
Province, Region, County or State This should not be abbreviated e.g. Sussex, Normandy, New Jersey
Country The two-letter ISO code for the country where your organization is located e.g. GB, FR or US etc..
An email address An email address to contact the organization. Usually the email address of the certificate administrator or IT department
PEM / CRT
De Certificate Authority controleert wat in het CSR-bestand staat, en als de informatie klopt, ondertekent de CA de aanvraag. Het stuurt vervolgens een bestandje in PEM- of CRT-formaat op, met daarin dezelfde gegevens, plus hun ondertekende verklaring dat de key te vertrouwen is.
Zaaksysteem API & koppelingen
Als Zaaksysteem met externe API's wil praten, gebeurt dit ook over beveiligde verbindingen.
Zaaksysteem controleert de verbinding aan de hand van een set CA-certificaten die per koppelprofiel worden geconfigureerd. De "basis-set" van CA's, zoals bijvoorbeeld meegeleverd in webbrowsers, wordt niet gebruikt.
Soms wil de server ook weten of wij zijn wie we zeggen te zijn, hiervoor kan een "client certificate" gebruikt worden. Vaak is dit een "self-signed" certificaat, maar het kan ook een door een CA uitgegeven certificaat zijn.
Meer
Zie ook: