Linux Friheden til at vælge digital signatur

Transkript

1 Linux Friheden til at vælge digital signatur Support for danske Certification Authorities for Linux brugere Mads Bondo Dydensborg

2 Linux Friheden til at vælge digital signatur: Support for danske Certification Authorities for Linux brugere af Mads Bondo Dydensborg Ophavsret af forfatteren har copyright på bogen, men udgiver den under "Åben dokumentlicens (ÅDL) version 1.0". Denne bog beskriver hvordan man kan få sit Linux system til at bruge Kommunedata A/S (KMD) som Certificate Authority (CA) og hvordan man kan anvende x509 certifikater under Linux. Det er planen at bogen på sigt skal udvides til at omfatte andre CA er end KMD-CA, men foreløbigt dækker den kun KMD-CA.

3 Indholdsfortegnelse Forord...i 1. Linux-bøgerne... i 2. Ophavsret... i 3. Vi siger tak for hjælpen...ii 1. Baggrund Digitale certifikater og signaturer Kommunedata CA Krævet software Eksempel på dannelse af certifikat forespørgsel Installation og brug af certifikater Anskaffelse af KMD-CA rodcertifikat Konvertering af certifikat Installation og brug af certifikater i programmer og miljøer KDE KDE Gnus Introduktion til sslugsig Målet med sslugsig Download Kildetekst og startscript Program, libs og startscript Programmets dokumentation Alle filer i projektet Installation Lidt om kildeteksten Kontrol af indtastningen Placering af output Information til programmører Dannelse af certifikat forespørgslen Eksempel på forespørgselsdannelses fil Beskrivelse af de enkelte felter Eksempel program til generering af forespørgsel Videresendelse af forespørgsel til KMD-CA Mere information A. Revisionshistorie for bogen Stikordsregister iii

4 iv

5 Forord Denne bog forsøger at dokumentere hvordan x509 certifikater kan anvendes under Linux. Understøttelsen af certifikater i Linux er rimeligt god, men det kan være et problem at erhverve sig et certifikat, hvis udbyderen f.eks. kræver Microsoft programmel som Internet Explorer. Denne bog forsøger at dække anskaffelse, installation og indledende brug af certifikater under Linux, med frit programmel. Dokumentet henvender sig både til brugere, der gerne vil have at deres system kan anvende KMD-CA som CA, samt til udviklere, der vil udvikle frontends til processen. For brugere beskrives hvordan man kan hente et program der kan bruges til at erhverve et certifikat, samt hvordan dette kan anvendes, for udviklere beskrives detaljer omkring procedurerne. Bogen er under stadig udvikling. Anvendelse af certifikater i Danmark er stigende og det er væsentligt at gøre det nemt for alle at anvende dem. Bidrag og rettelser til bogen modtages meget gerne. Mht. anskaffelse af certifikater dokumenterer denne udgave primært certifikater udstedt af KMD-CA, men det er vores intention at kommende udgaver også vil dokumentere andre udbydere. 1. Linux-bøgerne Bogen er en del af en serie, som kan findes på Linux Friheden til at vælge installation Om at installere Linux. Linux Friheden til at lære Unix Om hvordan man bruger Linux (og Unix ) kommandolinjeværktøjer. Linux Friheden til at vælge grafisk brugergrænseflade Om alle de grafiske brugergrænseflader, der findes til Linux. Linux Friheden til at vælge programmer Om de programmer du kan få til Linux. Linux Friheden til systemadministration Om at administre sit eget linuxsystem. Linux Friheden til at programmere Programmering på Linux Linux Friheden til at programmere i C Om at programmere i sproget "C". Linux Friheden til at programmere i Java Om at programmere i sproget "Java". Linux Friheden til sikkerhed på internettet Om at sikre dit Linuxsystem mod indbrud fra internettet. Linux Friheden til egen webserver Om at sætte en webserver med databaser, CGI-programmer og andet godt op. Linux Friheden til at skrive dokumentation Om at skrive dokumentation (og andet) i SGML/DocBook, LaTeX eller andre formater. Linux Friheden til at vælge kontorprogrammer Kontorfunktioner på et Linux/KDE/OpenOffice.org-system. Linux Friheden til at vælge IT-løsning Om muligheder, fordele og ulemper ved at bruge Linux i sin IT-løsning. Linux Friheden til at vælge OpenOffice.org Om at bruge OpenOffice.org, både på Linux og på andre styresystemer. Linux Friheden til at vælge digital signatur Digital signatur på Linux. 2. Ophavsret Denne bog er skrevet af Linux-brugere til Linux-brugere. Store dele af bogen er skrevet eller redigeret af enkelte forfattere, hvilket er nævnt i revisions-historien til bogen. Bogen kan findes i opdateret form på SSLUG s hjemmesider: mens prøve-udgaver kan findes på i

6 Forord Figur 1. ÅDL Bogen er udgivet under "Åben dokumentlicens (ÅDL) version 1.0" som kan læses på Du har bl.a. herved frit lov til at kopiere dette værk uændret på ethvert medium. Kommentarer, ris og ros og specielt fejl og mangler bedes sendt til 5, men er du medlem af SSLUG kan du i stedet for med fordel skrive til sslug-bog@sslug.dk Vi siger tak for hjælpen Vi har haft stor glæde af mange SSLUG-medlemmers støtte, rettelser og forslag til forbedringer - bliv ved med det. Specielt vil vi nævne: Jørn Guldberg (KMD), Erling Sjørlund, Arne Jørgensen, Hans Schou, Peter Toft, Klavs Klavsen og Christian Boesgaard. Du kan i Appendiks A finde en liste over alle de revisioner, som bogen har været igennem. Slutbemærkning: mailto:linuxbog@sslug.dk 6. mailto:sslug-bog@sslug.dk ii

7 Kapitel 1. Baggrund Baggrunden for udarbejdelsen af denne bog er at indførelsen af digitale signaturer og certifikater i Danmark er hastigt undervejs. I fremtiden må vi forvente at det i en vis udstrækning vil være nødvendigt at have et digitalt certifikat hvis man som borger vil anvende det offentliges digitale tilbud. Dette er egentlig ganske udemærket, men hvis man i øjeblikket gerne vil erhverve og anvende et digitalt certifikat under Linux, vil man opleve at de fleste udstedere forventer at man anvender Microsoft Windows. Deres procedurer og vejledninger er derfor målrettet imod denne platform. Derfor denne bog hensigten er at forklare hvad der skal til for at erhverve og anvende digitale certifikater under Linux. På sigt er det meningen at bogen skal dække alle certifikatudstedere af betydning i Danmark, men foreløbig er kun Kommunedata (KMD-CA) 1 dækket. Andre udstedere er TeleDK 2 og EuroTrust 3. I dette kapitel præsenteres digitale certifikater og signaturer kort, og derefter bliver KMD-CA kort præsenteret Digitale certifikater og signaturer Hvis man ikke er bekendt med kryptografi teknologi, kan det være lidt vanskeligt at forstå hvad digitale certifikater og signaturer er for nogen størrelser. Jeg vil her give en meget simplificeret fremstilling. En digital (eller elektronisk) signatur er en slags underskrift, der giver mening i "det digitale rum". Normalt i den virkelige verden signerer vi os som regel med noget der minder om bogstaver i en bestemt kombination, eventuelt med en række krummelyrer og andre streger. En sådan signatur, som antages at være personlig, anses for værende juridisk bindende i en række situationer, men faktisk accepteres den ikke alene i mange sammenhænge. Hvis man vil være virkelig sikker, skal ens navn som regel også angives og jævnligt vil det være nødvendigt at vidner skriver under (f.eks. ved indgåelse af ægteskab) på at man er den man udgiver sig for at være. I den digitale verden er der mange problemer med at kopiere ovenstående procedure. Dels er der ikke noget fysisk at manipulere (som f.eks. et stykke papir) dels er det ekstremt nemt at kopiere en underskrift, såfremt den "stod alene", altså f.eks. var et billede af ens virkelige signatur. Problemet med en digital signatur kan løses ved hjælp af kryptografi. Kryptografi er mildt sagt temmeligt indviklet og jeg vil ikke komme ind på det her. Men, man kan som sagt udvikle metoder så man kan sætte sin signatur på f.eks. et elektronisk dokument, sådan at det kan afgøres entydigt at man har skrevet under. Imidlertid forudsætter dette at andre kan finde ud af hvem man er. Det klares typisk ved og det er det denne bog handler om at man bliver enige om at stole på en tredjepart, en såkaldt "Certificate Authority" når man skal afgøre hvem der er hvem. Man erhverver sig et digitalt certifikat fra denne tredjepart og dette certifikat kan bruge til at signere f.eks. dokumenter med, og bruge til at dokumentere at man er den man er. En del af erhvervelsen består i at man identificerer sig entydigt overfor autoriteten. (I Danmark gøres dette som regel ved hjælp af et pas Danmark har ikke nogen mere sikker måde at entydigt identificere sig på. Dette har ført til mindst et tilfælde at identitetstyveri i den virkelige verden! Den elektroniske sikkerhed for at en person er den han udgiver sig for, kan altså aldrig blive større end den sikkerhed man har i den virkelige verden, og må generelt antages at være mindre.) Når du vil identificere dig elektronisk overfor en anden person eller myndighed, kan du således give vedkommende dit certifikat. Modtageren kan derefter få bekræftet dit certifikats gyldighed hos autoriteten (f.eks. KMD- CA). Typisk vil vedkommende gøre dette ved at installere et såkaldt rodcertifikat fra autoriteten på sin lokale computer, som kan anvendes til at afgøre om dit certifikat er gyldigt. Når modtageren er overbevist om at dit certifikat er gyldigt, kan du bruge din private nøgle som du vil have fået konstrueret som en del af processen med at erhverve dig dit certifikat til at kommunikere sikkert med vedkommende. Hvis du f.eks. sender en , kan du signere din mail med din private nøgle. Når modtageren modtager din mail, kan han afkode din signatur med det certifikat du allerede har givet ham, og være sikker på at mailen rent faktisk er fra dig. Du kan også kryptere din mail. Det gøres igen ved hjælp af din private nøgle, samt modtagerens certifikat. Når modtageren modtager din mail, kan han først læse den, når han har afkodet den med dit certifikat og sin egen private nøgle. (For at gøre dette, skal du altså have modtagerens certifikat og være sikker på at det er hans.) Det lyder umiddelbart ret kompliceret, men når først du har fået dit certifikat, er det meningen at du bare skal installere det på din computer sammen med din private nøgle og så fungerer resten rimeligt automatisk. Du skal måske nogen gange sørge for at folk har adgang til dit certifikat og at du har certifikater fra folk du vil kommunikere krypteret med. Men, det er lidt ligesom at udveksle adresser og man kan forestille sig at der endda vil være steder hvor man kan hente folks certifikater at de f.eks. har dem på deres hjemmeside. Så vidt jeg har forstået er det planen at f.eks. KMD-CA vil tilbyde en sådan service. 1

8 Kapitel 1. Baggrund 1.2. Kommunedata CA I dette afsnit vil jeg forklare hvordan KMD-CA s system fungerer, set fra brugerens side. Forklaringen er med vilje simplificeret og fokuserer på hvordan systemet fungerer i anvendelse, ikke hvordan det fungerer teknisk eller teoretisk (kryptografisk). Bemærk at mange af disse skridt vil kunne automatiseres. For at KMD-CA kan udstede et certifikat til dig, skal du bede dem om det. Det gøres ved at lave en "certificate request" - altså en forespørgsel om at få et certifikat. Denne forespørgsel skal laves digitalt. Hvis man har valgt at køre Microsoft Windows, har man mulighed for at hente et program fra KMD-CA s hjemmeside der kan lave forespørgslen for dig. Se Figur 1-1. Figur 1-1. KMD-CA s Windows program På sigt er det vist hensigten at KMD-CA vil udvikle en ActiveX komponent der kan gøre det i browseren hvis man kører Windows. Det er trist at KMD-CA vælger at satse på den slags lukket teknologi, men heldigvis vil man stadig have muligheden for at lave forespørgslen offline. Under Linux vil du således altid være henvist til at køre et program, der genererer requesten for dig. (Et eksempel på et sådan program gives i Kapitel 5). Dette program vil bede om en række oplysninger, blandt andet dit navn og adresse, mv. Programmet vil så lave en privat nøgle og en certifikat forespørgsel. Den private nøgle skal du passe rigtigt godt på, og ikke lade andre få adgang til. Du vil typisk lade programmet beskytte den med et password, så andre ikke kan afkode den. Hvis andre får adgang til den private nøgle, vil de være i stand til at udgive sig for dig (mht. digitale signaturer) så det er overmåde vigtigt at andre ikke får adgang til den. Certifikat forespørgslen indeholder din offentlige nøgle, så den ser du i første omgang ikke selv. Du skal sende certifikat forespørgslen til KMD-CA. De vil behandle den, og sende dig et brev om at du skal gå på posthuset og dokumentere hvem du er. En medarbejder på posthuset vil bekræfte din identitet overfor KMD-CA, hvorefter du kan hente dit nye certifikat hos KMD-CA. Når du fremover vil identificere dig elektronisk overfor en anden person eller myndighed (som anerkender KMD- CA), kan du give vedkommende dit certifikat, som beskrevet i afsnittet ovenfor og gå igang med at benytte det. Der er flere informationer om proceduren på KMD-CA s websider, f.eks. på 4 og de følgende kapitler indeholder information om hvordan man benytter certifikatet, mv, under Linux. 2

9 Kapitel 1. Baggrund Slutbemærkning:

10 Kapitel 1. Baggrund 4

11 Kapitel 2. Krævet software For at du kan generere en certifikat forespørgsel til KMD-CA, skal du have installeret programmet openssl. Langt de fleste Linux distributioner installerer dette som standard, idet det anvendes af f.eks. mange webbrowsere til at lave "Secure Socket Layer" (SSL) enkodning. Du kan teste om du har programmet ved at åbne en terminal og skrive: $ which openssl /usr/bin/openssl $ openssl OpenSSL> quit $ På mit system er openssl altså installeret som /usr/bin/openssl og fungerer tilsyneladende fint. I Kapitel 3 kan du se et eksempel på hvordan du manuelt kan genere en certifikatforspørgsel. Det er ret indviklet, og i stedet vil jeg anbefale dig at kigge på "sslugsig" i Kapitel 5, eller, hvis du er til kommandolinjeværktøjer, perl scriptet i Afsnit 6.2, der illustrerer hvordan openssl skal anvendes for at lave en certifikat forespørgsel der kan anvendes til KMD-CA. Når du har fået dit certifikat fra KMD-CA, skal det installeres. Se Kapitel 4 5

12 Kapitel 2. Krævet software 6

13 Kapitel 3. Eksempel på dannelse af certifikat forespørgsel Nedenfor gives et eksempel på hvordan man kan danne en certifikat forespørgselsfil med programmet openssl. Du kan finde mere information om proceduren i man filerne for openssl, men hvis du er interesseret i at lave en certifikat forespørgsel til brug for KMD-CA, anbefales det at du istedet kigger på "sslugsig" i Kapitel 5, eller, hvis du er til kommandolinjeværktøjer, perl scriptet i Afsnit 6.2. Nedenstående procedure giver nemlig ikke en forespørgsel der kan anvendes med KMD-CA. Der dannes to filer vha. programmet. key.pem er den private nøgle, mens req.der er certifikat forespørgslen. Bemærk, nedenstående procedure giver ikke en certifikat forespørgsel der kan anvendes af KMD-CA, da der mangler nogen specielle felter. Ligeledes stiller KMD-CA nogen specielle krav til navngivningen af filer og har nogen specielle krav til de danske bogstaver. Se Kapitel 6 for mere information om dannelse af en forespørgsel der kan anvendes i forhold til KMD-CA. $ openssl req -newkey rsa:1024 \ -keyout key.pem -out req.der -outform DER Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key writing new private key to key.pem Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank Country Name (2 letter code) [AU]:DK State or Province Name (full name) [Some-State]:Denmark Locality Name (eg, city) []:Copenhagen Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:Mads Bondo Dydensborg Address []:mads@dydensborg.dk Please enter the following extra attributes to be sent with your certificate request A challenge password []:tester An optional company name []: $ ls -l totalt 8 -rw-rw-r-- 1 madsdyd madsdyd 963 mar 4 08:55 key.pem -rw-rw-r-- 1 madsdyd madsdyd 482 mar 4 08:55 req.der 7

14 Kapitel 3. Eksempel på dannelse af certifikat forespørgsel 8

15 Kapitel 4. Installation og brug af certifikater Dette kapitel handler om, hvad man skal foretage sig på sin egen computer for at kunne bruge sit certifikat til noget fornuftigt. For at du kan bruge det certifikat, du køber hos f.eks. KMD-CA, til noget fornuftigt, skal det installeres i din browser, og i dit mailprogram. For at kunne se, at de signaturer du modtager fra andre nu også er korrekte, skal du installere rodcertifikater fra deres udstedere. For f.eks. KMD-CA er det faktisk nødvendigt at installere KMD-CA s rodcertifikat for at kunne få et personligt certifikat på en sikker måde. De personer du sender signerede eller krypterede mails til, skal have installeret rodcertifikatet fra din udbyder, så de kan få bekræftet din signatur Anskaffelse af KMD-CA rodcertifikat På KMD-CA s hjemmeside 1 kan man surfe sig frem til rodcertifikatet. Sitet er egentligt beregnet på at man bruger Windows og kan installere direkte i browseren, men hvis man leder længe nok, kan man også bare hente filen. Jeg fandt den på 2. Bemærk at der findes procedurer for at sikre at dette certifikat vitterligt er fra KMD-CA det indebærer at ringe til et telefonnummer og få læst certifikatets "fingerprint" op. De virkeligt paranoide kan så ringe til telefonselskabet og få bekræftet at telefonnummeret tilhører KMD-CA. Når du har hentet og installeret (se nedenfor) dette certifikat, kan du oprette sikre forbindelser til KMD-CA. Dette er en forudsætning for at hente dit nye certifikat, efter bekræftelsen på posthuset. Jeg fandt dette cerfikat på 3. Du kan også teste din sikkerhed på KMD-CA s hjemmeside Konvertering af certifikat Certifikatet fra KMD-CA er i binær form, nemlig i et format kaldet "DER". Det er noget nemmere at håndtere, hvis det er en i tekstbaseret form. Derfor vil det ofte være relevant at konvertere det til et tekstbaseret format kaldet "PEM" format. Det kan gøres med openssl. Kommandoen er: $ openssl x509 -inform DER -outform PEM -in KMD-CA-Server.crt \ -out KMD-CA-Server.crt.pem Filen KMD-CA-Server.crt.pem er nu i PEM format. Tilsvarende kan gøres for filen KMD-CA-KPerson.crt Installation og brug af certifikater i programmer og miljøer Dette afsnit beskriver installation og brug af certifikater i forskellige programmer og miljøer KDE 2 Dette afsnit beskriver hvordan rodcertifikat installation fungerer i KDE 2. Beskrivelsen er baseret på KDE version Mekanismerne for håndtering af certifikater er blevet meget forbedret i KDE version 3.0. Se Afsnit Hvis man bruger KDE og vil bruge certifikater, bør man absolut opgradere til KDE 3. Beskrivelsen af proceduren for KDE 2 vil blive fjernet fra kommende udgaver af denne bog. KDE har et Krypto modul du kan finde i KDE s Kontrolcenter under personliggørelse. Antageligvis burde man kunne installere certifikater via dette modul. Imidlertid er det foreløbigt ikke lykkedes for mig at gøre dette. Muligvis kan man kun tilføje egne certifikater. Tilføjelsen af rodcertifikatet må du foreløbigt klare manuelt. KDE bruger sit eget ssl modul, kssl. KDE programmer (som konqueror og kmail) burde således alle virke, såfremt de relevante certifikater er installeret. Der findes en fil, ca-bundle.crt, der indeholder en lang række certifikater som KDE accepterer som rodcertifikater som udgangspunkt. For at tilføje KMD-CA s certifikat, kan du kopiere denne fil til dit hjemmekatalog, og tilføje filen til enden af den. I det følgende er disse skridt beskrevet. (Bemærk at det kan skifte en smule hvor ca-bundle.crt ligger). $ mkdir -p $HOME/.kde/share/apps/kssl/caroot $ cat /usr/share/apps/kssl/caroot/ca-bundle.crt KMD-CA-Server.crt.pem \ > $HOME/.kde/share/apps/kssl/caroot/ca-bundle.crt 9

16 Kapitel 4. Installation og brug af certifikater Bemærk at det er filen KMD-CA-Server.crt.pem der bruges, ikke KMD-CA-Server.crt. Der er selvfølgelig andre måder at tilføje og rette i $HOME/.kde/share/apps/kssl/caroot/ca-bundle.crt fil på. Når du har tilføjet rodcertifikatet, kan du tjekke din sikkerhed på KMD-CA s hjemmeside, ved at besøge siden og følge "check sikkerheds" pilene. Når den sikre forbindelse er oprettet kan du klikke på vis sikkerhed i konquerors menu - det skulle gerne frembringe et billede som Figur 4-1. Figur 4-1. KDE sikkerheds dialog Peer certifikater på SSL forbindelser bliver iøvrigt placeret i $HOME/.kde/share/config/ksslpolicies KDE 3 KDE 3 indeholder stærkt forbedredet understøttelse af håndtering af certifikater. Det er således muligt at klikke direkte på KMD-CA s rodcertifikat på deres hjemmeside i konqueror og installere det derfra. Nedenstående billedserie illustrerer denne process. Figur 4-2 viser KMD s hjemmeside. For at installere Server rodcertifikatet skal man klikke på "1. Installer KMD-CA Servers rodcertifikat". 10

17 Kapitel 4. Installation og brug af certifikater Figur 4-2. KDE 3, KMD-CA installation af rodcertifikater, startside Figur 4-3 viser siden for installation af KMD-CA s Server rodcertifikat. hjemmeside. For at installere Server rodcertifikatet skal man klikke på "Installer KMD-CA Servers rodcertifikat". 11

18 Kapitel 4. Installation og brug af certifikater Figur 4-3. KDE 3, KMD-CA installation af Server rodcertifikat Figur 4-4 viser KDE 3 s certifikat import dialog. Man kan enten vælge at importere alt (i det her tilfælde er der kun eet certifikat), eller importere et enkelt certifikat ved at klikke på det. 12

19 Kapitel 4. Installation og brug af certifikater Figur 4-4. KDE 3, Certifikat import dialog Figur 4-5 viser detaljer om certifikatet. Figur 4-5. KDE 3, Certifikat import dialog, detaljer Figur 4-6 viser en dialogboks der fremkommer efter at have klikket importer på Figur

20 Kapitel 4. Installation og brug af certifikater Figur 4-6. KDE 3, import succes dialog. Figur 4-7 viser en dialogboks der fremkommer efter at have klikket "Kryptohåndtering..." på Figur 4-5. Figur 4-7. KDE 3, Kryptohåndtering Dialogboksen i Figur 4-7 kan også findes gennem KDE s kontrolcenter. (Det ses at jeg har to KMD-CA certifikater installeret det er fordi jeg også har et KMD-CA test certifikat installeret). Når du har tilføjet rodcertifikatet, kan du tjekke din sikkerhed på KMD-CA s hjemmeside, ved at besøge siden og følge "check sikkerheds" pilene. Når den sikre forbindelse er oprettet kan du klikke på vis sikkerhed i konquerors menu det skulle gerne frembringe et billede som Figur

21 Kapitel 4. Installation og brug af certifikater Figur 4-8. KDE sikkerheds dialog Gnus Certifikater understøttes endnu kun i udviklingsversionen af Gnus. Det er den der også er kendt som Oort Gnus. Metoderne i dette afsnit er afprøvet med nyeste version af Oort Gnus som jeg har hentet fra CVS-arkivet på 4. Kommende versioner af Gnus (versionsnumre højere end og 5.9) vil inkludere certifikatunderstøttelse. Metoden virker under GNU Emacs version 20.3 og nyere og under XEmacs 20.4 og nyere (ældre versioner af Emacs understøttes ikke længere af Gnus). Gnus bruger OpenSSL til håndteringen af certifikater (se Kapitel 2) og i dokumentationen af Gnus anbefales det at OpenSSL bør være version eller højere da der har vist sig fejl med tidligere versioner. I de følgende afsnit beskrives først hvorledes du installerer rodcertifikater samt egen nøgle og certifikat. Dernæst beskrives hvordan du kan håndtere andres certifikater og så slutter vi af med at beskrive hvordan du bruger alle herlighederne til daglig Installer CA-rodcertifikat i Gnus Først og fremmest skal du skaffe dig et rodcertifikat fra en CA og dette skal konverteres til PEM-format. Hvordan dette gøres er beskrevet hhv. i Afsnit 4.1 og i Afsnit 4.2. Det er kun nødvendigt at installere KMD-CA s Kvalificeret Person-rodcertifikat i Gnus. Vi skal nu have fortalt Gnus at den skal benytte rodcertifikatet. Dette kan gøres på to måder. Enten ved at angive en direkte sti til certifikatet eller ved at angive et katalog der indeholder certifikatet. Hvis du vælger sidstnævnte løsning kan du installere rodcertifikater fra flere CA er i kataloget til gengæld er der krav til navngivningen af filen med rodcertifikatetet. Begge metoder konfigureres fra Emacs customize-interface så i Emacs taster du: M-x customize-group RET smime RET hvilket giver mulighed for at konfigurere certifikathåndteringen i Gnus (se Figur 4-9). Udfyld enten "Smime Ca Directory" eller "Smime Ca File". 15

22 Kapitel 4. Installation og brug af certifikater Figur 4-9. Placering af CA-certifikat(er) Rodcertifikater der installeres i kataloget skal som sagt navngives på en særlig måde. Filen skal navngives med X.509 hash-værdien af certifikatet. Det gøres så nemt som: $ mv KMD-CA-KPerson.crt.pem openssl x509 -noout -hash -in KMD-CA-KPerson.crt.pem Installer eget certifikat og privat nøgle i Gnus Du skal naturligvis være i besiddelse af et nøglepar dvs. en offentlig og en privat nøgle. Det er beskrevet andetsteds i denne bog hvordan du skaffer dem. Gnus kræver at den offentlige og den private nøgle samles i en fil, men før vi kan det bliver vi nødt til at konvertere den offentlige nøgle til PEM-format (den private nøgle er allerede i PEM-format hvis du har brugt metoden i denne bog til at generere den med ellers skal den også konverteres). Konvertering af certifikater fra KMD-CA er beskrevet i Afsnit 4.2, men metoden vises også her for fuldstændighedens skyld. For at konvertere den offentlige nøgle (det er den du henter hos KMD-CA og som også kaldes dit personlige certifikat) gør du følgende: $ openssl x509 -inform DER -in cert.crt -outform PEM -out cert.pem Nu skal den offentlige og private nøgle samles til en fil: $ cat Mit_Navn_Nøgle.pem cert.pem > ~/.mit-certifikat og så skal vi have fortalt Gnus at certifikatet eksisterer. Gå atter ind i customize-interfacet i Emacs: M-x customize-group RET smime RET Angiv under "Smime Keys" hvor certifikatet ligger og til hvilken mailadresse det knytter sig (se Figur 4-10). 16

23 Kapitel 4. Installation og brug af certifikater Figur Placering af eget certifikat Gnus skulle nu være i stand til at håndtere dit certifikat Installer andres offentlige nøgler i Gnus Håndteringen af andre folks offentlige nøgler (dem du vil skrive krypteret med) er desværre ikke særlig udbygget i Gnus. Der er implementeret to metoder. Den ene forudsætter at man har nøglen i en fil og angiver den rette fil når man krypterer sine beskeder. Den anden kan hente nøglen på en DNS-server (se RFC ). Førstnævnte metode er standard og fungerer smertefrit og intuitivt. Anden metode er meget lidt brugt (forfatteren af S/MIME delen af Gnus kender kun et certifikat der er gemt på en DNS-server - nemlig hans eget) så den vil ikke blive beskrevet her. Gnus har desværre ingen metoder til automatisk at gemme den offentlige nøgle fra signerede eller krypterede mails man modtager (men det er dog forholdsvis lige til at gemme dem alligevel, se senere). Gnus har desværre heller ingen metoder til at hente offentlige nøgler fra LDAP-nøgleservere (fx ldap://certifikater.kmd.dk). Glade e-lisp-hackere går friskt i gang Send signeret og krypteret e-post fra Gnus For at signere eller kryptere en mail i Gnus skal du under redigeringen fra menuen "Attachments" vælge enten "S/MIME Sign" eller "S/MIME Encrypt" (se Figur Tastaturgenvejene er hhv. C-c RET s s og C-c RET c s. 17

24 Kapitel 4. Installation og brug af certifikater Figur Signering af mail Der bliver indsat en kode i mailen og når man sender mailen afsted (C-c C-c) bliver man spurgt om hvilken nøgle der skal bruges (Figur 4-12) og nøglens passphrase (Figur 4-13). Figur Signering af mail 18

25 Kapitel 4. Installation og brug af certifikater Figur Signering af mail Kryptering foregår ganske tilsvarende. Ydermere bliver man spurgt om i hvilken fil modtagerens offentlige nøgle er Verificer og dekrypter e-post i Gnus Når du læser en krypteret mail spørger Gnus selv om den skal dekryptere mailen (Figur 4-14) og spørger efter din private nøgles passphrase (Figur 4-15). Figur Gnus spørger selv om den skal dekryptere en krypteret mail 19

26 Kapitel 4. Installation og brug af certifikater Figur Din private nøgles passphrase skal bruges ved dekryptering af mail Hvis du læser en mail der blot er signeret bliver den ikke automatisk verificeret og du bliver heller ikke spurgt om du vil verificere den. Du kan kende en signeret (og en krypteret) mail på det lille "p" i statuslinjen (se Figur 4-16). Figur Det lille "p" fortæller at mailen er signeret og/eller krypteret Den store "knap" (teksten mellem "[[" og "]]", se Figur 4-17) der også fortæller om signaturen er o.k. vises ikke som standard af Gnus. For at få den at se skal du tilføje følgende til din.gnus: (setq gnus-buttonized-mime-types ("multipart/signed")) 20

27 Kapitel 4. Installation og brug af certifikater Figur Denne "knap" indeholder information om signaturen For at verificere den signerede mail vælges menuen "Article / MIME" og menupunktet "Verify and Decrypt" (Figur 4-18) eller tastaturgenvejen W s. Når mailen er verificeret vises resultatet i knappen (se Figur 4-19). Figur Vælg dette punkt for at verificere en signeret mail 21

28 Kapitel 4. Installation og brug af certifikater Figur Signaturen var i orden Knappen er som sagt en knap og hvis man klikker på den med midterste museknap eller placerer cursoren (point) på den og taster return vises al information om signaturen og certifikatet. Et uddrag af disse oplysninger kan ses på Figur I blandt oplysningerne kan man også finde afsenderens offentlige nøgle og det er således muligt med almindelige, simple Emacs-kommandoer at gemme nøglen til senere brug (marker region, M-x write-region). Figur Oplysninger om signaturen og certifikatet 22

29 Kapitel 4. Installation og brug af certifikater Slutbemærkning: ldap://certifikater.kmd.dk 23

30 Kapitel 4. Installation og brug af certifikater 24

31 Kapitel 5. Introduktion til sslugsig Programmet "sslugsig" er et program som et medlem af SSLUG, Erling Sjørlund, har skrevet og stillet til rådighed Målet med sslugsig Ideen med sslugsig er at give en let adgang til at oprette en ansøgning til KMD-CA om en personlig digital signatur. Samtidig tjener det som en øvelse i at udvikle og distribuere et Kylix-program. Figur 5-1 viser sslugsigs hovedvindue, med et par felter udfyldt. Figur 5-1. sslugsig, oversigt sslugsig kan enten anvendes af en enkelt bruger, lidt på samme måde som Windows programmet omtalt i Kapitel 1, eller installeres til brug for flere brugere. Hvis du har valgt at installere programmet til brug for flere brugere, skal du køre programmet som root efter installation. 25

32 Kapitel 5. Introduktion til sslugsig Figur 5-2. sslugsig, indtastning af domænenavn Første gang du kører programmet som root, vil det bede om systemets domænenavn (som vist på Figur 5-2) og gemme dette i filen /usr/local/etc/sslugsig.conf. Denne fil er ganske enkel - domainnavnet skal stå i første linje. Findes filen, vil sslugsig sætte login@domain.dk som adresse for almindelige brugere, findes den ikke sættes kun login@. (Her er det teksten domain.dk, der skal stå i filen.) Alle felter skal udfyldes før knappen "Opret anmodning" bliver aktiv. Samtidigt med at dette sker, dukker en række linjer op i bunden af skærmbilledet, som illustreret på Figur

33 Kapitel 5. Introduktion til sslugsig Figur 5-3. sslugsig, generering af certifikat forespørgsel Linjerne i bunden viser indholder af den request.config fil, der dannes, og sendes som grundlag til programmet openssl. (For de interesserede er denne fil og fremgangsmåden dokumenteret i Kapitel 6). Bemærk statuslinjen i midten af skærmen. I denne linje vises information om de fejl og mangler, der måtte være i indtastningen. Eftersom KMD-CA ikke pt. understøtter danske tegn, vil brug af den slags medføre, at programmet viser en fejlmelding. Der er gjort klar til at åbne for de danske tegn, når KMD-CA (og resten af verden) er klar til at understøtte det.. Baggrunden for KMD-CA s beslutning er angiveligt, at ikke alle browsere understøtter (dvs. kan fremvise indholdet af) signaturer med danske tegn. 27

34 Kapitel 5. Introduktion til sslugsig Et klik på "Opret anmodning" vil generere to filer som bliver gemt i et katalog ved navn.sslugsig i den aktuelle brugers $HOME dir: $HOME/.sslugsig/keyfile.pem er brugerens nye private nøgle. $HOME/.sslugsig/kmd-ca-cert.req er den fil, der skal sendes til KMD-CA s server. $HOME/.sslugsig/request.config betragtes som en midlertidig fil. Den dannes under oprettelsen af en anmodning, men slettes igen straks efter, da det ikke er i nogens interesse, at man senere kan læse adgangskoden i klar tekst. Desværre kan man ikke direkte sende sin forespørgsel til KMD-CA, det skal ske via deres hjemmeside. Du kan se mere om denne proces i Afsnit Download De relevante filer er opdelt i forskellige pakker, så du kan hente hvad der nu er mest behov for. Du kan hente alle pakker fra SSLUGs FTP server (ftp://ftp.sslug.dk/pub/signatur/). De efterfølgende henvisninger peger alle på den seneste version af pakkerne. For at installere, skal du lægge pakken i det dir, du ønsker at placere pakken under. Forslag: /usr/local. Herefter pakker du ud med kommandoen tar -zxvf filnavn.tgz, hvilket vil oprette et subdir ved navn sslugsig under det aktuelle dir, fx /usr/local/sslugsig. Der er i pakkerne to forskellige start scripts, nemlig signatur og startsig. Det første kræver at programmerne readlink og basename er installeret på din maskine. Så tillader det til gengæld, at sslugsig er installeret hvor som helst i dit filhieraki. (Programmerne readlink og basename er installeret på langt de fleste Linux maskiner.) startsig er mere primitivt. Her skal du ind og redigere stierne, hvis du vælger at installere i et andet dir end /usr/local/sslugsig Er det runtime-pakken eller pakken med alt, mangler du blot at lægge et symlink ind i /usr/bin, hvor alle dine brugere kan komme til at kalde det. Dette gøres med kommandoen: ln -sf /usr/local/sslugsig/signatur /user/bin/signatur eller evt. med ln -sf /usr/local/sslugsig/startsig /user/bin/signatur. Enhver bruger på systemet kan nu blot give kommandoen signatur, og fylde felterne ud. Den første gang programmet køres, bør det ske af bruger root, idet du dermed får lejlighed til at fylde systemets domainnavn ind i filen /usr/local/etc. Dette vil give de andre brugere en meningsfuld (måske) mailadresse som standard. RPM pakken placeres i /usr/local hvorefter den installeres med kommandoen rpm -ivf sslugsig i386.rpm Bemærk, at.rpm pakken under test på min RedHat kræver --force til slut i kommandoen, altså: rpm -ivf sslugsig i386.rpm --force Det kan ikke afvises, at det er fejlede eksperimenter, der forårsager dette problem Kildetekst og startscript sslugsig-prog tgz 2 (7 KB) Hvis du har Kylix2 installeret (kan hentes fra 3 ), skal du blot hente kildeteksten og startscriptet Program, libs og startscript sslugsig-runtime tgz 4 (3.5 MB) sslugsig i386.rpm 5 (3.5 MB) Her får du programmet selv, det nødvendige startscript og de nødvendige lib filer, vigtige filer der ikke normalt findes på en maskine uden Kylix2 installeret. med denne pakke installeret under /usr/local/sslugsig vil alle brugere kunne danne en ansøgning om digitalt signatur. 28

35 Kapitel 5. Introduktion til sslugsig Programmets dokumentation sslugsig-doc tgz 6 (241 KB) Dokumentationen er skrevet i sgml og derefter kompileret til hhv html og pdf format Alle filer i projektet sslugsig-alt tgz 7 Her er simpelthen alle de filer, der indgår fra kildetekst over dokumentation og libs til det kompilerede program Installation Der lægges op til, at filerne placeres under /usr/local/sslugsig hvor der er en opdeling i 3 subdir: libs/, src/ og doc/ Under libs/ placeres nogle libfiler og symlinks til samme. Disse filer er det sædvanligvis nødvendigt at have i netop den medsendte version. Under src/ findes programmets kildetekst. Denne kan du blot slette igen, hvis du ikke er interesseret i den. doc/ indeholder en lille introduktion i html-format, som kan gøres tilgængelig på hjemmesiden Lidt om kildeteksten Kildeteksten er kommenteret, så dette afsnit er blot for at uddybe ideerne bag et par af de beslutninger, der er truffet Kontrol af indtastningen Indtastningen kontrolleres når et felt forlades. Kontrollen sker rent teknisk ved at der opbygges en fejltekst. Har denne en længde større end nul er der en fejl, og knappen "Opbyg anmodning" gøres passiv. Kontrollen omfatter følgende delemner: Kontrol af navne Eftersom KMD-CA pt. ikke tillader danske tegn i navne kontrolleres de to navnefelters bogstaver. I praksis opsamles de illegale tegn i fejlteksten. Der gøres således ikke noget forsøg på at oversætte - stavefejl er en brugerbeslutning. Programmet er forberedt til fremtiden, hvor danske tegn bliver tilladt, idet der er lagt et afkrydsningsfelt ind, som tillader eller ignorerer tegnkontrollen. Eftersom der opstår fejl i openssl, hvis der ikke er både for og efternavn, kontrolleres det også, at de to navnefelter har en længde større end nul Kontrol af adgangskoden Adgangskoden skal (i dette program) være mindst 5 tegn lang. Om dette er fornuftigt eller ej skal jeg ikke kunne sige, men det er ikke et usædvanligt krav, så der skal nok være nogle, der har fundet ud af, at dette minimum er passende. Eftersom man ikke kan komme til at se adgangskoden senere og indtastningen sker skjult, skal man være i stand til at gentage koden korrekt Kontrol af adresse Programmet forsøger at opbygge en fornuftig adresse i form af loginnavn + servernavn. Det lykkes kun, hvis brugerne rent faktisk har deres loginnavn som mailadresse, og domainnavnet er oplyst i filen /usr/local/etc/sslugsig.conf. Der er dog altid en kontrol af at mailadressen indeholder og. (punktum), lige som det kontrolleres, at der overhovedet eksisterer en mailadresse. 29

36 Kapitel 5. Introduktion til sslugsig Placering af output Figur 5-4. sslugsig, placering af output Som det fremgår af Figur 5-4 herover, gemmes der to filer under brugerens $HOME/.sslugsig dir. Slutbemærkning: 1. ftp://ftp.sslug.dk/pub/signatur/ 2. ftp://ftp.sslug.dk/pub/signatur/sslugsig-prog tgz ftp://ftp.sslug.dk/pub/signatur/sslugsig-runtime tgz 5. ftp://ftp.sslug.dk/pub/signatur/sslugsig i386.rpm 6. ftp://ftp.sslug.dk/pub/signatur/sslugsig-doc tgz 7. ftp://ftp.sslug.dk/pub/signatur/sslugsig-alt tgz 30

37 Kapitel 6. Information til programmører Dette kapitel indeholder information til de der ønsker at udvikle programmer, der automatiserer de processer, der er beskrevet i de foregående afsnit. Det antages at man vil gøre det som en frontend til openssl programmet og derfor beskrives hvorledes dette kan gøres. Disse informationer handler udelukkende om at danne en certifikat forespørgsel til KMD-CA Dannelse af certifikat forespørgslen Man bør sætte sig ind i hvordan req programmet anvendes. Det er en del af openssl programmet. Basalt set kan req lave en x.509 request som den der eftersøges, hvis det gives en række informationer. Den nemmeste måde at få disse informationer videregivet til req er ved at indkode de enkelte parametre i en fil som man giver som config fil til req programmet. Dette er også at foretrække sikkerhedsmæssigt, idet f.eks. password overført via kommandolinjen ikke er hensigtsmæssigt, da de kan ses af andre processer på systemet. Bemærk, at der pt. er begrænsninger på brugen af æøå ÆØÅ (og andre specialtegn) i forhold til KMD-CA. Kun a-z, A-Z og 0-9 er tilladt Eksempel på forespørgselsdannelses fil Nedenfor gives et eksempel på hvordan en forespørgselskonfigurationsfil til programmet openssl kan se ud. Linjer der starter med tegnet # er kommentarer. # Eksempel på request config fil. # Anvendes eksempelvis således: # openssl req -newkey rsa:1024 -config req.config -out \ # kmd-ca-cert.req -outform DER # Bemærk at der sættes to password i denne fil, dels et for den # private nøgle (output_password), dels et challengepassword, som jeg ikke # rigtigt ved hvad skal bruges til. # Måske vil man give brugeren adgang til at undlade at sætte # et password for den private nøgle (vil man???). # Formatet for denne fil er defineret dels i req(1) og dels i config(1) # reg sectionen definerer hvordan filen hænger sammen - hvilke øvrige # sektioner der skal inkluderes mv. [ req ] prompt = no default_bits = 1024 default_md = sha1 default_keyfile output_password distinguished_name attributes = keyfile.pem = private_key_password = req_distinguished_name = req_attributes # Oplysninger om "distinguished name", se f.eks. # # Bemærk, kun felter der medtages i KMD-CA s program er medtaget her # I KMD s udgave har brugeren kun adgang til at angive givenname, # surname, og keyusage [ req_distinguished_name ] C = DK O = Ingen organisatorisk tilknytning CN = Joern Guldberg // PID:xxxxxxxxx address = jgu@kmd.dk givenname = Joern surname = Guldberg keyusage = Digital Signature, Data Encipherment, Key Agreement, Non Repudiation, Key E serialnumber = xxxxxxxxx # Strengt taget ved jeg ikke om denne sektion er nødvendig # Faktisk ved jeg ikke hvad den gør. Man siden lægger op til at den # muligvis ikke er nødvendig overhovedet - afhænger vist lidt # af vores CA (KMD-CA). [ req_attributes ] 31

38 Kapitel 6. Information til programmører challengepassword = tester Antag at ovenstående er indholdet af filen req.config. Herefter kan man danne en request fil kaldet kmd-ca-cert.req således: $ openssl req -newkey rsa:1024 \ -config req.config -out kmd-ca-cert.req -outform DER Using configuration from req.config Generating a 1024 bit RSA private key writing new private key to keyfile.pem $ ls -l totalt 20 -rw-rw-r-- 1 madsdyd madsdyd 951 mar 22 08:16 keyfile.pem -rw-rw-r-- 1 madsdyd madsdyd 1052 mar 22 07:45 req.config -rw-rw-r-- 1 madsdyd madsdyd 539 mar 22 08:16 kmd-ca-cert.req Det er filen kmd-ca-cert.req der er forespørgslen, som skal videresendes til KMD-CA Beskrivelse af de enkelte felter I realiteten er det relativt få felter der skal ændres i en request config fil. I det følgende forsøges de relevante felter beskrevet. givenname - personens fornavn (og eventuelle mellemnavne) indsættes her surname - personens efternavn indsættes her address - personens adresse indsættes her keyusage - Se nedenfor i afsnit Afsnit CN - værdien af givenname surname appended med strengen "// PID:xxxxxxxxx" serialnumber - dette felt skal ikke ændres når man bruger KMD-CA som CA. Det er beskrevet på en side hos Ministeriet for Videnskab, Teknologi og Udvikling om Personspecifikke Identifikationsnumre keyusage Dette felt sættes efter brugerens valg for hvordan nøglen skal bruges; "Kryptering og digital signatur", "Kun kryptering" eller "Kun signatur". Se Figur 1-1 for de valg Windows programmet giver. Følgende er baseret på oplysninger fra Jørn Guldberg, projektleder i KMD-CA. keyusage sættes til en kommasepareret liste af strenge. For signering sættes "Digital Signatur". For kryptering sættes "Data Encipherment". For begge dele, sættes begge dele. Man skal altid tilføje følgende liste: "Key Agreement, Non Repudiation, Key Encipherment". 32

39 6.2. Eksempel program til generering af forespørgsel Kapitel 6. Information til programmører I eksemplet nedenfor kan du se et interaktivt perl program der laver en forespørgsel baseret på de informationer brugeren taster ind. Bemærk, at det er et eksempel og ikke nødvendigvis velegnet til slutbrugerbrug. Scriptet kan hentes 2. #! /usr/bin/perl -w # Script der laver en kmd-ca certifikat forespørgsel. # Følgende oplysninger kræves fra brugeren: # Æ Ø Å eller ae oe aa i certifikatet? # givenname # surname # # keyusage # om den private nøgle skal enkrypteres # eventuelt password for denne nøgle # NB: Dette script er ikke tænkt som et "rigtigt" slutbrugerprogram, men som en # illustration af hvordan en forespørgsel kan opbygges og laves. Så vidt vides # indeholder programmet ingen fejl og har den fulde funktionalitet til at lave # en certifikat forespørgesel til brug for KMD-CA. # Dette script frigives valgfrit under "Åben dokumentlicens" (ÅDL) eller # Gnu Public Licensen (GPL )v. 2. # Oprindeligt lavet af Mads Bondo Dydensborg (madsdyd@challenge.dk) # Tilføjelser af Klavs Klavsen og Christian Boesgaard # Copyright 2002 Mads Bondo Dydensborg. ################################################################################ # Check at brugeren ikke gav nogen argumenter $arg = shift(@argv); if (defined $arg && $arg ne "") { print STDERR "Brug: $0\n\tInteraktivt certifikat forespørgelses skaber program for KMD-CA\n"; exit 1; } ################################################################################ # Check at man kan køre openssl $openssl = which openssl ; if ("" eq $openssl) { print STDERR "Fejl: Du skal have installeret openssl programmet\n"; print STDERR "og det skal være tilgængeligt i din PATH (udførbart)\n"; print STDERR "Dette program kan fås fra print STDERR "De fleste distributioner inkluderer dog dette program\n"; exit 1; } ################################################################################ # Vi bruger ReadLine til at læse ting ind med - for at give en rimelig # indlæsningsgrænseflade use Term::ReadLine; $term = new Term::ReadLine Certifikat ; $prompt = "> "; ################################################################################ # Lidt info til brugeren print "Dettte program vil lave en certifikat forespørgsel til KMD-CA for dig.\n\n"; print "Du skal indtaste en række oplysninger\n"; print "Efter indtastning af hver oplysning skal du trykke på enter/return\n"; print "For oplysninger hvor der gives flere valg, kan du som regel trykke enter for den\n"; print "mest almindelige værdi. Denne vil være illusteret med et stort bogstav.\n\n"; ################################################################################ # Læs de nødvendige værdier 33

40 Kapitel 6. Information til programmører do { $prompt = "Indtast dit fornavn(e) : "; $givenname= $term->readline($prompt); $prompt = "Indtast dit efternavn : "; $surname = $term->readline($prompt); $prompt = "Indtast din adresse : "; $ address = $term->readline($prompt); print "\ncertifikatet kan bruges til enkryptering, signering eller begge dele\n"; print "Hvad skal det bruges til? [E]nkryptering, [S]ignering eller [B]egge?\n"; $prompt = "Angiv hvad certifikatet skal bruges til [e/s/b] : "; $keyusage = $term->readline($prompt); if ("e" eq $keyusage "E" eq keyusage) { $keyusage = "Data Enchiperment"; } else { if ("s" eq $keyusage "S" eq $keyusage) { $keyusage = "Digital Signature"; } else { $keyusage = "Digital Signature, Data Enchiperment"; } } print "\nnogle Certifikat udstedere understøtter ikke ÆØÅ (såsom KMD) og skal\n"; print "du bruge certifikatet med en sådan udsteder skal du svare J her, så\n"; print "konverteres Æ, Ø, Å, til henholdsvis Ae, Oe, Aa.\n"; $prompt = "Ønsker du at få konverteret ÆØÅ? [J/n] : "; $convert = $term->readline($prompt); #Konverter æøå og ÆØÅ hvis der blev valgt J ovenfor. if ($convert eq "J" "" eq $convert) # do ÆØÅ conversions { foreach ($givenname,$surname,$ address) { #printf "Konverterer ÆØÅ...\n"; $_ =~ s/æ/ae/g; # $_ =~ s/ø/oe/g; # $_ =~ s/å/aa/g; # $_ =~ s/æ/ae/g; # $_ =~ s/ø/oe/g; # $_ =~ s/å/aa/g; # } } printf "\ndet anbefales at man beskytter sin private nøgle med en adgangskode\n"; printf "Indtast en sådan - bemærk at den vil blive skrevet til skærmen!\n"; $prompt = "Angiv adgangskode : "; $output_password = $term->readline($prompt); ################################################################################ # Bekræft 34 print "\nher er de informationer du indtastede.\n\n"; print "NB. Bemærk at hvis du svarede J til Konverter ÆØÅ, vil alle ÆØÅ og\n"; print " æøå være repræsenteret som Ae,Oe,Aa og ae, oe, aa nedenfor.\n\n"; print "Fornavn : $givenname\n"; print "Efternavn : $surname\n"; print " $ address\n"; print "Nøglebrug : $keyusage\n"; print "Konverter ÆØÅ : $convert\n"; print "Adgangskode : $output_password\n\n"; $prompt = "Er informationerne korrekte? [J/n] : "; $OK = "J"; $OK = $term->readline($prompt); if ("j" eq $OK "" eq $OK) {

41 Kapitel 6. Information til programmører $OK = "J"; } } while ($OK ne "J"); ################################################################################ # Informationerne er OK - lav forespørgselsfilen # Vi skal bruge en midlertidig fil, som skal være læsebeskyttet for andre # Jeg ved ikke rigtigt hvordan man laver det smart i Perl. $filename = "request.config.$$"; open (CONFIG, ">$filename") die "Kunne ikke åbne filen $filename - krævet for at forsætte\n"; chmod 0600, $filename die "Kunne ikke sætte rettigheder på $filename - krævet for at forsætte\n"; # Opbyg et par oplysninger $fileprefix = $givenname."_".$surname; $fileprefix =~ s/\s/\_/g; $keyfile = $fileprefix."_nøgle.pem"; $reqfile = $fileprefix."_anmod.req"; $CN = "$givenname $surname // PID:xxxxxxxxx"; # Skriv oplysninger til fil print CONFIG "[ req ] prompt = no default_bits = 1024 default_keyfile output_password distinguished_name = $keyfile = $output_password = req_distinguished_name [ req_distinguished_name ] C = DK O = Ingen organisatorisk tilknytning CN = $CN address = $ address givenname = $givenname surname = $surname keyusage = $keyusage serialnumber = xxxxxxxxx "; close (CONFIG) die "Kunne ikke lukke $filename - krævet for at forsætte\n"; ################################################################################ # OK, nu er vi klar til at køre openssl. print "Information: Starter openssl (god ting)\n"; $status = system("openssl req -newkey rsa:1024 -config $filename -out $reqfile -outform DER"); # Slet config filen $del = unlink ($filename); if (1!= $del) { print STDERR "Advarsel: Det var ikke muligt at slette $filename\n"; } else { print "Information: Den midlertidige fil er blevet slettet (god ting)\n"; } if (0!= $status) { print STDERR "Fejl: Der var en fejl under udførelsen af openssl kommandoen\n"; print STDERR "En anmodningsfil er _ikke_ blevet lavet\n"; exit 1; } print "\nsucces!\n"; print "\nto filer er blevet lavet:\n\n"; 35

42 Kapitel 6. Information til programmører print "\"$reqfile\" er den anmodningsfil KMD-CA skal have\n"; print "\"$keyfile\" er din private nøgle\n"; print "\nnb: Du må ikke lade andre få adgang til din private nøgle!\n"; Eksempel på anvendelse af scriptet: $./req-kmd-ca.pl Dettte program vil lave en certifikat forespørgsel til KMD-CA for dig. Du skal indtaste en række oplysninger Efter indtastning af hver oplysning skal du trykke på enter/return For oplysninger hvor der gives flere valg, kan du som regel trykke enter for den mest almindelige værdi. Denne vil være illusteret med et stort bogstav. Indtast dit fornavn(e) : Anders Benjamin Indtast dit efternavn : Christensen Indtast din adresse : abc@example.org Certifikatet kan bruges til enkryptering, signering eller begge dele Hvad skal det bruges til? [E]nkryptering, [S]ignering eller [B]egge? Angiv hvad certifikatet skal bruges til [e/s/b] : B Nogle Certifikat udstedere understøtter ikke ÆØÅ (såsom KMD) og skal du bruge certifikatet med en sådan udsteder skal du svare J her, så konverteres Æ, Ø, Å, til henholdsvis Ae, Oe, Aa. Ønsker du at få konverteret ÆØÅ? [J/n] : J Det anbefales at man beskytter sin private nøgle med en adgangskode Indtast en sådan - bemærk at den vil blive skrevet til skærmen! Angiv adgangskode : abctester Her er de informationer du indtastede. NB. Bemærk at hvis du svarede J til Konverter ÆØÅ, vil alle ÆØÅ og æøå være repræsenteret som Ae,Oe,Aa og ae, oe, aa nedenfor. Fornavn : Anders Benjamin Efternavn : Christensen abc@example.org Nøglebrug : Digital Signature, Data Enchiperment Konverter ÆØÅ : J Adgangskode : abctester Er informationerne korrekte? [J/n] : J Information: Starter openssl (god ting) Using configuration from request.config.6854 Generating a 1024 bit RSA private key writing new private key to Anders_Benjamin_Christensen_Nøgle.pem Information: Den midlertidige fil er blevet slettet (god ting) Succes! To filer er blevet lavet: "Anders_Benjamin_Christensen_Anmod.req" er den anmodningsfil KMD-CA skal have "Anders_Benjamin_Christensen_Nøgle.pem" er din private nøgle NB: Du må ikke lade andre få adgang til din private nøgle! 36

43 6.3. Videresendelse af forespørgsel til KMD-CA Kapitel 6. Information til programmører Proceduren er beskrevet på 3. Bemærk at KMD-CA s rodcertifikat skal være installeret, inden man kan besøge disse sider. Nedenfor er vist en række skærmbilleder fra registreringsprocessen. KMD-CA kræver at forespørgselsfilen ender i.req.(som det fremgår er der fejl i proceduren for mine værdier min accepteres ikke. Det skyldes muligvis mit valg af browser således er det muligt at f.eks. Mozilla 1.0 virker uden problemer. Dette afsnit vil blive opdateret i en kommende udgave af denne bog). Figur 6-1. KMD-CA upload, skridt 1 37

44 Kapitel 6. Information til programmører Figur 6-2. KMD-CA upload, skridt 2 Figur 6-3. KMD-CA upload, skridt 3 38

45 Kapitel 6. Information til programmører Figur 6-4. KMD-CA upload, skridt 4 Figur 6-5. KMD-CA upload, skridt 5 39