7 OpenSSL en de Certificate Authority

deel 7_7_1-3-AV25.qxp:deel 7_6-AV20

04-10-2007

14:00

Pagina 1

Security

7/7 OpenSSL en de Certificate Authority 7/7.1

Inleiding

Voor veel diensten die door een moderne server aangeboden kunnen worden, is additionele beveiliging nodig. Deze beveiliging wordt gerealiseerd door middel van SSL-certificaten. Het is mogelijk dat elke service voor zichzelf deze certificaten aanmaakt, maar in dat geval is er weinig garantie voor eindgebruikers dat het certificaat ook daadwerkelijk te vertrouwen is. Daarom wilt u waarschijnlijk gebruikmaken van een Certificate Authority. In dit hoofdstuk leert u hoe u deze aanmaakt op basis van OpenSSL. In oudere versies van Open Enterprise Server werd gebruikgemaakt van certificaten uit eDirectory. Sinds Open Enterprise Server versie 2 kunt u de certificaten ook direct vanuit Linux beheren. In dit hoofdstuk ligt de nadruk op het beheer van encryptie en certificaten in een pure Linuxomgeving. Dit betekent dat deze informatie van toepassing is in een omgeving waar u OES versie 2 geconfigureerd hebt om met Linux-certificaten te werken, evenals in pure SLES-omgevingen.

Novell Netwerkoplossingen, aanvulling 25

7/7.1-1


04-10-2007

14:00

Pagina 2

OpenSSL en de Certificate Authority

7/7.1-2



04-10-2007

14:00

Pagina 1

Security

7/7.2

Introductie tot de cryptografie

In vrijwel alle vormen van encryptie speelt de Public Key Infrastructure (PKI) een hoofdrol. Ook bij het configureren van uw eigen Certificate Authority is er een hoofdrol voor PKI weggelegd. Maar wat is nu precies een PKI? Voordat we kunnen gaan behandelen hoe public/private key-paren in verschillende vormen van encryptie toegepast worden, bespreken we hoe encryptie werkt en wat de rol daarin is van een PKI.

Ciphertext

7/7.2.1 Geschiedenis Bij de toepassing van cryptografie gaat het erom een leesbaar bericht om te zetten in tekst die niet langer leesbaar is. Dit laatste wordt in het Engels de zogenaamde ciphertext genoemd (we zullen hier de Engelse begrippen waar nodig hanteren om verwarring te voorkomen). Cryptografie wordt al zeer lang ingezet: al in de vroegste geschiedenis was het zaak ervoor te zorgen dat berichten die verstuurd werden door een koerier, niet door de vijand onderschept konden worden. Omdat cryptografie al zo lang gebruikt wordt, wordt ook cryptoanalyse al zeer lang ingezet. Dit is de wetenschap die ervoor zorgt dat versleutelde berichten ontcijferd kunnen worden, ook zonder dat daarvoor de code beschikbaar is die gebruikt is om het bericht te versleutelen. In het verleden werd geprobeerd de cryptografie zo goed mogelijk te maken door de algoritmes die ervoor gebruikt werden zoveel mogelijk geheim te houden. Een voorbeeld hiervan is de Enigma-machine die in de Tweede Wereldoorlog gebruikt werd om versleutelde berichten te verzenden. Toen de Engelsen echter een duikboot onderschepten die zo’n machine aan boord had, was het een koud kunstje het gebruikte algoritme te achterhalen. Er


7/7.2-1


04-10-2007

14:00

Pagina 2


bleek in de machine namelijk een ontwerpfout te zijn geïmplementeerd die dit mogelijk maakte. Om die reden zijn de sterkste encryptie-algoritmes die vandaag de dag gebruikt worden dan ook open algoritmes. Juist doordat deze wiskundige formules door iedereen onderzocht kunnen worden, kan een dergelijk hoog niveau van beveiliging bereikt worden. De beveiliging van de algoritmes wordt dus juist verbeterd doordat er meerdere mensen naar kunnen kijken. Hierdoor kunnen de meeste moderne algoritmes niet of nauwelijks gekraakt worden (al draaien er voortdurend programma’s die trachten het algoritme toch te kraken). De enige manier om een bericht te ontcijferen, is dus door te beschikken over de sleutel die daarvoor bestemd is. Het is dan ook vrij zinloos om van overheidswege te bepalen dat een encryptie-algoritme bijvoorbeeld onder de wapenwetgeving valt en niet geëxporteerd mag worden. 7/7.2.2 Substitution en transition Oorspronkelijk werd voor de versleuteling van berichten gebruikgemaakt van twee soorten sleutels, de zogenaamde substitution ciphers en transposition ciphers. Van deze sleutels is het substitution cipher het primitiefst: elke letter wordt namelijk vervangen door een andere letter. De enige toepassing van een dergelijke cryptografie is tegenwoordig nog in dagbladen, waar met dergelijke ciphers leuke puzzels gemaakt kunnen worden. Substitution ciphers kunnen wel ingewikkelder gemaakt worden, bijvoorbeeld door ze niet op afzonderlijke letters toe te passen, maar op volledige blokken tekst, maar het blijft een zwakke encryptiemethode. Iets ingewikkelder is een transposition cipher. Hierbij worden letters niet door andere letters vervangen, maar wordt

7/7.2-2



04-10-2007

14:00

Pagina 3

Security

de volgorde van de letters in een tekst door elkaar gehaald. Zo kan bijvoorbeeld een tekst verstopt worden in een andere tekst door steeds de zesde letter te lezen. Hieronder vindt u een eenvoudig voorbeeld van de transitiemethode: qwjdhpchwaicfblqbsdlpwefo

Kent u de gebruikte sleutel niet, dan is het redelijk lastig te achterhalen wat de originele tekst is. Als u echter weet dat u steeds naar de vijfde letter moet kijken, dan wordt dit toch een puzzel die u op kunt lossen. Het nadeel van een dergelijk algoritme is dat als u eenmaal een stukje tekst gevonden hebt, u uiteindelijk de volledige tekst ook kunt vinden. Voor mensen is een eenvoudig voorbeeld zoals hierboven prima op te lossen. Op het moment dat de methode ingewikkelder wordt, wordt het voor mensenhersenen wel erg lastig, maar dan kan gewoon een computer ingezet worden. Het heeft om die reden niet zo heel veel zin om bijvoorbeeld de substitutiemethode en de transitiemethode met elkaar te combineren: het blijft uiteindelijk gewoon een zwakke methode.

One time pad

7/7.2.3 Eenmalige sleutels Om het moeilijker – zo niet onmogelijk – te maken een encryptiemethode te doorzien, is het nodig dat gegevens maar éénmaal gebruikt worden. We hebben het dan over de methode die bekendstaat als het zogenaamde one time pad; in deze tekst zullen we de methode ook aanduiden als die van de eenmalige sleutel. Dit is een patroon met gegevens dat volkomen willekeurig gegenereerd wordt en opgeslagen wordt op een gegevensdrager. Vervolgens worden twee kopieën gemaakt van dit stuk willekeurige data: één kopie gaat naar de persoon die een bericht wil versturen en het andere brok data gaat naar de beoogde ontvanger van


7/7.2-3


04-10-2007

14:00

Pagina 4


het bericht. De afzender gebruikt deze eenmalige sleutel om de gegevens te versleutelen en verwijdert vervolgens ook de sleutel. De ontvanger gebruikt dezelfde eenmalige sleutel om het bericht te ontcijferen. De techniek van de one time pad is vaak gebaseerd op modulus. Hierbij is het van belang dat het one time pad even veel tekens bevat als het bericht dat versleuteld moet worden. Zo is er voor elk teken een overeenkomstig teken. Als dit bijvoorbeeld toegepast wordt op letters, kunnen de letters bij elkaar opgeteld worden. Stel dat in het oorspronkelijke bericht een A staat en in de one time pad voor dat teken een C. Dan worden die bij elkaar opgeteld en is het resultaat (1 + 3 in dit geval) een D, de vierde letter. Mocht het voorkomen dat de optelling een waarde krijgt die groter is dan 26, dan wordt het getal 26 ervan afgetrokken. Y (25) + S (19) levert dus een R (18) op. De methode van de one time pad is niet te kraken, omdat er voor elk teken in het oorspronkelijke bericht een teken is om het te versleutelen en omdat het one time pad niet hergebruikt wordt. Het probleem echter is dat de implementatie van deze methode vrij lastig is. Ten eerste moeten er continu nieuwe eenmalige sleutels gegenereerd worden en daarnaast moet u zorgen dat deze sleutels op een veilige manier verzonden worden. Welke methode ook gebruikt wordt, tijdens het transport van de eenmalige sleutel kan een dief toeslaan en zich de sleutel eigen maken. Dit geldt zeker als de eenmalige sleutel via een netwerk verstuurd wordt. 7/7.2.4 Symmetric keys Een tweede techniek voor encryptie die ook vandaag de dag nog regelmatig wordt ingezet, is symmetric keyencryptie. Hierbij wordt dezelfde sleutel gebruikt voor het versleutelen van gegevens als voor het ontcijferen van

7/7.2-4



04-10-2007

14:00

Pagina 5

Security

3DES

gegevens. Er zijn verschillende algoritmes die gebruikt worden in een symmetric key-omgeving waarvan 3DES (‘triple DES’) momenteel de populairste is. Dit algoritme is zo goed dat het onmogelijk is een bericht te ontcijferen als u alleen in het bezit bent van het versleutelde bericht. Net als bij de one time pad-methode echter is het probleem dat de sleutels uitgewisseld moeten worden op een veilige manier. Distributie van sleutels is een algemeen probleem in cryptografie. U moet ervoor zorgen dat dit uitwisselen absoluut risicoloos is. De persoon die een sleutel onderschept, is namelijk in staat om alle berichten die met die sleutel versleuteld zijn weer te ontcijferen. Symmetric key-encryptie heeft een groot voordeel en een groot nadeel. Het grootste nadeel is dat het vrij eenvoudig is en dat degene die zich de sleutel eigen maakt waarmee berichten versleuteld zijn, in staat is alle berichten te ontcijferen. Om een bericht te versleutelen met symmetric key-encryptie wordt de unieke sleutel aan het algoritme gegeven, dat er vervolgens de originele tekst mee versleutelt. Als hetzelfde algoritme vervolgens met dezelfde sleutel op de versleutelde tekst toegepast wordt, levert dat de ontcijferde tekst op. Deze eenvoud is gelijk ook het grootste voordeel van symmetric key-encryptie: de methode is razendsnel en leent zich daarom prima voor toepassingen waarbij grote hoeveelheden gegevens versleuteld moeten worden. 7/7.2.5 Public key-algoritmes De beste oplossing voor het probleem van het uitwisselen van sleutels is het gebruik van public key-algoritmes. Diffie en Helmann waren in 1976 de uitvinders van deze nieuwe cryptografische methode. De essentie van public


7/7.2-5


04-10-2007

14:00

Pagina 6


key-cryptografie is dat er een sleutelpaar gebruikt wordt: de publieke sleutel (public key) en de privésleutel (private key). De publieke sleutel is beschikbaar voor iedereen en kan dus ook vrij gedistribueerd worden; de private key daarentegen moet goed geheimgehouden worden. Op basis van moderne algoritmes is het nagenoeg onmogelijk om, met de public key alleen, terug te rekenen wat de private key was. Met de public key kunnen gegevens versleuteld worden. Deze gegevens kunnen vervolgens alleen gelezen worden door de eigenaar van de bijbehorende private key. Om public key-cryptografie te kunnen gebruiken moet u dus altijd beschikken over de public key van de andere partij.

One way

De essentie van public key-cryptografie is de zogenaamde one way-functie: hierbij kan een berekening op eenvoudige wijze één kant op uitgevoerd worden, maar is het nagenoeg onmogelijk om deze berekening in de omgekeerde volgorde weer uit te voeren. Daarom is het ook dat gegevens die versleuteld zijn met een public key alleen met een private key ontcijferd kunnen worden. Het grote voordeel van public key-cryptografie is dat het probleem van de distributie van de sleutels is opgelost. Gelijktijdig is er ook een nieuw nadeel: het werkt namelijk relatief langzaam. Juist om die reden worden public keyencryptie en symmetric key-encryptie vaak naast elkaar gebruikt. Om te beginnen is er public key-encryptie om een beveiligde verbinding tot stand te brengen. Binnen deze beveiligde verbinding kunnen vervolgens zonder problemen symmetrische sleutels uitgewisseld worden. Zo vormen de beveiliging van public key-encryptie en de snelheid van symmetric key-encryptie samen een ideale oplossing.

7/7.2-6



04-10-2007

14:00

Pagina 7

Security

Een voorbeeld van een protocol waarbij public key-encryptie samen met symmetric key-encryptie wordt gebruikt, is secure shell (SSH), dat vooral in UNIX-omgevingen gebruikt wordt als veilig alternatief voor telnet. Hierbij vindt de volgende procedure plaats: 1. Beide partijen genereren een public/private keypaar. 2. Als de client contact opneemt met een server, krijgt de client diens public key aangeboden. Op basis van deze public key kan een beveiligde verbinding tot stand gebracht worden. 3. Nadat de communicatie tot stand gebracht is, genereert de gebruiker op basis van symmetric key-cryptografie een sessiesleutel die vervolgens versleuteld met de public key van de server teruggestuurd wordt naar de server. 4. De server ontcijfert de sessiesleutel met zijn private key. 5. De sessiesleutel is nu aan beide kanten bekend en kan gebruikt worden om met symmetric key-encryptie beveiligde gegevens uit te wisselen. 6. Voor extra beveiliging is de sessiesleutel slechts beperkte tijd houdbaar en wordt van tijd tot tijd een nieuwe sessiesleutel aangemaakt. Hierbij wordt de kans dat iemand die de gegevens onderschept de sleutel terug kan rekenen en zo alle verkeer kan onderscheppen tot een minimum beperkt. 7/7.2.6 Key-escrow Public key-cryptografie is nagenoeg perfect. Dit betekent dat gegevens die op deze wijze versleuteld uitgewisseld worden, echt niet door derden onderschept kunnen worden. Op zich prima, maar er is één nadeel: ook een overheid bijvoorbeeld die graag het verkeer wil monitoren dat door criminelen en terroristen verstuurd wordt, is niet


7/7.2-7


04-10-2007

14:00

Pagina 8


meer in staat dit versleutelde verkeer te onderscheppen. Daardoor ontstaat vanuit sommige kampen de roep om tegenmaatregelen. Key-escrow is zo’n tegenmaatregel. Achterdeurtje

Key-escrow is een achterdeurtje dat ervoor zorgt dat een derde partij altijd in staat is om ook versleutelde gegevens te ontcijferen. Eén manier om dit te realiseren is door een tweede private key te genereren op basis waarvan het versleutelde verkeer ook ontcijferd kan worden. Deze tweede sleutel echter moet dan veilig opgeslagen worden bij een overheid, of bijvoorbeeld bij een notaris. Tot op heden gaat het echter nog niet zo hard met dergelijke alternatieven. Dit komt omdat niemand het erover eens is wie dan de vertrouwde partij zou moeten zijn die de sleutels in bewaring heeft. Daarnaast is het vrijwel onmogelijk het gebruik van key-escrow ook daadwerkelijk af te dwingen. Wat weerhoudt iemand er immers van een public key-algoritme te gebruiken? De overheid of wie dan ook heeft daar geen zeggenschap over. Het enige wat een overheid zou kunnen doen, is het gebruik van cryptografie volledig verbieden en strafbaar stellen. Er zijn nog steeds landen waar dat gebeurt. 7/7.2.7 Toepassingen van cryptografie Er zijn over het algemeen drie gebieden waarop cryptografie wordt toegepast, en wel voor: • het versleutelen van berichten; • het vaststellen van identiteit; • het vaststellen dat er niets aan een bericht gewijzigd is. Versleutelen van berichten Het versleutelen van berichten was een van de eerste doelen waarvoor cryptografie überhaupt ontwikkeld is. Zoals

7/7.2-8



04-10-2007

14:00

Pagina 9

Security

eerder in dit hoofdstuk besproken, kunt u voor het versleutelen van berichten het beste gebruikmaken van symmetric key-encryptie. De reden hiervoor is de snelheid van symmetric key-algoritmes. Vaststellen van identiteit Een tweede gebied waarop encryptie gebruikt kan worden, is voor het vaststellen van identiteit. Public/private keyalgoritmes lenen zich hier uitstekend voor. Hierbij komt het erop neer dat de persoon die zich bijvoorbeeld aan wil melden bij een server, een bericht verstuurt en dit bericht voorziet van een checksum die versleuteld is met zijn eigen private key. Op het moment dat de server in staat is dit bericht te ontcijferen met de public key van deze gebruiker (die op dat moment al in het bezit van die server moet zijn), is daarmee de identiteit van die gebruiker vastgesteld.

Checksum

Vaststellen dat er niets aan een bericht gewijzigd is Een derde gebied waarvoor encryptie ingezet kan worden, is om vast te stellen dat er niets aan een bericht gewijzigd is. In het Engels wordt dit aangeduid als non-repudiation. Om dit te doen wordt op het bericht dat verzonden wordt een checksum losgelaten. Deze checksum is een sterk verkorte weergave van de totale inhoud van het bericht. De afzender van het bericht versleutelt deze checksum vervolgens met zijn private key. De ontvanger ontcijfert vervolgens de checksum weer met de public key die de ontvanger van de afzender heeft. Is dit onmogelijk, dan is daarmee gelijk duidelijk gemaakt dat er onderweg iets verkeerd gegaan is en er iemand met het bericht heeft zitten rotzooien. Klopt de checksum daarentegen, dan is daarmee gelijk vastgesteld dat er onderweg niets met het bericht gebeurd is en de ontvanger met het originele bericht aan het werk is.


7/7.2-9


04-10-2007

14:00

Pagina 10


7/7.2.8 Bewijs van echtheid Het gebruik van public/private keys is een grote vooruitgang voor het beveiligd versturen van gegevens. Toch is er een probleem, namelijk de ontvangst van een public key. Wie garandeert namelijk dat de public key die ik ontvang ook daadwerkelijk afkomstig is van de gebruiker of server waarvan ik denk dat hij is? Dat is waar de Certificate Authority (Certification Authority volgens sommigen) om de hoek komt kijken. De Certificate Authority (CA) is een instantie die de echtheid van public keys garandeert. Dat doet de CA door een public key-certificaat aan te maken. Een public key-certificaat is een public key die gegarandeerd is door een CA. Deze doet dat op zijn beurt door het public key-certificaat te ‘ondertekenen’. Dit ondertekenen gebeurt met de private key van de certificate authority. Als de public key van de CA bekend is op het werkstation waar het public key-certificaat ontvangen wordt, kan dit certificaat automatisch en zonder tussenkomst van de gebruiker goedgekeurd worden. Deze techniek zorgt ervoor dat bijvoorbeeld gebruikers automatisch een door encryptie beveiligde verbinding met een beveiligde webserver op kunnen zetten. Nu zijn er verschillende manieren om een CA te gebruiken. U kunt als bedrijf uw eigen CA in het leven roepen, maar daarnaast kunt u ook gebruikmaken van de diensten van een commerciële CA, zoals Verisign. Voor beide oplossingen valt iets te zeggen. Stel dat u als bedrijf een aantal services aanbiedt aan uw gebruikers. Deze services zijn beveiligd met public/private key-cryptografie. Dit betekent dat om een verbinding tot stand te brengen, de gebruiker de public key van de service in een certificaat toegestuurd krijgt. Als u er als beheerder voor kunt zorgen dat de public key van de CA die

7/7.2-10



04-10-2007

14:00

Pagina 11

Security

dit certificaat ondertekend heeft, aanwezig is op de desktop van de gebruiker, is alles prima in orde. De computer van de gebruiker zal het certificaat zonder problemen accepteren en ermee aan het werk gaan. De essentie van het succes van deze oplossing echter zit hem in het beheer van de werkplekken van de gebruiker. Als u er als beheerder voor kunt zorgen dat het certificaat van de server op alle werkplekken geïnstalleerd is, is er niets aan de hand. Kunt u dat daarentegen niet, dan hebben we dus een probleem. Voor dit probleem bestaan twee oplossingen.

Chain of trust

De eerste oplossing om ervoor te zorgen dat ‘vreemde’ clients toch beveiligd contact kunnen maken met uw server, is door de echtheid van de CA die u gebruikt te laten garanderen door een andere CA. Dit is een oplossing die de moeite waard is als u als organisatie in staat wilt zijn veel certificaten uit te delen zonder dat daarvoor de hulp van een externe partij nodig is. U maakt op dat moment een certificaat aan, verstuurt dat naar een externe instantie, zoals Verisign, en laat deze instantie het ondertekenen. Op dat moment is er sprake van een zogenaamde chain of trust. Uw klanten herkennen het certificaat van uw CA dan wel niet, maar omdat dit certificaat ondertekend is door een partij waarvan iedereen weet dat die te vertrouwen is, is het toch goed. Verisign vervult in dit voorbeeld de rol van de zogenaamde trusted root. Op het moment dat u uw eigen CA hebt aangemaakt en de identiteit daarvan hebt laten garanderen door een externe partij, ontstaat er een ware Public Key Infrastructure (PKI). Hiermee wordt verwezen naar de totaaloplossing die door u gebruikt wordt om door middel van certificaten tot een veilige manier van werken te komen.


7/7.2-11


04-10-2007

14:00

Pagina 12


De tweede oplossing is aanzienlijk duurder: u gaat gewoon voor elk certificaat dat u wilt gebruiken naar een externe CA toe. U verzoekt deze instantie een certificaat aan te maken en dat voor u te garanderen. Dit werkt ook, alleen hebt u wel het nadeel dat u voor elk certificaat ook zult moeten betalen. Niet bepaald een goedkope oplossing dus! Daarom leert u in dit hoofdstuk hoe u uw eigen Linux Certificate Authority aanmaakt.

SuSE

7/7.2-12

Het is mogelijk om op basis van OpenSSL uw eigen CA te maken. In ‘Beheer van certificaten vanaf de commandoregel’ in paragraaf 7/7.3.5 leert u hoe u dit doet. Deze werkwijze is echter bepaald lastig. Fedora Linux kent geen mogelijkheid het beheer van een CA te vereenvoudigen. Red Hat wel, maar deze distributie is niet als gratis download beschikbaar. SuSE Linux Enterprise Server kan wel gratis gedownload worden, maar u kunt geen gebruik maken van de mogelijkheid deze distributie automatisch bij te laten werken met de meest recente updates. In SuSE Linux Enterprise Server is vanuit het beheersprogramma YaST een bijzonder gebruiksvriendelijke optie aanwezig om een Certificate Authority te configureren. Om die reden leest u in dit hoofdstuk vrij uitgebreid hoe deze configuratie werkt.



04-10-2007

14:00

Pagina 1

Security

7/7.3

Configuratie van een Certificate Authority

De eenvoudigste manier om in SuSE Linux Enterprise Server certificaten aan te maken, is met YaST. U vindt hier onder Security and Users twee opties om certificaten in te stellen. De optie CA Management helpt u bij het aanmaken van uw eigen CA. De optie Common Server Certificates stelt u in staat de eigenschappen te beheren van een certificaat dat al op uw server geïnstalleerd is. Het aardige van SuSE Linux Enterprise Server is overigens dat het niet altijd ook nodig is iets met deze opties te doen: bij installatie worden automatisch certificaten en CA aangemaakt en daar kunt u direct gebruik van maken. Alleen als u met de standaardinstellingen niet tevreden bent, past u deze aan.

Vier opties

7/7.3.1 Beheer van de CA met YaST De YaST-optie CA Management geeft toegang tot alles wat nodig is om uw eigen CA te beheren. Na een standaardinstallatie ziet u de YaST default CA en de daaraan gerelateerde chain of trust. Omdat de standaard CA self-signed is, is er geen sprake van een echte chain of trust. Om uw CA te beheren zijn er vier verschillende opties beschikbaar (zie volgende figuur): • Enter CA: gebruik deze optie om de eigenschappen van een CA aan te passen. • Delete CA: met deze optie verwijdert u uw CA, waarna u een nieuwe aan kunt maken. • Create Root CA: maak gebruik van deze optie als u een root-CA wilt maken om zo certificaten te signeren voor andere CA’s in uw netwerk. • Import CA: met deze optie kunt u sleutels van een andere CA op uw server importeren. Gebruik deze optie voor consolidatie van CA’s in uw netwerk.


7/7.3-1


04-10-2007

14:00

Pagina 2


YaST biedt vier opties om uw CA te beheren.

7/7.3.2

Aanpassen van de eigenschappen van bestaande Certificate Authorities Hier zullen we bespreken hoe u de eigenschappen van een bestaande CA aanpast. 1. Activeer de Certificate Authority-managementinterface in YaST en zorg ervoor dat uw huidige CA geselecteerd is. Klik dan op Enter CA. Hiermee krijgt u toegang tot de eigenschappen van de CA. 2. U ziet nu een venster met vier verschillende tabbladen. Vanaf deze tabbladen beheert u alle eigenschappen van de CA. Standaard is het tabblad Description actief. Op deze tab ziet u de eigenschappen waarmee de CA beschreven wordt en de waarden die aan deze eigenschappen toegekend zijn.

7/7.3-2



04-10-2007

14:00

Pagina 3

Security

Op het tabblad Description treft u een samenvatting van de belangrijkste eigenschappen van uw CA aan.

3.

Het tabblad Certificates geeft een overzicht van alle certificaten die door deze CA uitgedeeld zijn. U zult standaard alleen het servercertificaat zien dat is aangemaakt bij installatie van deze server. Als deze server echter gebruikt wordt om ook certificaten voor andere servers in het netwerk aan te maken, ziet u deze hier ook. Voor elk certificaat is het mogelijk een overzicht op te vragen van de huidige eigenschappen. Ook kunt u hier een certificaat herroepen als u weet dat de beveiliging gecompromitteerd is. Hiermee wordt een Certificate Revocation List (CRL) aangemaakt. Deze CRL wordt gepubliceerd zodat anderen die dit certificaat gebruiken weten dat het niet langer geldig is.


7/7.3-3


04-10-2007

14:01

Pagina 4


Op het tabblad Certificates ziet u een lijst van alle certificaten die door deze CA beheerd worden.

4.

5.

7/7.3-4

Vanaf het tabblad Certificates kunt u nieuwe certificaten aanmaken door op Add te klikken. Er worden vervolgens twee opties geboden: u kunt een server certificate of een client certificate aanmaken. Beide opties doen min of meer hetzelfde, daarom bekijken we hier uitsluitend de stappen die u moet doorlopen voor het aanmaken van een servercertificaat. Het is namelijk het meest aannemelijk dat u een servercertificaat aan wilt maken als u een server in het leven roept. Nadat u op Add Server Certificate geklikt hebt, krijgt u toegang tot de wizard Create New Server Certificate (zie volgende figuur). In het eerste venster dat door deze wizard geopend wordt, moet u eigenschappen opgeven waardoor het certificaat geïdentificeerd kan worden; het gaat hier om de common name, het emailadres en de lokaliteitsinformatie van het certifi-



04-10-2007

14:01

Pagina 5

Security

caat. Van deze eigenschappen zijn de eerste twee min of meer verplicht, de derde is optioneel. Hiermee maakt u het voor gebruikers van de certificaten eenvoudiger te achterhalen of het certificaat in kwestie echt wel betrouwbaar is. Het gebruik van de individuele opties wordt hieronder toegelicht. • Common name: dit is de complete naam, inclusief het DNS-suffix voor uw server. De common name kan gegeven worden in DNS-notatie. RTD.sandervanvugt.com is bijvoorbeeld een geldige common name. Zorg er tevens voor dat de common name gelijk is aan die van de server waarop u het certificaat gebruikt; als dit niet het geval is zult u een waarschuwing te zien krijgen. • E-mail address: het is goed gebruik om hier de emailadressen op te nemen van een of meer personen in uw organisatie met wie contact opgenomen kan worden als er iets mis is met het certificaat. De gebruiker die de zaak niet helemaal vertrouwt, kan hierdoor eenvoudig verifiëren of alles wel in orde is. • Organization, Organizational Unit, Locality en State: al deze informatie is optioneel en dient voor een betere identificatie van het certificaat. Wel moet u ervoor zorgen dat het juiste land hier geselecteerd is.


7/7.3-5


04-10-2007

14:01

Pagina 6


In het eerste venster dat de wizard Create New Server Certificate u toont, moet u alle contactinformatie invoeren.

6.

7/7.3-6

Nu moet u de eigenschappen van het public/private key-paar opgeven (zie volgende figuur). De volgende opties zijn hiervoor beschikbaar: • Password: dit is de passphrase waarmee u de private key beschermt. Dit is een zeer belangrijke component van de beveiliging: zonder passphrase zou het bezit van de private key namelijk voldoende zijn om van het certificaat gebruik te kunnen maken. Toch zult u in veel gevallen geen passphrase in willen voeren: elke keer dat het certificaat gebruikt wordt (bijvoorbeeld bij het opstarten van een webserver die gebruik wil maken van SSL), moet de passphrase handmatig ingevoerd worden en dat is bepaald niet handig als u in staat wilt zijn een server automatisch op te starten. Daarom is het aan te raden per key



04-10-2007

14:01

Pagina 7

Security

7.

goed te overwegen of u echt wel wilt werken met een passphrase. • Key length: dit is het aantal bits dat gebruikt moet worden voor de versleuteling van het certificaat. Hoe meer bits, hoe veiliger het is, maar houd er rekening mee dat met de toename van het aantal bits ook de belasting van uw server toeneemt. Al die bits moeten immers wel iedere keer gebruikt worden bij het versleutelen en ontcijferen en dat kost tijd. Voor servers is 2048 bitsencryptie over het algemeen goed genoeg; voor certificaten voor eindgebruikers beperkt u zich bij voorkeur nog meer, bijvoorbeeld tot 512 bits. • Valid period: hier specificeert u het aantal dagen dat het certificaat geldig is. De standaardwaarde is 365 dagen en dat is een redelijk waarde. Hiermee verzekert u zich er namelijk van dat het certificaat periodiek vernieuwd wordt. Dit vernieuwen is belangrijk om de kans op misbruik te verkleinen. Over het algemeen is het een goed idee certificaten voor servers en/of gebruikers eens per jaar te vernieuwen. Let er wel op dat de houdbaarheid van een servercertificaat in geen enkel geval groter mag zijn dan de houdbaarheid van de CA die dat certificaat ondertekend heeft. Zoals u ziet is er ook aantal Advanced Options beschikbaar. Wij raden u het gebruik van deze opties af: Novell garandeert de werking van uw certificaten dan niet.


7/7.3-7


04-10-2007

14:01

Pagina 8


Voor elk certificaat dat u aanmaakt, moet u op zijn minst een passphrase, een sleutellengte en een geldigheidsperiode invoeren.

8.

Het derde venster dat geboden wordt door de wizard Server Certificate, geeft een overzicht van alles wat aangemaakt zal worden. Klik in dit venster op Create om het certificaat ook daadwerkelijk aan te maken.

Als resultaat van de hierboven beschreven procedure, hebt u nu een nieuw public key-certificaat en de daarbij behorende private key. Alle bestanden die door deze procedure aangemaakt zijn, bevinden zich in de directory /var/lib/ CAM/YaST_Default_CA. Het prettige bij het gebruik van YaST is dat u met de locatie van deze bestanden verder weinig te maken hebt; u gebruikt immers de YaST-beheersinterface om er iets mee te doen. De belangrijkste knop die u hier ziet, is de knop Export. U vindt deze op het tabblad Certificates van de Certificate Authority-managementinterface. De opties die u onder deze knop vindt, worden hieronder samengevat:

7/7.3-8



04-10-2007

14:01

Pagina 9

Security

•

Export to file: klik op deze knop om uw certificaat te exporteren naar een bestand. Hierdoor wordt een nieuwe interface geopend waarin u aangeeft hoe het bestand uitgevoerd moet worden (zie volgende figuur). In deze interface moet u twee keuzes maken. Om te beginnen geeft u aan of u alleen het certificaat wilt exporteren (dat wil zeggen: de publieke sleutel en de signatuur die daaraan verbonden is), of dat u eveneens de private key wilt exporteren. Als u dit certificaat aangemaakt hebt naar aanleiding van een certificate signing request van een andere server, zult u zowel het certificaat als de bijbehorende private key willen exporteren. De andere server heeft immers beide nodig om gebruik te kunnen maken van het certificaat. Als u daarentegen het certificaat aangemaakt hebt om een service op uw eigen server er gebruik van te kunnen laten maken, is het voldoende alleen het certificaat te exporteren. Gebruikers die gebruik willen maken van de betreffende service, hebben immers alleen maar de publieke sleutel nodig om een beveiligde verbinding op te kunnen zetten. De privésleutel daarentegen moet als het grootst mogelijke geheim beschermd worden en mag in het laatste geval nooit geëxporteerd worden. Na exporteren van alleen het public key-certificaat moet u er bovendien voor zorgen dat dit ergens gepubliceerd wordt. Een webserver of een LDAP-server is hiervoor de aangewezen locatie. Naast de keuze hoe u om wilt gaan met exporteren moet u ook aangeven welk formaat u wilt gebruiken. Er zijn drie gangbare formaten: PEM, DER en PKCS12. Welk formaat u kiest is afhankelijk van de service en de client die gebruik gaan maken van het certificaat. In veel gevallen voldoet PEM uitstekend. Als PEM


7/7.3-9


04-10-2007

14:01

Pagina 10


daarentegen door uw toepassing niet ondersteund wordt, hebt u iets anders nodig. Nadat u aangegeven hebt wat en hoe u wilt exporteren, is het nodig een wachtwoord in te voeren. Dat wil zeggen: de interface heeft het over een wachtwoord, maar feitelijk gaat het hier om een passphrase waarmee u de private key beschermt. Daarna voert u een nieuw wachtwoord in om het bestand waarin uw sleutels geëxporteerd worden te exporteren, evenals de naam van het bestand dat u aan wilt maken. Klik dan op OK om te beginnen met exporteren.

Als u het certificaat uitvoert naar een bestand, is er een aantal opties waarmee u aangeeft wat er precies moet gebeuren.

•

7/7.3-10

Export to LDAP: maak gebruik van deze optie als u het certificaat rechtstreeks weg wilt schrijven naar een LDAP-directoryservice. Als dit het geval is, moet u zoals u in onderstaande figuur ziet, alle informatie



04-10-2007

14:01

Pagina 11

Security

invoeren die noodzakelijk is om contact te maken met de juiste LDAP-server.

Om een certificaat naar een LDAP-directoryserver te kunnen exporteren voert u alle informatie in die nodig is om een connectie met deze server tot stand te brengen.

•

CRL

Export as Common Server Certificate: door gebruik te maken van deze optie kunt u het algemene servercertificaat dat u op dit moment gebruikt vervangen door het certificaat dat u zojuist aangemaakt hebt. Als u dat van plan bent, moet u ervoor zorgen dat de naam van het certificaat gelijk is aan de naam van de server.

Een ander belangrijk aspect van het beheer van een Certificate Authority is de Certificate Revocation List (CRL). U hebt een CRL nodig als een probleem ontstaan is met de beveiliging van uw certificaat. Dit kan bijvoorbeeld het geval zijn als iemand de private key van uw CA gestolen heeft: alle certificaten die door die CA ondertekend


7/7.3-11


04-10-2007

14:01

Pagina 12


zijn, worden daarmee ongeldig. Ook bij het uitlekken van een enkele private key is het nuttig deze op een CRL te zetten, zodat in elk geval bekend gemaakt kan worden dat deze sleutel niet langer geldig is. Om een CRL aan te maken, klikt u in de Certificate Authrority beheersinterface op de CRL tab. Daarna klikt u op generate CRL. Hierdoor wordt voor u een CRL aangemaakt. Vervolgens stelt u deze CRL in als standaard zodat elke client die binnenkomt om de geldigheid van een certificaat te controleren, kan zien dat het certificaat niet langer gebruikt moet worden.

Als er een probleem is met de vertrouwelijkheid van een certificaat, kan een CRL aangemaakt worden.

De belangrijkste functie van een Certificate Authority is het signeren van sleutels die door andere gebruikers en servers aangeboden worden. Om dit te kunnen doen moet

7/7.3-12



04-10-2007

14:01

Pagina 13

Security

de andere server of gebruiker een certificate signing request aanmaken en dat naar uw CA versturen. Als de betreffende gebruiker of server daadwerkelijk op een andere fysieke machine voorkomt, is het nodig om de sleutel die door de ander is aangemaakt te importeren op de server waar uw CA actief is. Dit importeren vindt altijd plaats in de vorm van een bestand. Als de signing request van dezelfde server afkomstig is, kunt u vanuit YaST rechtstreeks naar de locatie van de sleutel bladeren: de sleutel is in het laatste geval immers gewoon een bestand dat ergens in uw lokale bestandssysteem voorkomt. Alle opties die nodig zijn voor het ondertekenen van sleutels, vindt u op de Requests-tab van de Certificate Authority-beheersinterface (zie volgende figuur). Zoals u kunt zien, verschijnt hier automatisch een lijst van alle certificaten die op uw server aangemaakt zijn. In de volgende procedure leest u hoe u deze certificaten kunt signeren. Mocht het certificaat dat u wilt ondertekenen nog niet op de lijst aanwezig zijn, klik dan op de Add- of Import-knop om het eerst toe te voegen. Houd er wel rekening mee dat, om dit met succes te kunnen doen, het in vrijwel alle gevallen nodig is dat de betreffende server zijn certificaat eerst geëxporteerd heeft naar een bestand.


7/7.3-13


04-10-2007

14:01

Pagina 14


Het ondertekenen van certificaten behoort tot de hoofdtaken van een CA.

1.

2.

7/7.3-14

Selecteer uit de lijst met certificaten het certificaat dat u wilt ondertekenen. Klik dan op Request en vervolgens op Sign. Nu moet u in de drop-downlijst aangeven als welk type certificaat u het wilt signeren. U kunt kiezen uit drie soorten: een client-certificaat, een servercertificaat en een CA-certificaat. In dit voorbeeld leest u hoe u een servercertificaat signeert. De procedures voor signeren van CA- en clientcertificaten zijn vergelijkbaar, al moet u er rekening mee houden dat in die gevallen wel gebruikgemaakt wordt van andere parameters. Zoals u in de volgende figuur kunt zien, worden nu alle eigenschappen van het certificaat getoond. Er zijn twee eigenschappen die u zelf kunt instellen in deze interface. Om te beginnen is dat de certificate validity. Hiermee geeft u de periode aan waarin de ondertekening geldig blijft. Dit is niet helemaal hetzelfde als de houdbaarheid van het certificaat zelf, Novell Netwerkoplossingen, aanvulling 25


04-10-2007

14:01

Pagina 15

Security

maar om het eenvoudig te houden, zouden beide wel gelijk aan elkaar moeten zijn. Houd het op de standaardwaarde van 365 dagen, in de meeste gevallen voldoet dat prima voor zowel server- als gebruikerscertificaten. Vervolgens kunt u kiezen uit een lijst met extensies die op het certificaat toegepast kunnen worden. Dit is de lijst die u in het onderste deel van de figuur ziet. Deze extensies gebruikt u om aan te geven waarvoor het certificaat ingezet wordt. Met bijvoorbeeld de extensie Constraints: CA: FALSE geeft u aan dat het niet mogelijk is dit certificaat voor gebruik van een CA in te zetten. Als u bij het aanmaken van het certificaat aangeeft waarvoor u het denkt te gaan gebruiken, worden de juiste extensies automatisch ingevuld; in de meeste gevallen hoeft u zich daar dus geen zorgen over te maken. Controleer ze voordat u verdergaat en als u tevreden bent met wat u ziet, klikt u op Next.


7/7.3-15


04-10-2007

14:01

Pagina 16


Door middel van certificate-extensies geeft u aan waarvoor een certificaat gebruikt kan worden.

3.

Nu ziet u een overzicht waarin het certificate signing request samengevat is. Klik vanuit dit overzicht op Sign request; dit resulteert in het aanmaken van een gesigneerd certificaat. Dit certificaat wordt onmiddellijk toegevoegd als gesigneerd certificaat aan de lijst van certificaten die u vindt op het tabblad Certificates. U kunt het certificaat nu exporteren naar de andere server, het daar importeren en beginnen met het gebruik ervan.

7/7.3.3 Andere CA-beheersopties vanuit YaST In de voorgaande pagina’s hebt u gelezen hoe u een Certificate Authority vanuit YaST aanmaakt en hoe u de aan deze CA geassocieerde certificaten kunt beheren. Daarnaast is er nog een aantal andere opties beschikbaar; deze opties zijn echter van veel kleiner belang dan de opties die hiervoor besproken zijn. Toch willen wij u een

7/7.3-16



04-10-2007

14:01

Pagina 17

Security

volledige indruk van wat mogelijk is niet onthouden en daarom volgt nu een korte uitleg van deze opties: • Delete CA: met deze drastische optie verwijdert u de CA van uw systeem. Voordat u ook maar overweegt hiervan gebruik te maken moet u zich realiseren dat hiermee alle certificaten die aan uw CA verbonden zijn, ongeldig worden en dus allemaal vervangen moeten worden. Hier geldt dus vooral: bezint eer ge begint, het verwijderen van een CA is een uiterste maatregel die veel extra werk met zich meebrengt. • Create Root CA: een CA is alleen nuttig als er ook een root-CA is die de identiteit van uw CA garandeert. Gebruik deze optie om een root-CA aan te maken. Gebruik hiervan is bijvoorbeeld handig in een omgeving waar meerdere servers geïnstalleerd worden en elke server zijn eigen CA heeft; de root-CA kan dan gebruikt worden om de certificaten van deze subordinate CA’s te signeren. • Import CA: uiteindelijk is een CA ook maar gewoon een hoeveelheid sleutels en daaraan geassocieerde configuratie. U kunt vanuit YaST een complete CA exporteren; het is dus ook mogelijk een complete CA te importeren. Dat is dan ook precies het doel van deze optie. Maak er gebruik van om een CA te importeren die u op een andere machine aangemaakt hebt. 7/7.3.4

De YaST Common Server Certificate-interface Naast de interface vanwaaruit u de CA beheert, biedt YaST ook de Common Server Certificate Interface. U benadert deze interface vanaf het tabblad Security and Users. De interface toont u het algemene certificaat dat momenteel op uw server gebruikt wordt (zie volgende figuur). Een belangrijke optie van deze interface is de knop Import. Door gebruik te maken van deze knop kunt u certificaten


7/7.3-17


04-10-2007

14:01

Pagina 18


importeren die op andere servers zijn aangemaakt. Gebruik deze optie bijvoorbeeld ook als u op uw server gebruik wenst te maken van een certificaat dat door een externe CA is aangemaakt. Om het certificaat daadwerkelijk te importeren klikt u op de Import-knop. Blader dan naar de locatie waar het certificaat is opgeslagen, voer de passphrase in en voltooi de wizard om het certificaat te importeren.

Vanuit de Common Server Certificate-interface kunt u nieuwe certificaten importeren.

7/7.3.5

Beheer van certificaten vanaf de commandoregel Het beheer van certificaten en Certificate Authority met YaST is één ding. Deze methode werkt ook uitstekend, maar er is wel een probleem: u hebt er SuSE Linux voor nodig en niet iedereen wil aan het werk met SuSE. Beschikt u over een andere Linux-distributie, dan zult u zich vanaf de commandoregel moeten redden. Uiteraard kunt u hier

7/7.3-18



04-10-2007

14:01

Pagina 19

Security

ook gebruik van maken om op SuSE Linux uw certificaten te beheren. Dit beheer vindt plaats met de opdracht openssl, een zeer krachtige maar ook vrij lastig te gebruiken opdracht die mogelijkheden biedt die u in YaST niet tegenkomt. De behandeling van alle mogelijkheden van OpenSSL vereist een compleet boek op zich, dat zullen we hier dus niet doen. Wel kunt u in deze paragraaf lezen hoe u het openssl-commando kunt gebruiken om een certificaat en een self-signed CA aan te maken. Aangezien er niet verder gewerkt wordt met een keten van CA’s, wordt deze self-signed CA de hoogste in de hiërarchie. We hebben dus te maken met een root-CA. De volgende procedure moet u hiervoor uitvoeren: 1. U moet de certificaten van uw CA opslaan in een directorystructuur. Eerst maakt u zelf een directory aan voor dit doel. Let erop dat deze directory voor geen enkele normale gebruiker toegankelijk mag zijn, zelfs leestoegang is uit den boze. Om het u iets eenvoudiger te maken automatisch te werken met de juiste permissies, is het geen slecht idee de homedirectory van de gebruiker root voor dit doel te gebruiken. Begin in de directory die u voor dit doel wilt gebruiken met de opdracht mkdir root-CA; dit wordt de subdirectory waarin de CA zijn bestanden opslaat. Vervolgens moet u onder deze subdirectory ook weer de nodige directory’s aanmaken. De namen ervan liggen min of meer vast; probeer dus niet creatief te zijn maar houd u aan de voorbeelden en gebruik de opdracht mkdir certs newcerts private crl voor dit doel. Hieronder vindt u een overzicht van waar deze directory’s voor gebruikt worden: • certs: dit is de locatie waar u alle gesigneerde public key-certificaten opslaat. Deze directory


7/7.3-19


04-10-2007

14:01

Pagina 20


2.

7/7.3-20

mag publiekelijk toegankelijk zijn, aangezien er immers alleen maar publieke en geen private sleutels in voorkomen. • newcerts: hier worden alle nieuwe certificaten opgeslagen. Het gaat in dit geval om certificaten die nog niet gesigneerd zijn. • private: in deze directory bewaart u de privésleutels. Deze directory moet u uitermate goed beschermen, omdat de private keys de identiteit van de server vormen. U moet ervoor zorgen dat op deze directory de permissiemodus 700 is toegepast en dat de gebruiker root de eigenaar is van deze directory. • crl: als gebruikgemaakt moet worden van Certificate Revocation Lists (CRL), worden deze hier opgeslagen. Om het certificaat voor uw root-CA aan te maken gebruikt u het configuratiebestand /etc/ssl/ openssl.cnf. Dit bestand bevat standaardinstellingen die het aanmaken van nieuwe certificaten wat vereenvoudigen. U kunt met de instellingen in dit bestand werken, maar bent er niet toe verplicht: als een instelling hier niet gevonden kan worden, wordt er gewoon om gevraagd bij het aanmaken van het certificaat. Wij raden u aan de inhoud van dit bestand op zijn minst een keer aandachtig door te lezen, zodat u weet welke instellingen er mogelijk zijn. Controleer in het bijzonder of alle directorypaden waarnaar verwezen wordt in orde zijn; het gaat hier vooral om de HOME-variabele (de homedirectory van uw CA) en daarnaast om de dir-variabelen. Deze dir-variabelen zijn aan de HOME-variabele verbonden instellingen die aangeven in welke subdirectory’s informatie opgeslagen wordt. U kunt in dit bestand de namen van het certificaat dat u aanmaakt en van



04-10-2007

14:01

Pagina 21

Security

de private key direct goed instellen. In onderstaande code listing ziet u hoe dit er voor de meest essentiële parameters uitziet (alle niet-essentiële opties zijn uit dit voorbeeld weggelaten): HOME

= /root/rootCA

dir

= /root/root-CA

... certificate

= $dir/root-CAcert.pem

... private-key

= $dir/root-CAkey.pem

Nu u het configuratiebestand op de juiste wijze hebt aangemaakt, kunt u een self-signed certificaat voor de root-CA aanmaken. Met het volgende commando maakt u een certificaat aan met een 1024 bits RSAsleutel die geldig is voor een periode van tien jaar: openssl req -newkey rsa:1024 -x509 -days 3650

Het hoofdcommando hier is het commando openssl. Deze opdracht heeft verschillende opties, die u kunt gebruiken alsof het individuele commando’s zijn. Elk van deze commando’s heeft bijvoorbeeld ook zijn eigen man-pagina in de sectie (1ssl). In dit voorbeeld wordt gebruikgemaakt van het hulpcommando req om een self-signed certificaat aan te maken. Met de overige opties geeft u aan hoe precies de sleutel aangemaakt moet worden. Het mag misschien verbazing wekken dat de sleutel een geldigheidsduur van tien jaar krijgt, maar dat komt omdat het hier gaat om een sleutel voor een Certificate Authority: deze moet langer houdbaar zijn dan een normaal certificaat. Als deze sleutel namelijk niet langer geldig is, zijn eveneens alle andere sleutels die gesigneerd zijn


7/7.3-21


04-10-2007

14:01

Pagina 22


door deze CA niet langer geldig. Ook moet u zich er bewust van zijn dat dit commando veel langer gemaakt kan worden. U kunt bijvoorbeeld aangeven welke namen de aan te maken sleutels en certificaten moeten krijgen. Aangezien deze namen ook opgegeven worden in het configuratiebestand openssl.cnf (zie stap 2 van deze procedure), is dat echter geen strikte noodzaak. Zou u toch bestanden aan willen maken met een andere dan de standaardnamen, dan maakt u met de opties -keyout en -out het commando gewoon wat langer. De volgende opdracht geeft bijvoorbeeld precies aan wat er aangemaakt moet worden: openssl req -newkey rsa:2048 -x509 -days 3650 -keyout private/my-CAkey.pem -out my-CAcert.pem

Bij het aanmaken van een sleutel zult u zien dat er altijd de nodige vragen gesteld worden. De belangrijkste is de vraag om de passphrase; dit is namelijk het enige stuk informatie dat niet automatisch ingevuld kan worden. Denk er bij het aanmaken van een root-CA (wat hier het geval is) aan dat het zeer belangrijk is dat u een passphrase gebruikt. Er is immers veel afhankelijk van het functioneren van de root-CA. Alle overige vragen die gesteld worden, krijgen een standaardantwoord op basis van de instellingen in openssl.cnf. U mag dit standaardantwoord accepteren door op Enter te drukken, maar u kunt ook op elk van deze vragen een afwijkend antwoord geven om het certificaat aan te maken.

7/7.3-22



04-10-2007

14:01

Pagina 23

Security

Bij het aanmaken van een self-signed public key-certificaat met de bijbehorende private key wordt u gevraagd informatie op te geven over de eigenaar van het certificaat. Daarnaast moet u een passphrase opgeven voor de private key.

Gefeliciteerd, u hebt nu uw eigen root-CA. Deze maakt het mogelijk uw eigen certificaten aan te maken en te ondertekenen. Deze kunt u vervolgens voor elk doel gebruiken. Denk bijvoorbeeld aan servercertificaten om beveiligd email te versturen, of client-certificaten om een laptop aan de VPN-gateway te verbinden. Voordat u echter enthousiast begint met het aanmaken van uw eigen certificaten, moet u nog een OpenSSL-databasebestand aanmaken. Dit is bepaald geen ingewikkelde database; het gaat slechts om twee bestanden die door de OpenSSL-software gebruikt worden om bij te houden welke certificaten er allemaal uitgegeven zijn. U moet deze bestanden handmatig aanmaken voordat u verdergaat. Hiervoor gaat u vanaf een opdrachtregel naar de homedirectory van uw root-CA. Daar geeft u dan de volgende opdracht:


7/7.3-23


04-10-2007

14:01

Pagina 24


touch index.txt

Vervolgens gebruikt u de opdracht echo 01 > serial

om meteen inhoud te geven aan de tweede van deze bestanden. Nu de indexbestanden aangemaakt zijn, kunt u het sleutelpaar en de bijbehorende certificate signing request aanmaken. Ook hiervoor maakt u weer gebruik van de opdracht openssl: openssl ca -policy policy_anything -notext -out certs/mailservercert.pem -infiles certs/mailserver_req.pem

In deze opdracht wordt voor de signing van de sleutel gebruikgemaakt van de policy. Deze policy, die ingesteld wordt in openssl.cnf, bevat instellingen die bepalen hoe de sleutel aangemaakt wordt. Met de optie -notetext beperkt u de hoeveelheid uitvoer die deze opdracht met zich meebrengt. Vervolgens krijgt het certificaat de naam certs/mailservercert.pem. Dit certificaat kan alleen maar aangemaakt worden omdat u in een eerder stadium een signing-request verstuurd hebt met de naam mailserver_req.pem. Deze signing request wordt opgeslagen in de directory certs. Mocht het eens voorkomen dat u een sleutel moet signen die op een andere server aangemaakt is, dan kan dat ook. U moet er in dat geval alleen maar voor zorgen dat de sleutel gekopieerd wordt naar de directory certs. U kunt dan zonder problemen een public key-certificaat aanmaken op basis van deze signing request, op de wijze die we beschreven hebben.

7/7.3-24



04-10-2007

14:01

Pagina 25

Security

U hebt nu een public/private key-paar aangemaakt. In dit voorbeeld zijn we ervan uitgegaan dat het een certificaat voor een mailserver betreft. Dit certificaat is gesigneerd met het self-signed certificaat van de root-CA. Zoals gezegd kunt u met OpenSSL veel meer doen dan wat in het voorgaande beschreven is. Raadpleeg voor een volledig overzicht de man-pagina van OpenSSL. 7/7.3.5 Tot slot In dit hoofdstuk hebt u gelezen over de wijze waarop u onder Linux kunt werken met certificaten. In het bijzonder is behandeld hoe u een Certificate Authority aan kunt maken. Het is aan te raden ervoor te zorgen dat u over een dergelijke service kunt beschikken; heel veel andere services maken namelijk gebruik van certificaten en voor al deze certificaten geldt dat de echtheid ervan vroeg of laat bepaald moet kunnen worden.


7/7.3-25


04-10-2007

14:01

Pagina 26


7/7.3-26


7 OpenSSL en de Certificate Authority

Recommend Documents