UNINETT Fagspesifikasjon ANBEFALT SIKKERHETSLØSNING FOR TRÅDLØSE NETTVERK IMPLEMENTASJON AV IEEE 802.IX UFS nr.: 112 Versjon: 1 Status: Godkjent Dato: 20. 12. 2007 Tittel: IEEE 802.IX for trådløse nettverk Arbeidsgruppe: Mobilitet Forfatter: Jardar Leira Ansvarlig: Jardar Leira Kategori: Anbefaling Ugyldiggjøring:
Sammendrag Dette dokumentet gir en orientering om de ulike sikkerhetsmekanismene som er tilgjengelig for trådløse nettverk. Det beskrives kort svakhetene ved bruk av MAC-adressefilter, WEP, Web-portaler og VPN og anbefaler 802.1X basert gjensidig autentisering som beste alternativ. EAP ved bruk av TLS, PEAP og TTLS er anbefalte alternativer som også kan støttes samtidig av systemet. Standarden IEEE 802.11i og bedre kjent som WPA og WPA2 med henholdsvis TKIP og AES kryptering. AES kryptering er det foretrukne men TKIP er et kompromiss ved manglende AES støtte hos klientene. Sertifikatgenerering kan være komplisert å sette seg inn i men dokumentet inneholder script som kan forenkle prosessen. eduroam er et internasjonalt RADIUS-hierarki hos akademiske institusjoner som gjør at brukere kan logge seg på trådløsnettet hos andre medlemsinstitusjoner med sitt eget brukernavn og passord. Innhold 1. Definisjoner 2. Bakgrunn 3. IEEE 802.11i med IEEE 802.1X, TKIP og AES 3.1 802.11i og WPA/WPA2 3.2 Elementene i 802.1X 3.3 Sertifikater og brukerautentisering 3.4 Kryptering 4. Sertifikatgenerering på SAMSON3 (Linux) 4.1 Lage CA root-sertifikat og etablere sertifikathierarki 4.2 Lage serversertifikat 4.3 Lage klientsertifikat 4.4 Script for å generere sertifikat 5. Kjøp av sertifikat fra UNINETT SCS 6. Konfigurasjon av FreeRADIUS på SAMSON3 (Linux) 7. Konfigurasjon av basestasjon/kontroller 8. Konfigurasjon av klient 9. Dynamisk tildeling av VLAN 10. eduroam 11. Oppsummering og anbefaling 12. Referanser 13. Intellektuelt eierskap 14. Forfatters adresse 2
1. Definisjoner AES: Advanced Encryption Standard, en svært sikker krypteringsalgoritme. CA: Certificate Authority er en entitet som utsteder sertifikater som andre parter kan bruke. CA er en pålitelig tredjepart som alle partene skal kunne bruke for å verifisere hverandre. BSSID: Basic Service Set ID, MAC adressen til en trådløs basestasjon. EAP: Extensible Authentication Protocol, protokoll som frakter autentiseringsprotokollen i et 802.1X sikret nettverk. EAPOL: EAP over LAN, EAP protokollen som går på lag 2 på nettverket. IEEE: Institute of Electrical and Electronics Engineers, organisasjon som utarbeider standarder for bl.a. datakommunikasjon. IEEE 802.11: Den første standarden for trådløst nettverk slik vi er vant med i dag. Baserte seg på bruk av frekvenser på 2.4GHz men definerte to ulike transmisjonsteknikker: Frequency Hopping Spread Spectrum (FHSS) og Direct Sequence Spread Spectrum (DSSS). Begge hadde overføringshastighetene 1Mbps og 2Mbps. I tillegg var det også definert bruk av IR men det ble aldri implementert for markedet. IEEE 802.11 DSSS har vært basisen for IEEE 802.11b. DSSS definerte kanalene 1 til 11 (USA), 1 til 13 (Europa) og 1 til 14 (Japan) for 2.4Ghz frekvensene. En del av disse kanalene overlapper. IEEE 802.11i: Standard for bruk av 802.1X og TKIP eller AES kryptering i trådløse nettverk. IEEE 802.1X: Standard for portbasert autentisering ved hjelp av protokollen EAP. En port kan være en fysisk nettverkskontakt i en switch eller en virtuell kobling mellom en assosiert klient og en basestasjon. MAC: Media Access Control, en unik adresse alle nettverksenheter må ha PKI: Public Key Infrastructure, et hierarkisk system der man har en CA og underliggende server og brukersertifikat. Hvert sertifikat er unikt og kan verifiseres av CA. RADIUS: Navn på en protokoll som benyttes av en RADIUS server. En RADIUS server er en autentiseringsserver. SAMSON3: UNINETT standard linux servermaskin for e-mail, DNS, web server, RADIUS, m.m. SCS: Server Certificate Service SSID: Service Set ID, identifiserer et spesifikt trådløsnett. Flere basestasjoner kan ha samme SSID for å ta del i et større nettverk. 3
SSL: Secure Sockets Layer, kryptert kommunikasjonskanal. TKIP: Temporal Key Integrity Protocol, en RC4 kryptering som er en forbedring av WEP. Trådløst nettverk: Et "trådløst nettverk" er i utgangspunktet lite spesifikt og kan omfatte mange ulike typer teknologi. Dette dokumentet definerer trådløse nettverk som gjengitt i standardene IEEE 802.11, IEEE 802.11b, IEEE 802.11g, IEEE 802.11a og IEEE 802.11n. VPN: Virtual Private Network, kryptert kommunikasjonskanal WEP: Wired Equivalent Privacy, trådløs kryptering definert i IEEE 802.11. Wi-Fi Alliance: Interesseorganisasjon med omtrent alle produsenter av trådløst utstyr som medlemmer. Utarbeider testkriterier og sertifiserer produkter som møter disse kriteriene. Tanken er en trygghet for forbrukeren som skal kunne stole på at produktet han kjøper virker med produkter fra andre leverandører. WPA: Wi-Fi Protected Access. Sertifisering av utstyr som møter Wi-Fi Alliance sine krav om funksjonalitet i henhold til IEEE 802.11i standarden. Dvs. støtte TKIP kryptering. WPA2: Wi-Fi Protected Access 2. Sertifisering av utstyr som møter Wi-Fi Alliance sine krav om funksjonalitet i henhold til IEEE 802.11i standarden. Dvs. støtte AES kryptering. 4
2. Bakgrunn Trådløse nettverk er i utgangspunktet langt mindre sikkert enn et kablet nettverk. Utgangspunktet for det argumentet er at trådløse nettverk er basert på bruk av radiobølger og dermed kringkaster alle de data som blir overført mellom klienter og basestasjoner. Følgelig kan noen innen rekkevidde lytte til all kommunikasjon. Med en ekstra kraftig antenne kan også rekkevidden for denne avlyttingen utvides betraktelig. Mangelen på kabel mellom klienten og tilkoblingspunktet kan også være et sikkerhetsproblem da en basestasjons identitet (SSID og BSSID) enkelt kan forfalskes da de ikke er ment å være brukt som sikkerhetstiltak. Klienten kan derfor ikke stole på at den basestasjonen en er tilkoblet er den ekte, med de følger det kan få for videre datakommunikasjon. På den andre siden kan heller ikke basestasjonen stole på at klienten er en gyldig bruker fordi det eneste som trengs fra klientens side er korrekt SSID. Oppsummert kan vi si at trådløse nettverk har to sikkerhetsmessige utfordringer: 1 - Sikker, gjensidig autentisering av basestasjon og klient 2 - Datakommunikasjon sikret mot avlyttning og forfalskning Med dette som bakgrunn har vi fått se flere ulike metoder for å gjøre trådløse nett sikrere. MAC adresselister - Kun klienter med godkjent, registrert MAC adresse får assosiere seg til basestasjonene. Svært tungt å vedlikeholde og gir ingen sikkerhetsmessig gevinst da en MAC adresse er lett å finne og lett å forfalske. Det gir heller ingen kryptering av datakommunikasjonen. WEP kryptering - Finnes med ulike krypteringsgrader (RC4). En felles, delt hemmelighet må være kjent for å få assosiert seg til basestasjonen og sørger samtidig for kryptering av datakommunikasjonen. WEP har flere svakheter og kan i dag knekkes på under ett minutt ved hjelp av programvare lett tilgjengelig på Internet. En delt hemmelighet skalerer dårlig og all datakommunikasjon blir kryptert likt slik at om man kjenner nøkkelen så kan man lytte til all datakommunikasjon. Web-portaler - Klienten kobler seg til et ukryptert og åpent trådløst nett. Når brukeren prøver å bruke sin webleser til å aksessere en ekstern side, blir forespørselen omdirigert til en web-basert innloggingsside for nettverket. Siden er som regel beskyttet med kommunikasjon over SSL. Dette er en brukervennlig løsning som er mye brukt i såkalte "hot-spots" og offentlig tilgjengelige trådløsnett. Det er en gjensidig autentisering av system og klient gjennom SSL men i praksis er det for enkelt for brukeren å overse varsler om feil i sertifikatet eller at det i det hele tatt blir brukt SSL. Siden det ikke er noen verifisering av tilkoblingspunktet (basestasjonen) så er denne løsningen svært utsatt for Man-in-the- Middle og Phishing. Datakommunikasjon blir heller ikke kryptert. Man bør generelt være svært aktsom som bruker av slike systemer. VPN Man definerer et ellers helt åpent trådløst nett som "usikkert, eksternt nett" og så tillate kun trafikk mellom konsentrator og trådløse klienter. Klienter blir nødt til å autentisere seg mot VPN konsentratoren for å få opprettet en kryptert tunnel som når ut av trådløsnettet. Metoden gir høy sikkerhet med gjensidig autentisering og individuell kryptering av datakommunikasjonen. Men det stiller store krav til kapasitet hos konsentratoren da 5
alle trådløse brukere vil måtte bruke den. Klientprogramvaren kompliserer ytterligere og gir et stort behov for brukerstøtte, samt at det gjerne er begrenset tilgjengelighet for alle OS. Kort tid etter at de trådløse brukerne i verden hadde blitt gjort kjent med at WEP var blitt knekt, kom det masse krav om at det måtte komme noe som sikret trådløse nettverk på en god og enkel måte. Da hadde IEEE allerede vært i god gang med å utvikle standarden 802.11i og med den skulle vi få noe som løste begge de to sikkerhetsmessige utfordringene. 6
3. IEEE 802.11i med IEEE 802.1X, TKIP og AES IEEE 802.11i er vår anbefalte sikkerhetsløsning for trådløse nett. Vi gjør her rede for denne standarden. 3.1 802.11i og WPA/WPA2 Med IEEE standarden 802.11i har vi fått en mulighet for å bruke IEEE 802.1X for autentisering også i trådløse nettverk. Mens 802.11i standarden var under utvikling, lanserte Wi-Fi Alliance noe de kalte WPA. Den benytter seg av 802.1X for autentisering og TKIP som kryptering. Da 802.11i ble ferdig, kom WPA2 som er 802.1X med AES som kryptering. "802.11i" er ikke så godt kjent av brukere som "WPA" og "WPA2" men man kan si at WPA og WPA2 er Wi- Fi Alliance sin sertifisering av produkter som har implementert 802.11i på en måte som gjør dem kompatible med andre WPA-sertifiserte produkter. At et produkt er WPA/WPA2 sertifisert skal være en trygghet for at brukeren har utstyr som vil fungere med utstyr fra andre produsenter. WPA og WPA2 finnes hver i to varianter, "Enterprise" og "PSK" (Pre-Shared Key). Enterprise benytter seg av 802.1X og er godt egnet for bedriftsnett mens PSK benytter seg av en delt hemmelighet på 64 heksadesimale tegn og er beregnet på hjemmeløsninger. PSK er i utgangspunktet en uegnet løsning for en akademisk institusjon, men siden svært mange også har en trådløs basestasjon hjemme så nevnes det litt om PSK i dette dokumentet som en sikkerhetsbetrakning. Selv om WPA med PSK er en signifikant forbedring fra WEP så er det viktig at man velger sitt passord/passfrase med omtanke slik at det ikke blir lett å gjette eller for kort. Det er ikke veldig brukervennlig å la brukeren fylle ut alle 64 heksadesimale tegnene selv. Derfor har produsentene implementert en algoritme som ekspanderer et passord/passfrase til 64 heksadesimale tegn. Dersom dette passordet/passfrasen blir under 20 tegn så har man i realiteten ikke oppnådd stort bedre sikkerhet enn om man brukte WEP. Det finnes tilgjengelig på nett programvare som kan knekke slike korte passord/passfraser fra WPA-PSK. Merk at i beskrivelsene i avsnittene under så vil det fokuseres på anbefalte eller mye brukte løsninger for å få optimal sikkerhet. Med som så mye annet så er det dessverre mulig å konfigurere også WPA/WPA2 på måter som gjør det langt mindre sikkert. 3.2 Elementene i 802.1X Kjernen i IEEE 802.11i er IEEE 802.1X. IEEE 802.1X gjør bruk av tre parter i en autentiseringsprosess: Supplicant (klienten), Authenticator (AP) og Authentication Server (RADIUS). Kommunikasjonen mellom disse går via en protokoll ved navn EAP (Extensible Authentication Protocol). Mellom Supplicant og Authenticator går EAP direkte på lag 2 (EAPOL - EAP over LAN) mens det mellom Authenticator og Authentication Server går over TCP/IP som en del av RADIUS-protokollen. 7
Klient Basestasjon RADIUS-tjener Supplicant Authenticator Authentication server EAPOL EAP i RADIUS Internett Autentiseringsprosessen initieres av enten Supplicant eller Authenticator i det klienten prøver å assosiere seg mot basestasjonen. Det er flere måter å gjøre det på, men ved gjensidig autentisering så vil Authentication Server først sende sitt sertifikat til Supplicant via Authenticator. Dersom Supplicant godtar denne, så vil den så følge opp med å oppgi sitt brukernavn/passord eller sertifikat, avhengig av hvilken metode som brukes. Dersom Authentication Server godtar dette svaret så vil den sende beskjed til Authenticator om dette som så vil åpne en trådløs "port" for Supplicant. Denne virtuelle porten er en sikret, trådløs tilknytning mellom Supplicant og Authenticator slik at klienten får fri tilgang til nettverket bak basestasjonen. Klient Basestasjon RADIUS-tjener Supplicant Authenticator Authentication server EAPOL EAP i RADIUS EAPOL - Start Forespørsel om identitet Respons med identitet Respons med identitet Forespørsel med utfordring Forespørsel med utfordring Svar på utfordring Svar på utfordring Godkjent eller Avvist Godkjent eller Avvist EAPOL - Avslutt 8
Figuren viser gangen i EAP-prosessen. Den initielle prosessen hvor RADIUS serveren først sender sin offentlige nøkkel er ikke tatt med i denne figuren men vil foregå før klienten blir spurt som sin identitet. EAP er konstruert for at man skal kunne benytte seg av en valgfri autentiseringsmekanisme. TLS TTLS PEAP OTP Autentiseringslag Extensible Authentication Protocol (EAP) EAP Over LANs (EAPOL) EAP lag PPP 802.3 802.5 802.11 MAC lag Det finnes mange muligheter men det er få av dem som gir den gjensidige autentiseringen vi trenger på trådløse nettverk. Disse er TLS (Transport Layered Security), TTLS (Tunneled TLS) og PEAP (Protected EAP). Felles for alle er at Authentication Server må ha et serversertifikat. TLS benytter seg av klientsertifikat for alle brukere også mens for TTLS og PEAP, som er veldig like, benytter seg av brukernavn og passord. TTLS og PEAP bør da bruke MS-CHAPv2 for å pakke inn dette før det sendes til Authentication Server. Det er ingenting i veien for å tilby flere autentiseringsmekanismer samtidig. De fleste som kjører 802.1X for trådløse nettverk gir gjerne klienten valget mellom TLS, PEAP og TTLS. 3.3 Sertifikater og brukerautentisering Siden vi med disse metodene involverer sertifikater, må man ha etablert et minimum av PKIløsning. Det vil si at man må enten benytte seg av en eksisterende CA (Certificate Authority) eller man må etablere sin egen. På en SAMSON3 (eller en annen Linux-maskin) så er dette rimelig trivielt (se eget avsnitt), det samme gjelder Microsoft IAS. Dersom man etablerer sin egen CA så koster ikke det noe og man kan generere så mange server- og brukersertifikater som man ønsker. Ulempen er at din egen CA i utgangspunktet vil være ukjent for alle dine brukere slik at de ikke vil være i stand til å sjekke ektheten til sertifikatet som kommer fra Authentication Server. For å gjøre det må alle klientene installere det offentlige sertifikatet til den lokale CA. Den kan trygt spres åpent gjennom f.eks. mail og web-sider men det er en ekstra operasjon i konfigurasjonen en bruker må få til rett. Alternativet er at man kjøper et serversertifikat fra en organisasjon som har fått preinstallert det offentlige sertifikatet til sin CA i operativsystemet til klienten. Her er det mange å velge mellom og mange ulike prismodeller. Hvorvidt det lønner seg økonomisk vil være en avveining mellom kostnad på brukersupport og kostnad på serversertifikatet. Det må også nevnes at det KAN være en sikkerhetsrisiko involvert ved å bruke sertifikater fra en større CA. De færreste klienter vil nemlig sjekke om sertifikatet tilhører en server 9
med rett navn men nøyer seg med å finne ut om sertifikatet er gyldig. Dermed kan man teoretisk få servert et gyldig sertifikat men fra en server som er satt opp for phishing. Risikoen for at dette skal skje blir foreløpig sett på som ganske liten. Når det gjelder identifikasjon av brukeren/klienten så kan man der også benytte seg av sertifikater. Hver bruker får sitt personlige sertifikat og maskiner kan få et maskinsertifikat. I dette scenariet vil brukere slippe å ha brukernavn og passord men til gjengjeld må organisasjonen ha et godt opplegg for PKI med sertifikathåndtering, noe som kan koste mye i form av både penger og administrative ressurser. Alternativet er brukernavn og passord. Denne metoden blir sett på som like sikker som sertifikater og har den ekstra fordelen at man kan knytte opp autentiseringen mot en eksisterende brukerdatabase. Det er imidlertid en forutsetning at brukerdatabasen kan sjekke med MD4-hashet passord da dette er formatet til passord over MS-CHAPv2. 3.4 Kryptering Man må merke seg at med 802.1X autentisering så er det kun autentiseringsprosessen som er kryptert. Etter at prosessen er ferdig så vil datakommunikasjonen kunne gå ukryptert. Ved at man bruker 802.1X så får man samtidig en mulighet for basestasjonene å på en sikker måte distribuere en unik per-bruker nøkkel som kan brukes til kryptering. Dette utnyttes i WPA ved å bruke TKIP kryptering og WPA2 med AES kryptering. Da får man en god og unik per-pakke kryptering av all datatrafikk. Det er mulig å konfigurere et 802.1X sikret trådløsnett til å ikke benytte seg av kryptering eller å bruke rullerende WEP-nøkler. Det er langt sikrere enn vanlig WEP dersom man har en hyppig rotasjon, men det er allikevel ikke anbefalt. TKIP er en RC4 kryptering som WEP men har noen kraftige forbedringer som gjør at den ikke har de samme svakhetene. Eldre trådløskort som støttet 128-bits WEP vil kunne firmware oppgraderes til å kjøre TKIP men dessverre er det flere produsenter som ikke har prioritert dette i eldre modeller. TKIP er ikke 100 % sikker og har noen svakheter men blir allikevel generelt sett på som meget sikkert så langt. AES er svært lik Rijndael, som er "originalen". AES har noen begrensninger på bl.a. nøkkelstørrelse. Den er brukt av statlige organisasjoner i USA og brukes for kryptering av materiale i graden SECRET, dvs. til TOP SECRET. Med andre ord så blir den ansett som svært sikker. 10
4. Sertifikatgenerering på SAMSON3 (Linux) Generering av sertifikater og bruk av sertifikater kan, som så mye annet, virke forvirrende, komplisert og arbeidskrevende før man har kommet inn i det. Denne forklaringen tar det hele med teskje for at man skal kunne forstå gangen i det. Til slutt er det listet opp tre script som automatiserer mye av disse manuelle operasjonene. 4.1 Lage CA root-sertifikat og etablere sertifikathierarki Når man skal etablere en egen sertifikatstruktur, må man først og fremst ha på plass et rootsertifkat som senere skal brukes til å generere og kontrollere alle andre sertifikater med. openssl req -new -x509 \ -keyout root-req.pem \ -out root-req.pem \ -days 1825 \ -passout pass:capassord Dette genererer et nytt X509 sertifikat og privat nøkkel til samme fil i PEM-format (Privacy Enhanced Mail). Dette eksempelet gir en CA med varighet i 1825 dager som er 5 år. Det er ingenting i veien for å lage noe med lengre eller kortere varighet, men siden alle andre sertifikater er avhengig av dette så bør dette settes til en fornuftig lang varighet så ikke alle sertifikater må byttes i utide. Ofte setter man så lang som 10 års varighet. Du vil få spørsmål om å legge inn noen data: Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []: Email Address []: Legg inn informasjonen slik det virker fornuftig. Vær påpasselig med å gi Common Name (CN) et fornuftig navn som for eksempel UNINETT WLAN CA siden dette er navnet alle brukere vil se i listen sin når de skal bruke sertifikatet. I stedet for å fylle ut all denne informasjonen manuelt i det man genererer sertifikat, kan man i stedet redigere i konfigurasjonsfila til OpenSSL /etc/ssl/openssl.cnf Et stykke ned i filen finner man innslag som countryname_default, organizationalunitname_default, osv. Her legges standardverdiene som man vil skal dukke opp. Man kan også legge til slike _default for de innslagene som mangler det. Resultatet av denne operasjonen blir en fil root-req.pem. Så må man etablere et sertifikathierarki. Det gjøres ved å bruke scriptet CA.pl som følger med OpenSSL og parameteren -newca 11
/usr/lib/ssl/misc/ca.pl -newca På spørsmålet: CA certificate filename (or enter to create) Skriver du navnet på det sertifikatet vi nettopp har generert: root-req.pem Avhengig av hva som er konfigurert i openssl.cnf så blir det laget en katalog (democa) med underliggende katalogstruktur og filer som skal huse sertifikathierarkiet. Det offentlige sertifikatet til CA legges også der. I tillegg trenger vi en fil som holder rede på serienummeret til neste sertifikat som skal lages. Vi kan gjøre det enkelt å lage det på denne måten: echo "01" > democa/serial Kontroller at democa/cacert.pem inneholder det samme sertifikatet som det som ligger i rootreq.pem og at democa/private/cakey.pem inneholder den samme nøkkelen som root-req.pem. Etter det kan du slette root-req.pem. rm root-req.pem Til slutt må man lage et offentlig sertifikat i DER-format (Distinguished Encoding Rules) slik at brukerne kan importere det i sine klienter som root CA. openssl x509 -inform PEM \ -outform DER \ -in democa/cacert.pem \ -out CAroot.der Fila CAroot.der kan man gi et passende navn og distribuere fritt til alle egne brukere som kunne tenkes å bruke trådløsnettet. Den kan for eksempel sendes ut pr. mail, legges inn på en web-side eller liggende tilgjengelig i resepsjonen på en minnepinne. På Windows importeres den enkelt til rett sted ved å dobbeltklikke på den. 12
4.2 Lage serversertifikat Serversertifikatet er nødvendig uansett om man skal ha TLS, PEAP eller TTLS autentisering fordi det er den eneste måten RADIUS serveren kan identifisere seg på. Det første vi må gjøre er å rekvirere en fil i PEM-format. openssl req -new \ -keyout req-server.pem \ -out req-server.pem \ -days 1825 \ -passout pass:serverpassord Som da vi laget CA sertifikatet, får vi spørsmål om å fylle inn verdiene for organisasjon, lokasjon og navn. Fyll inn med det som er fornuftig. Det er fornuftig å la levetiden til serveren sitt sertifikat vare noen år men det er ikke problematisk å bytte ut sertifikatet etter behov og det får ingen konsekvenser for klientenes konfigurasjon. VIKTIG! Common Name (CN) må være det fulle DNS-navnet (hostname + domain name) til RADIUS serveren! For eksempel radius1.uninett.no. Det er fordi enkelte klienter vil sjekke om CN i RADIUS serveren sitt sertifikat stemmer med hva de forventer den skal hete. Klienten har naturligvis ikke anledning til å sjekke direkte i DNS under autentiseringsprosessen så dette er noe brukeren må legge inn selv. Å bruke navnet angitt i DNS vil være naturlig for mange. I tillegg får man disse spørsmålene: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Her er det bare å svare blankt. Kommandoen resulterer i filen req-server.pem. Denne må signeres av CA og dessuten få lagt til nødvendig policy slik at den kan brukes til vårt tiltenkte formål. De ulike formålene et sertifikat kan brukes til, angis ved hjelp av OID (Object ID). Vi må spesifisere at dette sertifikatet skal brukes av en server for autentisering. ODI for det er 1.3.6.1.5.5.7.3.1 For enkelhets skyld legger vi dette inn i en fil som vi kaller for EXTENSIONS. [ xpserver_ext ] extendedkeyusage = 1.3.6.1.5.5.7.3.1 13
Slik signeres sertifikatet: openssl ca -policy policy_anything \ -out server-cert.pem \ -extensions xpserver_ext \ -extfile EXTENSIONS \ -passin pass:serverpassord \ -key capassord \ -infiles req-server.pem Resultatet blir filen server-cert.pem som vi bruker videre til å først generere sertifikatet i P12 format: openssl pkcs12 -export \ -in server-cert.pem \ -inkey req-server.pem \ -out server.p12 \ -clcerts \ -passin pass:serverpassord \ -passout pass:serverpassord Deretter bruker vi filen som blir laget, server.p12, til å lage et endelig sertifikat i PEM-format: openssl pkcs12 -in server.p12 \ -out server.pem \ -passin pass:serverpassord \ -passout pass:serverpassord Filen server.pem er strengt tatt den eneste du trenger for RADIUS serveren, noe som betyr at du nå kan slette filene req-server.pem, server-cert.pem og server.p12 med mindre du har en RADIUS server som ønsker sitt sertifikat i P12-format. rm req-server.pem rm server-cert.pem rm server.p12 14
4.3 Lage klientsertifikat Dersom man skal kjøre en TLS løsning så må man også utstede klientsertifikater. Å lage ett klientsertifikat er bare marginalt forskjellig fra å lage et serversertifikat. Det første vi må gjøre er å rekvirere en fil i PEM-format. openssl req -new \ -keyout req-klient.pem \ -out req-klient.pem \ -days 1095 \ -passout pass:klientpassord Vi får spørsmål om å fylle inn verdiene for organisasjon, lokasjon og navn. Fyll inn med det som er fornuftig. Sertifikatets gyldighet kan det være fornuftig å sette til studiets/ansettelsesforholdes varighet, for eksempel 3 år. VIKTIG! Common Name (CN) anbefales å være brukerens brukernavn pluss hjemmeorganisasjon/domene, for eksempel bruker@uninett.no. Dette er for å kunne rute forespørselen riktig gjennom et radiushierarki (se avsnittet om eduroam). I tillegg får man disse spørsmålene: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Her er det bare å svare blankt. Kommandoen resulterer i filen req-klient.pem. Denne må signeres av CA og dessuten få lagt til nødvendig policy slik at den kan brukes til vårt tiltenkte formål. De ulike formålene et sertifikat kan brukes til, angis ved hjelp av OID (Object ID). Vi må spesifisere at dette sertifikatet skal brukes av en klient for autentisering. ODI for det er 1.3.6.1.5.5.7.3.2 For enkelhets skyld legger vi dette inn i en fil som vi kaller for EXTENSIONS. [ xpclient_ext ] extendedkeyusage = 1.3.6.1.5.5.7.3.2 15
Slik signeres sertifikatet: openssl ca -policy policy_anything \ -out klient-cert.pem \ -extensions xpserver_ext \ -extfile EXTENSIONS \ -passin pass:klientpassord \ -key capassord \ -infiles req-klient.pem Resultatet blir filen klient-cert.pem som vi bruker videre til å først generere sertifikatet i P12 format: openssl pkcs12 -export \ -in klient-cert.pem \ -inkey req-klient.pem \ -out klient.p12 \ -clcerts \ -passin pass:klientpassord \ -passout pass:klientpassord Filen klient.p12 er det formatet de fleste klienter kan benytte seg av. For en Windows klient er det bare å dobbeltklikke på fila for å importere den til rett sted. Det her oppgitte klientpassord er brukerens passord til den private nøkkelen og må brukes for å kunne importere fila til sin egen maskin. Du kan nå slette filene req-klient.pem og klient-cert.pem. rm req-klient.pem rm klient-cert.pem 16
4.4 Script for å generere sertifikat ca-cert.sh #!/bin/sh PATH=/etc/ssl/misc/:${PATH CA_PL=/usr/lib/ssl/misc/CA.pl if [ $#!= 1 ] then echo "Format: $0 capassord" exit 1 fi # Dersom CA hierarkiet er eksisterer foer, maa den tidligere strukturen # slettes. Ellers vil ikke det nye CA sertifikatet bli kopiert inn. rm root* rm -rf democa # Lage et nytt CA rootsertifikat openssl req -new -x509 -keyout root-req.pem -out root-req.pem -days 1825 \ -passout pass:$1 # Lage CA hierarki echo "root-req.pem" $CA_PL -newca >/dev/null # Lage serienummerfil echo "01" >> democa/serial # Lage CA sertifikatet i DER-format openssl x509 -inform PEM -outform DER -in democa/cacert.pem -out CAroot.der # Rydde opp rm root-req.pem EXTENSIONS [ xpclient_ext] extendedkeyusage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedkeyusage = 1.3.6.1.5.5.7.3.1 17
server-cert.sh #!/bin/bash if [ $#!= 3 ] then echo "Format: $0 filnavn capassord sertifikatpassord" exit 1 fi # Rekvirer et nytt sertifikat openssl req -new -keyout req-$1.pem -out req-$1.pem -days 1825 \ -passout pass:$3 # Signer sertifikat og legg innoedvendig OID openssl ca -policy policy_anything -out $1-cert.pem \ -extensions xpserver_ext -extfile EXTENSIONS \ -passin pass:$3 -key $2 -infiles req-$1.pem # Eksporter til P12 format openssl pkcs12 -export -in $1-cert.pem -inkey req-$1.pem -out $1.p12 \ -clcerts -passin pass:$3 -passout pass:$3 # Konverter til PEM format openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:$3 -passout pass:$3 # Rydd opp rm req-$1.pem rm $1-cert.pem 18
klient-cert.sh #!/bin/bash if [ $#!= 3 ] then echo "Format: $0 filnavn capassord sertifikatpassord" exit 1 fi # Rekvirer et nytt sertifikat openssl req -new -keyout req-$1.pem -out req-$1.pem -days 1095 \ -passout pass:$3 # Signer sertifikat og legg innoedvendig OID openssl ca -policy policy_anything -out $1-cert.pem \ -extensions xpclient_ext -extfile EXTENSIONS \ -passin pass:$3 -key $2 -infiles req-$1.pem # Eksporter til P12 format openssl pkcs12 -export -in $1-cert.pem -inkey req-$1.pem -out $1.p12 \ -clcerts -passin pass:$3 -passout pass:$3 # Rydd opp rm req-$1.pem rm $1-cert.pem 19
5. Kjøp av sertifikat fra UNINETT SCS Alternativet til å lage sertifikater selv er å kjøpe fra en etablert sertifikatutsteder. Fordelen med det er at CA allerede er installert hos klientene. Skal man kjøpe et sertifikat står man fritt til å kjøpe fra dem man ønsker. UNINETT har en Server Certificate Service (SCS) gjennom vårt medlemsskap i TERENA sitt SCS-prosjekt. Sertifikatene er utsted av GlobalSign, en CA som er lokalisert i Belgia og som er en del av Cybertrust-gruppen. På http://forskningsnett.uninett.no/scs/ vil man finne nødvendig informasjon om hvordan man går frem for å bestille. Prosessen er i korte trekk: 1. Din organisasjon må få etablert en Forhåndsgodkjenning 2. Genere nøkkelpar og Certificate Signing Request (CSR) 3. Sende inn CSR via SCS enrolment pages 4. Bekrefte bestilling 5. Motta sertifikatet 6. Installere sertifikatet Erfaring har vist at det kan være problematisk å generere CSR fra enkelte plattformer/applikasjoner. Vi anbefaler derfor OpenSSL som finnes både for Windows og Linux. 20