Follow Us on Twitter

Transport layer security: je eigen Certificate Authority

Gepubliceerd in

Wanneer systemen onderling communiceren, en vooral wanneer het gevoelige informatie betreft, wordt deze informatie veelal versleuteld verstuurd. Om te versleutelen zijn er certificaten nodig. Deze kunnen worden gekocht bij een Certificate Authority (CA), maar kunnen ook zelf gemaakt worden en in eigen beheer worden gehouden. In dit Whitebook laat ik zien  hoe in een IT SOA landschap gebruik kan worden gemaakt van eigen certificaten voor authenticatie en autorisatie.

Public Key Infrastructure

Als we informatie dat over de lijn gaat willen versleutelen, hebben we te maken met Transport Layer Security (TLS). TLS is gebaseerd op de Public Key Infrastructure (PKI). De cryptografische sleutels die worden gebruikt binnen de PKI zijn zgn. asymmetrische sleutels. Deze asymmetrische sleutels vormen een uniek paar: de public en private sleutels. de publieke sleutel is openbaar en kan worden gebruikt om een bericht te versleutelen en signeren. De private sleutel is niet openbaar, en is de enige sleutel die het bericht weer kan ontcijferen en verifiëren. Het is dus belangrijk zorgvuldig om te gaan met de private sleutel, terwijl de publieke sleutel wordt gedistribueerd met ketenpartners.

Wat is een Certification Authority?

De PKI sleutels (certificaten) worden uitgegeven door een zgn. Certification Authority (CA). De CA is een algemeen vertrouwde partij en certificeert het eigendom van een publiek certificaat door het te signeren met haar eigen private certificaat. Gebruikers van het publieke certificaat weten hierdoor wie het eigendom heeft van dit publieke certificaat (en dus ook het bijbehorende private certificaat), omdat dit geverifieerd is door de CA. De gebruikers baseren hun vertrouwen op het feit dat de CA haar private certificaat veilig in eigen beheer heeft, en certificaten volgens de regels uitgeeft. Er zijn ongeveer een vijftigtal wereldwijde CA's die algemeen vertrouwd worden. Dat dit vertrouwen kan worden geschaad werd pijnlijk duidelijk in de DigiNotar Affaire in 2011, toen bleek dat het private certificaat van deze CA door hackers is misbruikt om frauduleuze certificaten uit te geven[0].

Naast het uitgeven van certificaten kan een CA ook certificaten intrekken. Deze worden bijgehouden in een Certificate Revocation List (CRL).

Je eigen Certification Authority

Het is niet ongebruikelijk dat applicaties of partijen die met elkaar integreren in een IT landschap zichzelf authenticeren  en autoriseren op basis van PKI certificaten. Om volledige controle te hebben over welke certificaten toegang hebben en krijgen tot systemen, kan er worden besloten een eigen CA te gebruiken. Deze CA geeft vervolgens de certificaten uit die mogen verbinden met de  systemen in kwestie.

Het grote verschil met “echte CA” is in dit geval dat deze niet wereldwijd wordt vertrouwd. Als er met een internet browser bijvoorbeeld een website wordt benaderd via HTTPS waarop een “zelfgemaakt” certificaat staat, zal de browser een beveiligingswaarschuwing geven. Echter, intern binnen een organisatie, of binnen een bepaald specifiek IT-landschap hoeft dit geen probleem te zijn. Interne browsers kunnen bijvoorbeeld het publieke certificaat van de eigen CA vertrouwen, en communicerende systemen kunnen ook het publieke certificaat van de CA als vertrouwd certificaat opnemen in hun keystores. Immers, het is je eigen CA, die kan je hopelijk wel vertrouwen!

Je eigen CA is eenvoudig te maken (maar er zijn tevens ook vele opties in te stellen). Elk Unix-systeem komt meestal standaard geleverd met de open source tool OpenSSL[1] (ook voor Windows te krijgen overigens).

Om te beginnen met het uitgeven van de eigen certificaten moet allereerst de publieke en private sleutel van de CA gemaakt worden. Om een CA te maken die 1825 dagen geldig is, kan het volgende commando worden gebruikt:

openssl req -new -x509 -sha256 -extensions v3_ca -keyout myca-private.key -out myca-public.crt -days 1825

De tool zal vragen om een wachtwoord om de private sleutel van deze CA te beveiligen. Daarnaast zullen enkele identificerende elementen moeten worden opgegeven (Country, State, a.d). Deze informatie vormt de Subject-regel van het certificaat. Deze regel is een human readable identificatie voor het certificaat. Hieronder staat een voorbeeld van de gevraagde input:

Country Name (2 letter code) [XX]:NL
State or Province Name (full name) []:Utrecht
Locality Name (eg, city) [Default City]:Nieuwegein
Organization Name (eg, company) [Default Company Ltd]:Whitehorses BV
Organizational Unit Name (eg, section) []:Whitebooks
Common Name (eg, your name or your server's hostname) []:whitebook demo CA
Email Address []:info@whitehorses.nl

De uitkomst is een “X.509” privaat certificaat waarmee de CA andere certificaten kan signeren (certificeren), en het publieke certificaat van de CA zelf. Het is een zgn. SHA256 certificaat, iets wat ook wordt gebruikt binnen de PKI overheid. Als het publieke certificaat wordt geïnspecteerd met:

openssl x509 -text -in myca-public.crt

Zien we o.a. :

Issuer: C=NL, ST=Utrecht, L=Nieuwegein, O=Whitehorses BV, OU=Whitebooks, CN=whitebook demo CA/emailAddress=info@whitehorses.nl
Validity
  Not Before: Jan  9 19:09:49 2012 GMT
  Not After : Jan  7 19:09:49 2017 GMT
Subject: C=NL, ST=Utrecht, L=Nieuwegein, O=Whitehorses BV, OU=Whitebooks, CN=whitebook demo CA/emailAddress=info@whitehorses.nl

en verderop:

X509v3 Basic Constraints:
CA:TRUE

Omdat de “Issuer” (identificatie van de CA die het certificaat heeft gesigneerd) gelijk is aan de “Subject” (identificatieregel van dit specifieke certificaat) kunnen we opmaken dat het een selfsigned certificaat is. De “CA:TRUE” geeft aan dat het een CA certificaat is, en dus certificaten kan uitgeven.

Naast de command line tooling van OpenSSL zijn ook andere open source oplossingen die een wellicht gebruikersvriendelijkere  oplossing vormen. Een bekende open source web-based CA tool is bijvoorbeeld EJBCA [2], maar ook RedHat heeft een commerciële toepassing genaamd Certificate System [3]. Voor een desktop Linux systeem is GnoMint [4] een veelgebruikte toepassing.

Authenticatie en autorisatie met certificaten

Omdat een CA het eigendom van een certificaat certificeert, is een certificaat uitermate geschikt om gebruikers te identificeren. Als er wordt uitgegaan dat de houder van het private certificaat dit rechtvaardig in bezit heeft, kan het de houder authenticeren. Certificaten om een gebruiker (een client) te authenticeren worden veelal client certificaten genoemd. Met een client certificaat kan de client tijdens het verbinden met een server worden geauthenticeerd:  in de transportlaag dus. Vaak is de transportlaag gebaseerd op SSL over HTTP (HTTPS). De client authenticatie wordt daarom ook wel two-way SSL genoemd. Hieronder is beknopt samengevat hoe dit in zijn werk gaat:


 
Alleen de houder van de private sleutel kan het client certificaat correct aanbieden, want naast het toesturen van het publieke client certificaat, wordt deze ook versleuteld verstuurd. De server controleert of de versleuteling is gedaan met het private certificaat van de client.

Eén van de controles die de client en server kunnen uitvoeren is het controleren van het ontvangen certificaat tegen de CRL. Zo kan worden gecontroleerd of de CA het certificaat wellicht heeft ingetrokken.

Vaak bevat een server een certificaten opslag, een keystore, met daarin de publieke certificaten die worden toegelaten. Deze wordt meestal de trust store genoemd. Als een certificaat uit deze keystore overeenkomt met een aangeboden client certificaat, wordt de two-way SSL handshake voltooid. De client is dan geauthenticeerd.

Voor de autorisatie wordt meestal de Common Name (CN) uit het certificaat gebruikt. De Oracle WebLogic server bijvoorbeeld heeft ingebouwde providers in haar security realm om specifieke data uit een binnenkomend certificaat te extraheren. Een CN kan worden gekoppeld aan een WebLogic gebruiker die bepaalde rechten en rollen heeft binnen de applicaties die draaien op de server.

Voorbeeld

Eerder in dit Whitebook is laten zien hoe een CA certificaat wordt gemaakt. Deze kan worden gebruikt voor het uitgeven en signeren van certificaten.  De CA geeft deze certificaten uit op basis van een Certificaat Signing Request (CSR). De CSR wordt door de aanvrager gegenereerd:

openssl req -new -keyout myown.key -out myownkey-request.csr -days 365

Bij het aanmaken van een CSR door een gebruiker worden tevens de private en publieke certificaten aangemaakt.  De CSR bevat dit publieke certificaat en is gesigneerd door het private certificaat.  Op deze manier kan de CA zien dat de CSR is aangemaakt door de bezitter van de private sleutel.  Het gemaakte CSR bestand zal moeten worden verstuurd naar de CA. Ook bij deze stap zullen de gebruikelijke data worden gevraagd:

Country Name (2 letter code) [XX]:NL
State or Province Name (full name) []:Utrecht
Locality Name (eg, city) [Default City]:Utrecht
Organization Name (eg, company) [Default Company Ltd]:Laurens van der Starre
Organizational Unit Name (eg, section) []:Whitebook Author
Common Name (eg, your name or your server's hostname) []:AdminConsoleKey-123
Email Address []:

De CA zal op basis van dit CSR een certificaat uitgeven. Omdat de CA de eigenaar van het certificaat certificeert is het belangrijk het certificaat pas uit te geven als de identiteit is geverifieerd.

De CA creëert een certificaat op basis van een CSR als volgt:

openssl ca -policy policy_anything -keyfile myca-private.key -cert myca-public.crt -out myown-publicserver.crt -infiles myownkey-request.csr

De uitkomst van dit commando is een publiek certificaat uitgegeven door onze eigen CA. Dit kan direct worden gezien aan het “Issuer”-gedeelte in het nieuwe certificaat.

Issuer: C=NL, ST=Utrecht, L=Nieuwegein, O=Whitehorses BV, OU=Whitebooks, CN=whitebook demo CA/emailAddress=info@whitehorses.nl
Validity
  Not Before: Jan  9 19:40:58 2012 GMT
  Not After : Jan  8 19:40:58 2013 GMT
Subject: C=NL, ST=Utrecht, L=Utrecht, O=Laurens van der Starre, OU=Whitebook Author, CN=AdminConsoleKey-123

Het nieuwe publieke certificaat kan terug naar de aanvrager: het is nu gesigneerd en gecertificeerd door de CA.

Natuurlijk kan de CSR en uiteindelijk het certificaat, ook door de CA zelf worden gemaakt. In dat geval hoeft de aanvragen niet zelf de private sleutel te maken. Echter moet de aanvrager nu niet alleen het publieke certificaat, maar ook het private certificaat ontvangen. De CA moet echter wel vertrouwd omgaan met de private certificaten van de clients, of simpelweg verwijderen.

Het is gebruikelijk deze data in een zgn. PKCS#12 container af te leveren. Dit is eenvoudig gezegd een binair bestand met daarin het publieke certificaat van de CA, de private sleutel, en het nieuwe gegenereerde publieke certificaat. Deze container kan OpenSSL ook maken, op basis van een het nieuw private en publiek certificaat als invoer :

openssl pkcs12 -export -in myown-publicserver.crt -inkey myown.key -certfile myca-public.crt -name "MyCRT" -out myown-p12.p12

De uitkomst is een “p12”-file, die tevens direct in de browser kan worden geïmporteerd. Als een web pagina/applicatie een client-certificaat vereist, kan de gebruiker een certificaat kiezen uit de lijst van geïmporteerde certificaten en deze aan de server aanbieden: de browser zal de gebruiker de keuze geven uit een lijst van geïmporteerde certificaten. Zo kan een web applicatie de gebruiker authenticeren. Omdat er een wachtwoord op de private sleutel zit, is deze niet door iedereen te gebruiken.

Natuurlijk kunnen deze certificaten ook worden gebruikt door systemen die met elkaar integreren. In een SOA landschap wordt over het algemeen gecommuniceerd via SOAP over http. In de transport laag kan SOAP over HTTPS met client authenticatie worden afgedwongen.

Conclusie

Het beveiligen op transport niveau kan eenvoudig gebeuren met eigen gemaakte certificaten. Het voordeel van eigen certificaten is dat de volledige controle over aan wie certificaten worden uitgegeven. Certificaten zijn tevens een makkelijke manier om bepaalde gegevens op bijvoorbeeld web portalen af te schermen voor onbevoegden.
In dit Whitebook is met OpenSSL getoond wat nodig is om eenvoudig zelf certificaten uit te geven. Natuurlijk is dit maar de top van de ijsberg. Er zijn vele opties binnen een OpenSSL om qua inrichting en opties in het CA certificaat. Naast OpenSSL zijn er diverse grafische tools om het uitgeven en beheren van certificaten te ondersteunen. Bij de referenties zijn enkele opgenomen als link.

Als de certificaten eenmaal zijn gemaakt, kunnen deze in het IT landschap worden opgenomen. Applicatie servers zoals WebLogic en JBoss, en Middleware zoals de Oracle Service Bus bieden de mogelijkheden eenvoudig two-way SSL op te zetten. Daarnaast bevatten applicatie servers zoals WebLogic ingebouwde features om een client certificaat te mappen op bevoegdheden binnen de server, waardoor een gebruiker ook kan worden geautoriseerd op basis van haar aangeboden client certificaat.

Referenties:

[0] De DigiNotar hack
[1] OpenSSL
[2] EJB CA
[3] RedHat Certificate System
[4] GnoMint CA Management Tool

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.