Introduksjon

TLS er en protokoll som benyttes for å etablere en sikker kommunikasjonskanal mellom 2 parter, dette sikrer konfidensialitet og integritet i kommunikasjonen. I etableringen av en TLS-forbindelse benyttes et TLS-sertifikat på serversiden for å autentisere serveren. Man kan også benytte et digitalt sertifikat for å autentisere klienten i TLS-forbindelse, men dette er ikke så vanlig og denne artikkelen dekker ikke klientsertifikater.

Bruk av TLS-sertifikater for å etablere en TLS-forbindelse mot en server som man kan nå via en nettleser og HTTPS er blitt en bransjestandard og TLS-sertifikatet som benyttes må være anerkjent og godkjent av nettleseren for at TLS-forbindelsen skal bli etablert. Buypass er en sertifikatutsteder (rot CA) og utsteder TLS-sertifikater som anerkjennes av nettlesere og av andre applikasjoner som benyttes på klientsiden. Vi snakker gjerne om et økosystem rundt bruken av TLS-sertifikater (her omtalt som WebPKI) der Buypass som sertifikatutsteder tar en viktig rolle. Men bruk av TLS-sertifikater på serversiden utgjør også en kritisk komponent for at dette økosystemet skal fungere optimalt.

Denne artikkelen beskriver en beste praksis for bruk av Buypass TLS-sertifikater på serversiden.

Generelt

SSL vs TLS

Man bruker ofte begrepene SSL (Secure Socket Layer) og TLS (Transport Layer Security) om hverandre. SSL-protokollen ble tatt i bruk allerede i 1995 (SSL 2.0), mens siste versjon (SSL 3.0) ble avviklet i 2015.

TLS-protokollen er etterfølgeren til SSL-protokollen og første versjon kom allerede i 1999, mens siste og gjeldende versjon (TLS 1.3) ble publisert i 2018.

SSL-protokollen er ikke i bruk lenger og vi benytter her betegnelsen TLS-sertifikater om digitale sertifikater som benyttes for autentisering i TLS-protokollen (som tradisjonelt har vært omtalt som SSL-sertifikater).

Nøkler og sertifikater

Bruk av TLS-sertifikater er basert på asymmetrisk kryptografi der man benytter et kryptografisk nøkkelpar som består av en privat nøkkel og en offentlig nøkkel. Serveren som skal autentiseres benytter den private nøkkelen, mens den offentlige nøkkelen benyttes i TLS-sertifikatet. Den kryptografiske nøkkelen må være en sterk nøkkel (minst 112 bits sikkerhet) - og må være minst 2048 bits RSA eller en nøkkel basert på elliptisk kurve kryptografi og NIST P-256 kurven. Både RSA og ECDSA (som benytter elliptisk kurve kryptografi) er standardiserte kryptografiske algoritmer som begge har stor utbredelse i dag. En ECDSA nøkkel på 256 bits har samme kryptografiske styrke som en RSA nøkkel på 3072 bits (128 bits sikkerhet), men er mye kortere og vil være mer effektiv i bruk enn en RSA nøkkel med tilsvarende styrke.

Kvantesikker kryptografi er også et tema for TLS, men det er for tidlig til at slike algoritmer er støttet i protokollene ennå.

I asymmetrisk kryptografi er den private nøkkelen koblet til en korresponderende offentlig nøkkel på en slik måte at kryptografiske operasjoner utført med den private nøkkelen kan verifiseres med den offentlige nøkkelen. Den offentlige nøkkelen blir derfor koblet til serverens identitet, som utgjør minst ett domenenavn i et TLS-sertifikat for bruk i TLS-protokollen. Serveren benytter den private nøkkelen i en kryptografisk operasjon for autentisering (genererer en digital signatur) og sender med det tilhørende TLS-sertifikatet til klienten (feks en nettleser) som verifiserer signaturen mot den offentlige nøkkelen i sertifikatet. På denne måten er klienten trygg på at nøkkelen kontrolleres av serveren og kjenner identiteten (dvs minst domenenavnet) til serveren via TLS-sertifikatet.

Det er viktig å beskytte den private nøkkelen på en slik måte at den ikke kommer på avveie. Dersom man har mistet kontroll på den private nøkkelen må det tilhørende sertifikatet revokeres og erstattes med en ny nøkkel og tilhørende TLS-sertifikat. En privat nøkkel på avveie er kompromittert siden andre kan benytte denne for å utgi seg for å være serveren (eller tjenesten) som autentiseres med et TLS-sertifikat.

Dette er også grunnen til at nøkkelen som skal benyttes alltid må genereres og sikres på den serveren der den skal brukes.

Når man skal bestille et TLS-sertifikat må man derfor generere det som kalles en Certificate Signing Request (CSR) som inneholder den offentlige nøkkelen samt eventuelt andre attributter og legge den ved bestillingen. CSR-en skal være signert med den korresponderende private nøkkelen. Dette fungerer som et “bevis” for at CSR-en faktisk kommer fra en aktør som kontrollerer den private nøkkelen. Buypass henter bare den offentlige nøkkelen samt eventuelle domenenavn (fra CN og SAN) fra CSR-en, alle andre attributter blir ignorert.

Om bruk av TLS-sertifikater

TLS-sertifikater benyttes for å autentisere serveren og inneholder som regel minst ett domenenavn (som identifiserer tjenesten) og eventuelt andre identitetsdata som sier noe om organisasjonen som kontrollerer serveren/tjenesten.

TLS-sertifikatet sendes (gjerne sammen med intermediate-sertifikatet) tilbake til klienten sammen med datalementer som er signert med den private nøkkelen. Den offentlige nøkkelen i sertifikatet benyttes for å verifisere signaturen. Når verifiseringen er gjort, kan klienten være sikker på at serveren som har signert har kontroll på den korresponderende private nøkkelen og kan benytte TLS-sertifikatet for å identifisere serveren/tjenesten.

Dersom klienten er en nettleser, må TLS-sertifikatet være utstedt av en sertifikatutsteder (Certification Authority - CA) som klienten anerkjenner og stoler på. Nettleser og sertifikatutsteder tar begge en viktig rolle i WebPKI og nettleserne stiller en rekke krav som sertifikatutstederne må tilfredsstille, inkludert krav fra standarder utarbeidet av CA/Browser Forum.

Velg en sertifikatutsteder du har tillit til

Velg en sertifikatutsteder som du kjenner og har tillit til. Buypass er en av relativt få sertifikatutstedere globalt som er anerkjent av de mest brukte nettleserne.

Buypass er også et aktivt medlem i CA/Browser forum som er ansvarlig for de standardene som benyttes for utstedelse og administrasjon av TLS-sertifikater. Buypass er også en kvalifisert tilbyder av tillitstjenester under eIDAS og tilbyr kvalifiserte sertifikater for nettstedsautentisering (QWACs).

Benytt DNS CAA

DNS CAA er en mekanisme du som eier og administrerer domener kan benytte for å begrense hvilke CA-er som skal kunne utstede TLS-sertifikater på ditt domene. Dersom du ønsker å gi Buypass tilgang til å utstede sertifikater på domenet, kan du legge inn ‘buypass.no’ eller ‘buypass.com’. Se https://datatracker.ietf.org/doc/html/rfc8659 for mer informasjon.

Alle sertifikatutstedere er pålagt å sjekke DNS CAA før utstedelse og dersom konfigurasjonen tilsier at sertifikatutsteder ikke er autorisert til å utstede, så kan ikke sertifikatet utstedes. Dette er en god måte å få kontroll på hvilke sertifikatutstedere som kan benyttes, det er mulig å autorisere flere CA-er for ett domene. Dette kan også være en årsak til at Buypass ikke kan utstede sertifikat på et domene som inngår i et sertifikat som er bestilt. Dersom du er i tvil, sjekk oppsettet i din DNS konfigurasjon og gi Buypass autorisasjon til å utstede.

Det er viktig at domeneeierne har kontroll på DNS-konfigurasjonen og benytt gjerne DNSSEC (DNS Security Extentions). Dette vil gi en ekstra sikkerhet mot potensielt misbruk av Man-in-the-Middle aktører.

Vær forsiktig med bruk av wildcard sertifikater

Wildcard sertifikater brukes gjerne på tvers av ulike tjenester som matcher domenenavnet i sertifikatet (*.qa.buypass.com) - og i noen sammenhenger også på tvers av ulike systemer. Dette øker sannsynligheten for at nøkkelen kommer på avveie, noe som gjør at wildcard-sertifikatet må revokeres.

Wildcard sertifikater kan være praktisk å bruke i mange sammenhenger, men det er også her viktig å ha god kontroll på den private nøkkelen som benyttes sammen med et slik sertifikat. Dersom den private nøkkelen kommer på avveie, eller et wildcard sertifikat må revokeres av ulike årsaker, kan dette ha konsekvenser for alle tjenester der sertifikatet brukes.

Ikke benytt ett wildcard-sertifikat for tjenester på ulike tilits- eller sikkerhetsnivåer.

Certificate Transparency (CT)

De største nettleserne krever i dag at TLS-sertifikater skal være logget i det vi kan omtale som et nytt økosystem - Certificate Transparency (CT). Dette betyr at alle TLS-sertifikater blir registrert og publisert i CT-logger som er åpent tilgjengelig for allle. Dette sikrer åpenhet og skal redusere sannsynligheten for at sertifikater blir utstedt på feil grunnlag.

I dette økosystemet finnes det ulike aktører som tilbyr verktøy for overvåking og rapportering - se https://certificate.transparency.dev/ for mer informasjon.

Revokering av TLS-sertifikater

Som nevnt innledningsvis er det viktig å ha kontroll på den private nøkkelen som benyttes på serveren. Dersom en slik nøkkel kommer på avveie og blir kompromittert, bør det korresponderende TLS-sertifikatet revokeres (sperres) umiddelbart. Dersom sertifikatet sperres med årsak (reasonCode) keyCompromise, så vil det ikke være mulig å bestille nye TLS-sertifikater på samme nøkkel. Dette kan være viktig for å unngå misbruk av en kompromittert nøkkel.

Standardene fra CA/Browser Forum definerer en rekke situasjoner som krever at sertifikatet revokeres. I tillegg til kompromitterte nøkler gjelder dette feks sertifikater som ikke lenger er i bruk, eller inneholder domenenavn som ikke lenger brukes. Vi er også pålagt å angi en årsakskode når et TLS-sertifikat skal revokeres. Les mer om revokering og aktuelle årsakskoder her: https://buypassdev.atlassian.net/wiki/spaces/SSL/pages/2818408449.

Det kan også oppstå hendelser som gjør at sertifikatutsteder må revokere TLS-sertifikater på eget grunnlag, da det kan være sikkerhetshendelser eller andre hendelser som gjør at sertifikatet må revokeres. I slike tilfeller må TLS-sertifikatet revokeres innen 24 timer eller 5 dager etter at hendelsen oppstod. Fristen er avhengig av alvorlighetsgrad på hendelsen.

Vær oppmerksom på at dette er noe vi er pålagt å gjøre i vår rolle som sertifikatutsteder og at en revokering av sertifikatet kan ta ned tjenesten som benytter TLS-sertifikatet. Dersom Buypass som serifikatutsteder må revokere sertifikatet, er det viktig at sertifikatet som revokeres blir erstattet så raskt som mulig - fortrinnsvis før revokering skjer. I en slik situasjon er det avgjørende at sertifikatutsteder har god og oppdatert kontaktinformasjon slik at varsling om revokering kan gjøres så effektiv som mulig. Det beste er selvfølgelig at erstatning av sertifikat skjer automatisk i slike tilfeller - les mer om dette under Automatisering nedenfor.

Konfigurasjon og oppsett av server for TLS

TLS-protokollen skal sikre konfidensialitet og integritet i en kommunikasjon mellom to parter, men dette forutsetter at serveren er korrekt konfigurert. Sikkerheten på kommunikasjonen er helt uavhengig av TLS-sertifikatet som bare brukes for autentisering av server under etablering av en TLS-kommunikasjon.

Det er kun de to siste versjonene av TLS-protokollen (TLS 1.2 og TLS 1.3) som anses for å være uten kjente sikkerhetssvakheter og man bør ikke benytte andre protokoller enn disse i dag.

Velg en sikker “cipher suite”, da dette definerer sikkerheten i den endelige kommunikasjonkanalen. Cipher suites basert på AEAD (Authenticated Encryption with Associated Data) og PFS (Perfect Forward Secrecy) anbefales.

Benytt OCSP Stapling

En sertifikatutsteder må si noe om revokeringsstatus på et TLS-sertifikatet og dette kan gjøres via CRL eller OCSP (Buypass tilbyr begge mekanismer). Nettlesere og andre klienter sjekker gjerne revokeringsstatus direkte mot sertifikatutsteder ved å hente CRL eller sjekke status for det aktuelle TLS-sertifikatet ved direkte kontakt med sertifikatutsteder (ved bruk av OCSP). Det er imidlertid flere og flere nettlesere som ikke sjekker revokeringsstatus og det kan dermed ta litt tid fra et sertifikat blir revokert til revokeringsstatus er tilgjengelig.

Man bør vurderer å sette opp bruk av såkalt OCSP Stapling på serveren dersom dette støttes av serveren. Da er det serveren selv som sjekker status for det aktuelle TLS-sertifikatet og returnerer OCSP-responsen sammen med sertifikatet i TLS-protokollen.

Dette er også et viktig tiltak for å ivareta personvernet siden en sertifikatutsteder ellers vil kunne sitte med informasjon om hvilke nettsider (via OCSP-oppslag på et TLS-sertifikat og tilhørende domener) en nettleser er innom.

Verifiser oppsettet

Det finnes verktøy som kan brukes for å verifisere at serveren er konfigurert korrekt for bruk i en TLS-protokoll, se .

Automatisering

For å sikre at man har et velfungerende og sikkert økosystem (WebPKI) er det viktig å sikre at det er mulig å erstatte/fornye TLS-sertifikater på en effektiv og rask måte. Det er viktig å fornye sertifikater før disse utløper - et utløpt sertifikat kan føre til at tilgangen til tjenesten blir blokkert siden nettleserne ikke aksepterer utløpte sertifikater. Det går også i retning av kortere og kortere levetid på TLS-sertifikatene og maksimal levetid på slike sertifikater er i dag 398 dager. Vi forventer at levetiden blir redusert ytterligere de neste årene.

Det samme vil skje dersom et TLS-sertifikat blir revokert - da må dette erstattes med et nytt (erstatnings)sertifikat så raskt som mulig, fortrinnsvis før det eksisterende sertifikatet blir revokert.

Alt dette tilsier at prosessene med erstatning/fornyelse av sertifikater bør automatiseres, fortrinnsvis slik at bestilling av sertifikat blir gjort i god tid og nytt sertifikat er installert før eksisterende sertifikat utløper eller revokeres.

Automatisering krever systemstøtte i viktige funksjoner som overvåking av sertifikatets tilstand (gjenværende levetid og revokeringstatus), bestilling av nytt sertifikat når behovet dukker opp samt nøkkelgenerering og installasjon av sertifikat.

ACME

Det finnes etter hvert mange måter å automatisere adminstrasjon av TLS-sertifikater, men ACME (Automated Certificate Management Environment) seiler opp som en klar favoritt hos mange.

ACME tilbyr automatisert støtte for funksjonene nevnt over og er tilgjengelig for mange ulike miljøer og plattformer- se for mer informasjon.

Buypass tilbyr administrasjon av TLS-sertifikater via ACME og jobber aktivt for å utvide tilbudet på dette området.

Innhold: