Forvaltning av digitale identiteter
Hvor mange ganger har du møtt meldinger om at et websted har et ugyldig sertifikat? Enten fordi sertifikatet har utløpt på dato eller fordi navnet du bruker i adressefeltet ikke stemmer med et gyldig navn i sertifikatet. I denne posten skriver vi litt om dette. Det er egentlig en svært triviell problemstilling, men likevel noe som stadig glipper.
Hva er et sertifikat – egentlig?
Først en liten oppklaring omkring hva et sertifikat er og hvordan det brukes. Er du kyndig på området, hopp over dette.
Sertifikatet er en liten fil som blant annet inneholder informasjon som:
- Navn. For et serversertifikat er dette typisk maskin- eller tjenestenavn. For et epost-sertifikat er det mailadresse. Et sertifikat kan inneholde flere navn og også «wildcards» av typen *.domene.com.
- Gyldighetsperiode. Dato/tid fra og til når sertifikatet er gyldig.
- Offentlig nøkkel. Nøkkelen som benyttes for å etablere kryptering mot serveren, eventuelt for å validere en elektronisk signatur av f.eks. en epost-melding.
I tillegg til sertifikatet har eieren en privat-nøkkel. Dette er motparten til den offentlige nøkkelen og kan benyttes til å dekryptere informasjon som er kryptert med den offentlige.
Tekst som er kryptert med den private nøkkelen kan åpnes med den offentlige. Det kan virke underlig at dekryptering med den offentlige nøkkelen har noen verdi siden den er tilgjengelig for alle. Men dette benyttes ved signering – ved å benytte den private nøkkelen kan man bevise at man er eier av sertifikatet, og da har man en digital signatur.
Sertifikatutstedere – CA (Certificate Authority)
I prinsippet alle sertifikat er signert med et CA signeringssertifikat. Dette er igjen signert av et annet CA sertifikat. Slik nøstes det oppover inntil en kommer til rot-sertifikatet som identifiseres ved at det er signert av seg selv (Self-signed). Det er disse rot-sertifikatene som er lagt inn i alle PCer, mobiler og applikasjoner som «trusted». Sertifkatkjeden en mottar fra en server ved oppkobling leder til slutt frem til en rot som vi har valgt å stole på (Eller, dette valget er gjort for oss av Microsoft, Mozilla, Google, Apple osv.)
Bruk av sertifikater på et websted
Når vi har vært ute og handlet et sertifikat og installert dette på serveren og vi ser at brukerne får koblet til fint mot https://serveren.domene.com/. Da er vi vel ferdige med den saken?
Ikke helt. Det er her det ofte feiler. For vi glemmer at sertifikatet en dag ikke lenger er gyldig (eller er sikker på at vi huser det). Og kanskje at hun som kjøpte sertifikatet brukte sin egen epost-adresse i bestillingen. Når det nærmer seg utløp har hun kanskje sluttet og vi får ikke den hyggelige eposten fra CA’en med påminnelse om at sertifikatet bør fornyes. Snipp, snapp snute, så er levetiden ute.
Eller om vi bruker wildcard-sertifikat av typen *.domene.com som er gyldig for alle tenkelige navn under domene.com. Da har vi ikke lenger sporbarhet på hvor vi bruker sertifikatet. Med faste navn kan det ikke være andre steder enn på serveren som svarer til navnet, men et wildcard-sertifikat har en tendens til å bli spredt rundt på mange servere, og de færreste miljøer undertegnede har besøkt fører noen slags oversikt over hvor dette er.
Enkle prinsipper
Det finnes noen enkle prinsipper som kan sikre oss at vi ikke ender opp med at en krakilsk markedssjef eller direktør komme løpende og sier at websidene ikke funker som de skal.
- Bruk kontaktinformasjon som ikke er knyttet til person
Uansett om du kjøper et enkelt-sertifikat eller henter dem fra en leverandør der du kan logge inn, pass på at epost-adressen(e) som benyttes ikke forsvinner. Da går du ikke glipp av varslene om sertifikat som utgår. - Ikke spre wildcard-sertifikat ukontrollert utover
Her bør en være helt firkantet. Enten bør en ha wildcard-sertifikat installert kun på proxy-servere (f.eks Netscaler) der alle tjenester benytter samme sertifikat slik at de oppdateres samtidig når sertifikatet fornyes, eller føre en god oversikt som viser hvor en har distribuert sertifikatet. Dersom man har behov for et wildcard til f.eks. testsystemer der en sprer det utover, bruk et eget sertifikat til det formålet og la kritiske systemer kjøre på et godt forvaltet wildcard-sertifikat. Eller bedre, på et sertifikat med faste navn.
Siden et sertifikat bare har en privatnøkkel, må denne installeres alle steder wildcard-sertifikatet benyttes. Et wildcard-sertifikat som kompromitteres på en server eller tjeneste vi ikke synes er så viktig, vil kunne utgjøre en trussel mot andre, mer kritiske systemer fordi det er samme privatnøkkel. - Digital identitet bør være et lederansvar
Siden sikkerhet og konfidensialitet får stadig større betydning i alt vi gjør, bør ansvaret for dette området legges på ledelsen. Bruk gjerne ansatte eller konsulenter til å utføre oppgavene, men ansvaret for all digital identitet bør være tillagt en leder-rolle og et system for å forvalte dette bør være på plass.
Om du ønsker en gjennomgang av dine sertifikater, eller hjelp til å etablere en ryddig rutine rundt disse er du selvsagt velkommen til å kontakte oss