Centric connect.engage.succeed

Beveiligingscertificaten en andere vergissingen

Geschreven door Redactie Craft - 03 juni 2016

Redactie Craft
Ik liep door de gangen van ons cloudcentrum naar de vergaderzaal. Een collega rende langs mij heen. Gevolgd door een tweede. En in zijn kielzog een hele groep. Met moeite hield ik iemand staande. "De vergadering is afgelast. Het is nu alle zeilen bijzetten!"

Eenmaal op mijn kamer hoorde ik dat ‘DigiNotar’ was gevallen. Toen begreep ik dat al die collega's druk in de weer waren om van honderden klanten met platgelegde websites de certificaten te vervangen. Dit was mijn eerste desastreuze kennismaking met certificaten. En helaas niet mijn laatste…

In het ontwikkelproces bestaan er in de praktijk nogal eens misconcepties over het werken met certificaten. Met als gevolg een langer en stroever (lees: frustrerend voor de ontwikkelaar) proces. En dan hebben we het nog niet eens over het fout installeren van certificaten, wat leidt tot foute conclusies over de geproduceerde software.

Certificaten

Certificaten zijn kleine brokjes cryptografisch materiaal die je op een computer installeert. Ze worden gebruikt om beveiligde verbindingen over het internet te maken. Of om berichten mee te versleutelen en te ondertekenen. Sommige certificaten kun je zelf produceren, maar de meer algemene certificaten voor internetverkeer koop je via een Certificate Authorithy. Bij dat kopen komt nogal wat kijken; soms is zelfs een controle nodig omtrent de eigen identiteit waarvoor de notaris wordt ingeschakeld.

Werken met eigen of ingekochte certificaten is soms lastig. Zo maakt het verschil of er in de ontwikkelfase van de software op één ontwikkelmachine wordt gewerkt, op meer dan één machine (met meerdere machines binnen het huidige domein van de Active Directory) of dat er al wordt getest over het internet.

Eén machine

Ontwikkeling van software begint meestal op één machine, namelijk die van de eerste ontwikkelaar. Indien hij/zij alleen werkt, dan is het voor het initieel ontwikkelen en testen vaak voldoende om met één zelf ondertekend certificaat te werken in zijn/haar persoonlijke certificaten store. Dit certificaat hoeft in eerste instantie niet aan een root certificaat verbonden te zijn. Dit is de meest simpele situatie, die in de praktijk niet direct leidt tot problemen. Heeft een ontwikkelaar hier nog geen ervaring mee? Dan moet hij/zij de weg worden gewezen naar de juiste tools (zie de links onderaan). Ontwikkelaars die bekend zijn met de administratietools van de internetserver IIS, kunnen daar via submenu's een eigen certificaat aanmaken voor hun persoonlijke certificaten store.

Een machine - Operating systeem

Meerdere machines

Ontwikkelaars werken - net zoals wolven - in roedels. Teams noemt men dat wel eens. Als je daar meer dan één van hebt, dan heb je ook meerdere machines waarop ontwikkeld wordt. Bij veilige applicaties is dat dan vaak ook het eerste moment waarop veilige HTTPS-verbindingen getest worden ‒ van de ene machine naar de andere. En dan is het niet meer voldoende om op één van die machines zelf een certificaat aan te maken. In dat geval is het noodzakelijk om een gemeenschappelijk - zelf gegenereerd - root-certificaat te maken en om dat certificaat te verspreiden. Het certificaat waarop een verbinding draait, kan dan van dit root certificaat worden afgeleid.

Om de feestvreugde te verhogen: het root certificaat kan maar beter - net zoals in het echt - in de zogenaamde machine store gezet worden, in de map root certificerings instanties (Root Certified Authorities). Gelukkig is dat voor het team maar een eenmalige actie binnen het project. En als je het goed organiseert, is het zelfs een eenmalige actie voor de hele afdeling. En gelukkig kan ook dit root certificaat zelf worden aangemaakt, zonder het te hoeven kopen. Alleen: hier voldoen de administratietools van IIS niet meer en moet je met command line-tools aan de slag.

Voor wie zich helemaal wil uitleven: lees hier hoe je zelf root en ssl certificaten genereert.

Meerdere machines - lokaal netwerk

Een domeincertificaat

Om beter te testen en de situatie in ‘de echte wereld’ te simuleren, moet het root certificaat vervolgens gekoppeld worden aan de domein-controller van de eigen organisatie. Een domein-controller is een machine die de namen achter de interne internetadressen (namen naar IP-nummers) vertaalt. Dit maakt het mogelijk om vanuit de gehele organisatie en vanaf alle machines de beveiligde verbinding te benaderen. Netwerkbeheerders die toegang en rechten hebben tot de domeincontroller en de Microsoft Active Directory (AD) kunnen zo’n root certificaat vrij eenvoudig genereren. Het grootste struikelblok in de meeste organisaties is het vinden van een beheerder die even de tijd en moeite neemt om te helpen bij het genereren van een dergelijk root certificaat en het plaatsen van het certificaat op de benodigde machines.

Voor wie zelf hiertoe de rechten heeft, is hier is een goede beschrijving hoe men dit aanmaakt.

Meerdere machines binnen één lokaal domein

Een ‘echt’ certificaat

Bedrijven als Verisign, Thawte, Comodo of Symantec laten hun eigen root certificaat meeleveren met het operating systeem, zoals Windows of iOS. Een certificaat dat je van deze organisaties kunt kopen, wordt aan dit root certificaat gekoppeld. Het mooie is dat het overal werkt, waar het operating systeem staat en draait. En omdat ze eerst via je eigen notaris jouw identiteit – of die van je bedrijf – controleren, kunnen anderen in de wereld er dus vanuit gaan dat de beveiligde verbinding echt van jou komt.

Nadeel is dat je zo’n certificaat moet bestellen en betalen. En dat de levering even duurt, doordat de identiteitscontrole nog moet plaatsvinden. Daarom is zo’n ‘echt’ certificaat meestal ook de allerlaatste stap die je in het ontwikkelproces wilt ondernemen (en zo lang mogelijk wilt uitstellen).

Productie situatie

Vergissingen

De ‘vergissingen’ in de titel verwijzen naar de vergissingen en fouten van het werken met de zelf gegenereerde certificaten, alvorens de ‘echte’ certificaten worden uitgeprobeerd. Omdat de ‘echte’ certificaten nogal wat geld kosten – en omdat de levertijd het ontwikkelwerk vertragen – willen ontwikkelafdelingen het aanschaffen van de ‘echte’ certificaten zo lang mogelijk uitstellen.

Dit uitstellen wordt meestal gedaan door zelf een self-signed certificate te genereren. En in het geval van één machine werkt dat prima. Meestal zal de ontwikkelaar op de eigen machine een IIS webserver draaien en ook de ontwikkelde client applicatie (bijvoorbeeld in een browser). Er kan dan een beveiligde verbinding (HTTPS) gelegd worden tussen de server en de browser.

Omdat één zo’n certificaat werkt, zijn mensen al snel geneigd deze aanpak ook te gebruiken bij twee machines op het moment dat zij voor het eerst de server en browser qua machine splitsen. En helaas, soms werkt dat per vergissing. Wellicht omdat de machines in hetzelfde sub net staan. De exacte reden is niet helemaal duidelijk. Vervelender is: meestal werkt het niet. De organisatie moet dan minimaal een eigen root certificaat genereren. En dat kan ook een zogenaamd ‘self-signed certificate’ zijn.

Maar indien de machines niet in hetzelfde sub net staan, dan is het al nodig om een root certificaat te genereren dat aan de DNS-server (Domain Name Server) hangt. Al kan het nog steeds een sigaar uit eigen doos zijn. Want dat is een zelf ondertekend certificaat natuurlijk.

Pas in een productiesituatie dient zowel het SSL-certificaat als het root certificaat van een ‘echte’ certificeringsautoriteit afkomstig te zijn. Dit is in de tekening aangegeven met groene vinkjes.

Wat er in de praktijk vaak fout gaat, is dat er dus één certificaat gegeneerd wordt: het SSL-certificaat. En dat dit certificaat wel tussen de machines gedeeld wordt op een ontwikkelafdeling, maar dat men vergeet er een root certificaat bij te doen. En dan werkt het – meestal – niet. En niemand die snapt waarom de HTTPS SSL/TLS-verbinding maar niet tot stand wil komen. Hier worden soms letterlijk weken zoekwerk aan verspild.

Moraal van het hele verhaal

Ja: het is wel degelijk mogelijk om in een pre-productie situatie je eigen ondertekende certificaten te genereren en te gebruiken. Denk er dan wel aan dat je niet maar één certificaat via de IIS administrator tool genereert, maar een gedegen root certificaat én een SSL-certificaat.

Oja, lees vooral de verhalen achter de links in dit artikel door. Ja, het is taaie stof. En ja, het kost veel tijd om het allemaal te doen. Maar het is zeker de moeite waard!

Tags:ALM

     
Reacties
  • Gemeente Roermond
    Frans
    05 juni 2016
    Geen
Schrijf een reactie
  • Captcha image
  • Verzenden