Kokebok for bestilling og utstedelse av SSL-sertifikater

UiO er godkjent til å utstede sertifikater under domenenavnet uio.no, samt en håndfull andre domener.

Sertifikatets levetid

Gyldig levetid for et sertifikat er ett år (eller kortere). Det har tidligere vært mulig å bestille lengre gyldighet, men denne muligheten ble faset ut av en samlet bransje i 2020, og er i dag nedfelt i baseline requirements for sertifikat, som alle CAer og nettlesere plikter å følge. Dette er med andre ord ufravikelig, og selv om det hadde vært mulig å utstede et sertifikat med lengre levetid, ville ikke dette blitt akseptert av klienter.

Sjekke gyldighetsdatoer for et SSL-sertifikat

maskin.uio.no# openssl x509 -noout -dates -in foo.uio.no.crt
notBefore=Feb 16 12:00:51 2017 GMT
notAfter=Feb 18 16:23:16 2018 GMT

Hvilke domener kan man få utstedt sertifikat for?

UiOs sertifikatavtale kan (og skal) benyttes for alle domener UiO står som eier av. Dette inkluderer naturligvis uio.no, men også en rekke andre domener, som benyttes til forskjellige formål. Der det er mulig anbefales det som regel å benytte uio.no, da dette gir mindre merarbeid.

Domener det skal utstedes sertifikat for må først få validert eierskap. Ta kontakt med www-drift for å koordinere denne prosessen. Validering må gjentas årlig, og er gyldig for hele domenet, dvs. en validering for foo.no vil gjelde for både foo.no, www.foo.no, bar.foo.no osv.

Dersom domenet ikke er eid av UiO, ta først kontakt med hostmaster for å få overdratt eierskap før validering igangsettes.

Kan man få utstedt et sertifikat mot en IP-adresse?

Svaret på dette er i utgangspunktet nei, og selv om det kan være teknisk mulig, er dette ikke ønskelig. Løsningen er å gi IP-adressen et FQDN, og så få utstedt et sertifikat mot FQDN. Klienter som skal kontakte server hvor sertifikat benyttes må gjøre dette som hostnavn istedenfor IP-adresse. Da vil sertifikatet validere, og man har omgått problemstillingen.

Ja: https://foo.uio.no/
Nei: https://129.240.123.123/

Kom i gang

Du trenger:

Minimum OpenSSL 1.0.x eller høyere (RHEL 7), men 1.1.x eller høyere (>=RHEL 8) er anbefalt

Alle forekomster av 'foo.uio.no' (alltid uthevet) i teksten skal byttes ut med navnet/URL-en som sertifikatet skal bindes til. Dvs. fullt domenenavn (FQDN), f.eks. admin.uio.no eller universitas.uio.no

VIKTIG: Hvis du klipper ut innholdet fra CSR-filen i Windows etter å la laget den på en *nix maskin, så må du bruke Wordpad og for all del ikke Notepad.

Prosessen har tre steg:

A. Generere nøkkel og SCR

B. Kopiere inn CSR og sende bestillingsskjema

C. Legge opp sertifikat på server (framgangsmåte avhengig av løsning)

A: Generer nøkkel og CSR

1. Start med å lage en foo.uio.no.cnf fil. Typisk vil den inneholde:

[ req ]
default_bits = 2048
prompt = no
encrypt_key = no
default_md = sha256
distinguished_name = dn
utf8 = yes

[ dn ]
C = NO
O = Universitetet i Oslo
CN = foo.uio.no

2. Her må du bytte ut CN. Dette står for domenenavn ("Common Name"), som blir 'foo.uio.no' i vårt tilfelle.

2.1 Sertifikat for flere DNS-navn: Hvis du skal bestille sertifikat for flere DNS-navn (aliaser) blir .cnf-filen litt annerledes:

[ req ]
default_bits = 2048
prompt = no
encrypt_key = no
default_md = sha256
distinguished_name = dn
utf8 = yes
req_extensions = v3_req

[ v3_req ]
subjectAltName = @alt_names

[ dn ]
C = NO
O = Universitetet i Oslo
CN = foo.uio.no

[alt_names]
DNS.0 = foo.uio.no
DNS.1 = www.foo.uio.no

Bytt ut CN, som skal være lik DNS.0. I tillegg er DNS.1 da et alias. Om man har behov for flere alias legger man til DNS.2, DNS.3 osv.

3. Lag en ECDSA-nøkkel og en CSR (Certificate Signing Request) ved hjelp av OpenSSL. Lagre dem et sted du finner det igjen. Du trenger ikke lage nøkkel og CSR på samme maskin som sertifikatet skal bindes til.

maskin.uio.no# openssl ecparam -genkey -name prime256v1 > foo.uio.no.key ; openssl req -new -key foo.uio.no.key -out foo.uio.no.csr -config foo.uio.no.cnf

4. Beskytt den private nøkkelen. Velg en sikker passordfrase, og husk den. Den kan endres i ettertid hvis du husker den gamle. Ta en backup av filen foo.uio.no.key.

maskin.uio.no# openssl ec -in foo.uio.no.key -aes256 -out foo.uio.no-enc.key
read EC key
writing EC key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Den krypterte nøkkelen vil lagres i foo.uio.no-enc.key, og den ukrypterte nøkkelen i (foo.uio.no.key)

Hvis du ønsker det, kan du se nøkkelparet i klartekst med:

maskin.uio.no# openssl ec -noout -text -in foo.uio.no.key
...[en halv bøtte output]

Samme kommando kan også kjøres mot foo.uio.no-enc.key, men du vil da måtte taste inn passfrase for å aksessere nøkkelen. På denne måten kan du også verifisere at nøkkelen i foo.uio.no-enc.key er beskyttet.

Du har muligheten til å lagre den private nøkkelen i klartekst, men dette frarådes.

??Før du gjør noe som helst bør du forsikre deg om at du har en backup av den private nøkkelen.

B: Kopier inn CSR og send bestillingsskjema

1. Åpne bestillingsskjemaet.

2. Kopier innhold i CSR, og lim inn i bestillingsskjemaet.

3. Fyll ut de andre opplysningene i skjemaet.

4. Du får sertifikatet tilsendt på e-post. Lagre det som som foo.uio.no.crt.

NB: Når du bestiller via Nettskjema er prosessen (utenom godkjenning) automatisert, som vil dekke de fleste vanlige behov. Vi bestiller per i dag kun multidomain/SAN, ikke stjerne/wildcard-sertifikater. Hvis du av spesielle grunner skulle trenge noe annet enn dette må du kontakte www-drift@usit.uio.no.

Når får jeg sertifikatet mitt

Alle sertifikater må godkjennes manuelt før de kan utstedes, og det er kun et fåtall ansatte som har rettigheter til å gjøre dette. Dette skjer fortløpende, men noe ventetid kan måtte påregnes ifbm. ferie osv. Dersom noe haster er det lov å ~~mase~~spørre pent om sertifikatkøen kan behandles, f.eks. på chat (www-drift-kanalen i UiO-IT-teamet på Mattermost) eller i en ticket til www-drift.

CSR, hva skal jeg kopiere?

Innholdet i din CSR skal se ut omtrent som dette:

Når du skal fylle ut bestillingsskjemaet må du kopiere og lime inn alt fra og med ----BEGIN... til og med. END CERTIFICATE REQUEST-----

Istedenfor sertifikatet mitt mottok jeg en mail med noe HTML. Hva skjer?

Løsningene til UiOs sertifikatleverandør er i blant nede for vedlikehold, planlagt eller uplanlagt. Når dette skjer, vil spørringene vi gjør mot deres API ikke feile, men det vår kode får tilbake er en feilside istedenfor sertifikatet. Dette er vrient å feilhåndtere, ettersom APIet ikke ellers sier fra om at svaret inneholder noe annet enn det etterspurte sertifikatet.

Hvis du opplever dette, er gjerne det enkleste å bare prøve igjen, da vedlikehold som regel ikke pågår lenge. Hvis problemet vedvarer, kan du ta kontakt med www-drift.

C: Legg opp sertifikat på server

Du har fått sertifikatet tilsendt på e-post, og nå skal det opp på serveren. Framgangsmåte er avhengig av løsning:

Sertifikat på Apache (og andre løsninger hvor man angir sertifikat, intermediate og nøkkel separat)

Du trenger:

??den private (eller kryptert?) nøkkelen (som bør være beskyttet med passordfrase): foo.uio.no.key
signert sertifikat: foo.uio.no.crt
CA intermediate-sertifikat, dette vil som regel hete intermediate.crt
Hvis du har filen TrustedRoot.crt, eller andre filer med "root" i navnet, skal denne ikke benyttes til noe

Vi anbefaler å kjøre Apache fra RedHat, og aller helst på RHEL 8 eller senere. Sertifikatfilene kan da egentlig ligge hvor som helst, men det er gjerne ryddig å legge de under:

/etc/httpd/certificates/

1. Sørg for å sikre filene, i hvert fall nøkkelen:

maskin.uio.no# chmod 400 /etc/httpd/certificates/*.key
maskin.uio.no# chmod 440 /etc/httpd/certificates/*.crt

2. Filene bør eies av root (Apache vil lese dem før den dropper root-rettigheter):

maskin.uio.no# chown root:root /etc/httpd/certificates/*

3. For å ta i bruk sertifikatet, må følgende legges inn i VirtualHost-konfigurasjonen:

SSLEngine On
SSLCertificateFile /etc/httpd/certificates/foo.uio.crt
SSLCertificateKeyFile /etc/httpd/certificates/foo.uio.key
SSLCertificateChainFile /etc/httpd/certificates/intermediate.crt

Hvis du skal tilby flere domenenavn fra samme Apache-instans, og dermed ha flere VirtualHost-blokker med forskjellige sertifikater, er klienten nødt til å støtte Server Name Indication. Dette vil være tilfelle for alle klienter av nyere dato, men f.eks. RHEL 5 og Android <4 mangler SNI-støtte.

4. Videre må du sørge for sikker konfigurasjon av krypto. Du bør bruke Mozillas anbefalte konfig for dette. Intermediate-nivået er anbefalt for å sikre bakoverkompatibilitet med eldre klienter, men Modern er foretrukket for høyest sikkerhet. Fra eksempelet, bør sistnevnte konfigurasjonssnutt (utenfor VirtualHost) legges inn i /etc/httpd/conf.d/ssl.conf, og man bør bekrefte at SSLCipherSuite-innstillingen erstatter tidligere forekomster.

5. Du bør også sørge for at all ukryptert trafikk omdirigeres til HTTPS. Apaches wiki har en grei guide på hvordan dette enkelt kan gjøres. Vær også OBS på at dersom HSTS-sjekkboksen er valgt i Mozillas konfigurasjons-generator, vil nettlesere gå direkte til HTTPS etter første besøk, uavhengig av hvorvidt brukeren faktisk har tastet https://

Alt dette oppsummert burde se omtrent slik ut på RHEL 8 og høyere:

SSLEngine                           On
SSLCertificateFile                  /etc/httpd/certificates/foo.uio.crt
SSLCertificateKeyFile               /etc/httpd/certificates/foo.uio.key
SSLCertificateChainFile             /etc/httpd/certificates/intermediate.crt
Protocols                           h2 http/1.1
Header always set                   Strict-Transport-Security "max-age=63072000"
SSLProtocol                         all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite                      "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
SSLHonorCipherOrder                 On
SSLSessionTickets                   Off
SSLCompression                      Off
SSLUseStapling                      On
SSLStaplingResponderTimeout         5
SSLStaplingReturnResponderErrors    Off
SSLOCSPProxyURL                     http://update.uio.no:3128/

6. Til slutt starter du SSL-serveren med:

maskin.uio.no# systemctl restart httpd
Apache/2.4.6 mod_ssl/2.4.6 (Pass Phrase Dialog)
Some of your private key files are encrypted for sequrity resasons.
IN order to read them you have to provide us with the pass phrase. 

Server foo.uio.no:443 (ECDSA)
Enter pass phrase:

Sertifikat på nginx (og andre løsninger som vil ha sertifikat og intermediate samlet)

Enkelte løsninger ønsker samme format som Apache (crt/pem), men lar deg ikke angi sertifikat og chain/intermediate som separate filer. Det vanligste eksempelet på dette er nginx.

1. Sertifikatet og intermediate kombineres til en samlet fil:

cat foo.uio.no.crt intermediate.crt > foo.uio.no_fullchain.crt

2. Angi resultatet, foo.uio.no_fullchain.crt, i nginx slik som dette:

ssl_certificate /path/to/foo.uio.no_fullchain.crt;
ssl_certificate_key /path/to/foo.uio.no.key;

3. Øvrige anbefalinger fra Apache-avsnittet over, for sikker SSL-konfigurasjon med Mozillas konfigurasjons-generator, nøkkelhåndtering m.m., må følges også for nginx, med egnede tilpasninger.

Sertifikat på løsninger som kun lar deg angi én fil i sertifikatkonfigurasjon

Enkelte løsninger ønsker samme format som Apache (crt/pem), men lar deg kun angi én enkelt fil for alt av sertifikater og nøkkel.

1. Kombiner alle de tre separate filene (i samme katalog) til én samlet fil:

cat foo.uio.no.key foo.uio.no.crt intermediate.crt > foo.uio.no.pem
chown 400 foo.uio.no.pem

2. Resultatet, foo.uio.no.pem, kan så angis.

VIKTIG: Merk at den resulterende filen (foo.uio.no.pem) må beskyttes på samme måte som den separate nøkkelfilen (foo.uio.no.key) ettersom den inneholder den private nøkkelen!

Denne løsningen kan også benyttes i nyere versjoner av Apache, men er frarådet i Apaches dokumentasjon.

Sertifikat på IIS (og andre Microsoft-løsninger)

For IIS-webservere (og de fleste andre Microsoft-produkter), må du konvertere sertifikatet. ??Du mottar som regel sertifikatet som en zip-fil. Zip-filen må du pakke ut på vanlig måte før du starter konverteringen.

.crt-filen brukes, sammen med intermediate-sertifikat og nøkkelen som man laget sammen med den opprinnelige bestillingen, til å lage en PFX.

For Windows Server 2019 eller høyere:

openssl pkcs12 -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha512 -export -in foo.uio.no.crt -inkey foo.uio.no.key -out foo.uio.no.pfx -certfile intermediate.crt

For Windows Server 2012R2, og for Windows Server 2016 (med versjonsnummer under 1709), må man istedet bruke denne kommandoen:

openssl pkcs12 -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -nomac -export -in foo.uio.no.crt -inkey foo.uio.no.key -out foo.uio.no.pfx -certfile intermediate.crt

Resultatet, foo.uio.no.pfx, kan så importeres i IIS.

Noen Microsoft-løsninger kan kreve at sertifikat eller nøkkel har enkelte (lite brukte og i hovedsak utdaterte) egenskaper satt, som eksempelvis Key Usage o.l. Dette gjelder særlig MSSQL. Enkelte av disse egenskapene har i moderne sertifikat med ECDSA blitt erstattet med andre/nyere egenskaper for samme formål, og det vil dermed ikke være mulig å tilfredsstille disse kravene med et sertifikat med moderne signering. Sannsynligvis blir du ikke rammet av dette, men dersom du opplever problemer du mener kan være knyttet til dette - særlig med annet enn MSSQL - ta kontakt med www-drift slik at vi kan kartlegge hvorvidt du vil trenge å få utstedt en annen type sertifikat.

Sertifikat på appliances / proprietære løsninger

Enkelte appliances og andre proprietære/black box-løsninger vil gjerne "hjelpe" brukeren på forskjellige måter med håndtering av sertifikater. Noen genererer selvsignerte sertifikater. Selvsignerte sertifikater skal ikke brukes. Alt som kobles på nett på UiO skal ha et hostnavn, og hostnavn har kun anledning til å benytte sertifikater utstedt av UiOs CA. Hvis du er usikker på hvordan ta i bruk et gyldig (ikke-selvsignert) sertifikat på en appliance du jobber mot, kontakt leverandøren for hjelp.

Hvis du har mulighet til å ta i bruk egen nøkkel (f.eks. ved å laste den opp i løsningen), anbefaler vi at du følger stegene beskrevet i denne kokeboken for å selv generere nøkkel og CSR på vanlig og anbefalt måte (steg A, over). Denne nøkkelen og det utstedte sertifikatet benyttes så istedenfor noe appliancen selv har kokt ihop. Hvs du ikke har mulighet til dette, og kun kan benytte nøkkel og CSR som appliancen selv har generert, sørg for at nøkkel og CSR i størst mulig grad gjenspeiler egenskapene beskrevet i denne kokeboken. Kort oppsummert vil dette si ECDSA med P-256 om mulig (eller RSA med 2048 bit hvis ikke), samt C- og O-verdier som du finner i avsnittet "Generere nøkkel og CSR".
Se også avsnittet spesifikt om bruk av RSA.

Feilsøking og svar på spørsmål

Tema i denne listen er for spesielt interesserte, og er primært ment som en referanse å peke til for spørsmål eller problemer som i blant dukker opp. Dersom du har fulgt kokeboken, alt fungerer bra, og du ikke har spesielle spørsmål eller behov, kan du trygt hoppe over denne seksjonen.

Gjenbruk av nøkler? Ikke tillatt!

Selv om det er hypotetisk mulig å gjenbruke nøkler, er dette ikke tillatt ved UiO. Alle sertifikat skal benytte en unik nøkkel, og nye nøkler skal alltid utstedes ved fornyelse av sertifikat, gjenutstedelse av sertifikat osv. I korte trekk kan man si at all nøkkelbruk er engangs, og alle nøkler skal regnes som eksklusivt og uløselig knyttet til sertifikatet de tilhører.

Gjenbruk av CSR? Ikke tillatt!

En CSR er knyttet til en spesifikk nøkkel, og som påpekt i forrige punkt, er det ikke tillatt å gjenbruke nøkler. Dermed er det heller ikke tillatt å bruke CSR på nytt, f.eks. å bruke CSR fra tidligere når man skal fornye et sertifikat. Ny nøkkel, ny CSR, nytt sertifikat.

Når du har fått utstedt et sertifikat, kan du egentlig bare kaste CSRen. Akkurat som nøkler bør bruk av CSR regnes som engangs, men til forskjell fra nøkler tjener CSRen ikke lengre noen hensikt etter at sertifikatet er utstedt.

Må jeg bruke intermediate?

Ja, du må alltid bruke intermediate, ellers kan ikke sertifikatet valideres. Noen ganger kan det virke som om sertifikatet likevel virker selv om man ikke har satt opp intermediate korrekt - særlig om man tester i en nettleser. Se avsnittet om hva dette skyldes, som forklarer hvorfor man ikke bør bruke nettlesere til å teste sertifikater, og hvordan man heller bør teste sertifikatet for å være sikker på at det er satt opp riktig.

Se evt. også avsnittet om hvilken root dersom du er interessert i flere detaljer om hvordan dette fungerer, og hvorfor du alltid må inkludere intermediate.

Hvilken intermediate skal jeg bruke?

Alltid bruk intermediate som fulgte med sertifikatet du brukte. Man bør altså ikke gjenbruke intermediates man har mottatt sammen med andre/gamle sertifikat. Hver CA benytter gjerne et utall forskjellige intermediates for utstedelse og signering, og man har aldri garanti for at ikke sertifikatet man nettopp mottok er utstedt av en helt annen intermediate enn et tidligere sertifikat var. Den eneste måten å være sikker på at det blir riktig er å alltid bruke medfølgende intermediate, og ha dette som fast rutine.

Må man absolutt ha en pass phrase på nøkkelen?

Anbefalingen om å ha en pass phrase på nøkkelen er nettopp det: en anbefaling. Akkurat som med SSH-nøkler er det sikrest å beskytte med pass phrase, men noen ganger er ikke dette praktisk gjennomførbart, av forskjellige grunner. Det anmodes derfor om å utvise skjønn, og benytte dette der det er mulig.

Guiden beskriver stegvis hvordan generere nøkkel, foo.uio.no.key, og så lage en pass phrase-beskyttet utgave av denne, foo.uio.no-enc.key. Den opprinnelige kopien av nøkkelen (foo.uio.no.key) vil ikke være pass phrase-beskyttet, og man kan evt. velge å hoppe over steget som genererer filen foo.uio.no-enc.key dersom man ikke skal benytte denne.

Hvordan endre pass phrase på den private nøkkelen

Du kan endre passordfraser på de private nøklene på denne måten:

maskin.uio.no# openssl ec -aes256 -in foo.uio.no.key -out foo.uio.no.key.new
read EC key
writing EC key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

maskin.uio.no# mv foo.uio.no.key.new foo.uio.no.key

Hvordan lager jeg en trust store

Svaret på dette er nesten alltid du skal ikke lage en trust store.

TL;DR: Bruk systemets innebygde trust store, og kun denne. Ikke tukle med den, ikke legg til noe, ikke fjern noe. La trust store være i fred, følg kokeboken, og det vil gå deg godt. Se også neste punkt.

Klienter som skal prate med serveren hvor sertifikatet er satt opp, trenger å bruke en trust store (også kjent som root store, CA path, CA file og ymse andre navn). Som regel vil applikasjonen som default bruke systemets globale trust store, og da er det ikke noe mer å tenke på. Et korrekt deployet sertifikat vil da stoles på uten at man trenger å foreta seg noe mer.

Andre ganger er man nødt til å eksplisitt angi en trust store. Dette ser man gjerne med Java-applikasjoner, men dette kan i prinsippet gjelde enhver applikasjon. Man skal da ikke opprette en egen trust store kun for et enkelt spesifikt formål, eller bruke noe fra en tredjepart, men peke på systemets trust store. Denne kommer fra leverandør (typisk Red Hat), og blir vedlikeholdt, som systempakke, sammen med resten av systemet, med sikkerhetsoppdateringer og annet. Enhver annen trust store vil som regel vedlikeholdes sjeldnere, dårligere, eller vel så ofte ikke i det hele tatt. På samme måte som programvare som ikke vedlikeholdes, er dette en fryktelig dårlig idé.

Flg. stier er de eneste som skal benyttes som trust store. Sørg for at pakken ca-certificates er installert og oppdatert!

Red Hat (og beslektede distroer som Fedora, CentOS, Rocky osv.):

Fil (CAfile): /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
Dir (CApath): /etc/pki/ca-trust/extracted/pem/ (i Fedora kan man istedet bruke /etc/pki/ca-trust/extracted/pem/directory-hash/)
Java: /etc/pki/ca-trust/extracted/java/cacerts

Debian (og beslektede distroer som Ubuntu osv.):

Fil (CAfile): /etc/ssl/certs/ca-certificates.crt
Dir (CApath): /etc/ssl/certs/
Java: /etc/ssl/certs/java/cacerts (trenger pakken ca-certificates-java)

Alpine Linux (containere):

Fil (CAfile): /etc/ssl/certs/ca-certificates.crt
Dir (CApath): /etc/ssl/certs/
Java: /etc/ssl/certs/java/cacerts (trenger pakken java-cacerts)

Hva skal jeg putte i trust store

Det eneste riktige svaret på dette spørsmålet er ingenting.

Noen ganger blir man fortalt at intermediate skal puttes i trust store. Det skal den ikke.

Korrekt deployment av sertifikater utstedt av CA skal under alle normale forhold aldri medføre at noe må eller skal legges til andre steder enn på server ihht. denne kokeboken. Ikke intermediate, ikke root, ikke sertifikatet, ingenting. Alt klienten trenger for å verifisere et sertifikat mot en trusted root skal komme fra server, uten behov for noen som helst endringer på klientsiden. Med andre ord har klienten allerede alt den trenger for å verifisere et sertifikat som er deployet riktig. Klienten verken trenger eller skal trenge å vite noe om intermediates på forhånd; disse skal den få fra server, sammen med sertifikatet, slik at dette tilsammen utgjør en chain som kan verifiseres mot en root den alt stoler på.

Dersom å tukle med trust store (f.eks. ved å legge inn en intermediate) kan virke å "løse et problem" er det en indikasjon på et problem på serversiden - ikke på klientsiden - og å gjøre endringer på klientsiden er følgelig helt feil "løsning". Dette er altså ikke en løsning, men å maskere det egentlige problemet, på en helt feil måte. Riktig løsning er så enkel som å sørge for at server svarer med full chain, opp til root, slik at denne kan verifiseres mot klientens trust store. Er dette gjort riktig ihht. denne kokeboken vil ting fungere, og ikke minst, fungere slik dette skal fungere.

Se også avsnittet Hvorfor fungerer sertifikatet mitt i nettlesere, men ikke andre klienter for andre måter slik feil deployment av sertifikat kan bli maskert. Løsningen er den samme: følg kokeboken.

Hvilken root skal jeg bruke

Dette er egentlig feil spørsmål å stille. Du skal ikke bruke noen root.

Sertifikatet du mottar er signert av et intermediate-sertifikat. Intermediate-sertifikatet er signert av et root-sertifikat. Serveren sender server-sertifikatet og intermediate-sertifikatet til klienten, slik du har satt den opp til å gjøre. Klienten verifiserer så chain; at server-sertifikatet er signert av intermediate-sertifikatet, og at intermediate-sertifikatet er signert av et root-sertifikat som klienten alt har i dens trust store, og dermed stoler på. Da kan chain verifiseres, og server-sertifikatet stoles på, ettersom det kan forankres mot noe i klientens trust store. Er det flere nivå, altså flere nivåer av intermediates mellom root og server-sertifikatet, er prosedyren den samme, og server må sørge for å sende med alle intermediates som trengs for å forankre sertifikatet mot en trusted root. (For UiO-bruk er det dog normalt sett kun én intermediate)

Root-sertifikatet er altså noe klienten allerede har, og må ha for at sertifikatet skal kunne stoles på. Det har følgelig ingen hensikt å sende root-sertifikatet fra server; hvis ikke root-sertifikatet allerede stoles på, vil ikke klienten begynne å stole på det noe mer om det kommer uoppfordret fra en "tilfeldig" server på Internet. Dermed skal man ikke forholde seg til root på server-siden; om dette blir konfigurert der, blir dette simpelthen forkastet av klienter, og utgjør ikke annet enn bortkastede bytes, ofte betegnet som et unødvendig anker. Med andre ord konfigurerer man ikke root på server - dette har ingen hensikt.

Så du, som server-administrator, skal altså ikke forholde deg til roots. Dette er noe klienten må ha fra før for at ting skal fungere. Se også avsnittet Hva skal jeg putte i trust store (hvor svaret er "ingenting").

Når alt dette er sagt; det hender likevel at enkelte proprietære/sære løsninger insisterer på å bli matet med en root, selv om det ikke egentlig er noen reell grunn til at de skal trenge dette, eller bruke den til noe. Se også avsnittet om deployment på appliances. Dersom du er avhengig av å gi serveren en gyldig root for å komme i mål, finner du alle relevante roots på Sectigos sider. Riktig root vil være en av de to øverste. Er du usikker på hvilken root som har signert relevant intermediate, og dermed hvilken root du må laste ned, kan du sjekke dette slik:

maskin.uio.no# openssl x509 -noout -issuer -in intermediate.crt

Utfører man samme kommando mot nedlastet root, skal output (i hvert fall verdien av CN) være lik.

Som en kuriositet kan også nevnes kryss-signering. Dette er hvor en root signeres av en annen root, for å ytterligere øke utbredelse av trust blant klienter. Om man har et sertifikat som (via intermediate) chaines mot en root utstedt i 2019, kan det være at eldre klienter (og/eller klienter som ikke har fått oppdatert systemets trust store) mangler rooten, og dermed ikke vil stole på sertifikatet. Dersom rooten fra 2019 også i seg selv er signert av en root fra 2005, vil sertifikatet også kunne stoles på av de eldre klientene, som mangler rooten fra 2019, men har rooten fra 2005. Da utvides chain med ett ledd, slik at nyere klienter vil fullføre chain mot root fra 2019, og si seg fornøyd med det, mens eldre klienter vil fullføre chain mot root fra 2005 (som de har), via root fra 2019 (som de ikke har).

For at dette skal fungere, må dog server (som alltid) sende full chain opp til root som klienten kan validere mot. Dette vil med andre ord si at alle svar fra server må inkludere root fra 2019, som så blir forkastet som unødvendig anker av den absolutte brorpart av klienter, men er nødvendig for at fåtallet eldre klienter skal kunne validere chain. UiOs CA Sectigo har tilrettelagt for slik bruk ved at roots som benyttes (USERTrust) er kryss-signert av en veldig gammel root (AAA Certificate Services), men vi benytter oss i utgangspunktet ikke av dette, da klienter som er for gamle til å ha USERTrust i sin trust store i de aller fleste tilfeller også er for gamle til å kunne bruke våre tjenester, f.eks. ved at de ikke støtter tilstrekkelig moderne TLS-versjon, eller at de mangler SNI-støtte.

Det kan dog finnes kanttilfeller hvor slik bruk kan ha nytteverdi, f.eks. ved bruk hvor klientene har en veldig begrenset trust store, og/eller en trust store som sjelden eller aldri oppdateres, typisk på appliances av ymse natur. Dessverre er dette ikke så uvanlig som man skulle tro eller håpe, og for slik bruk kan kryss-signering mot eldre root være en løsning. Eksempler på slikt ved UiO kan inkludere eksempelvis VoIP-telefoner eller annet AV-utstyr. Av kjente eksempler på bruk av kryss-signering ellers kan nevnes Let's Encrypt's raske inntog på CA-fronten vha. kryss-signering av leverandøren IdenTrust, eller BBCs løsning for å få sin iPlayer-løsning til å fortsette å fungere på riktig utdaterte smart-TVer.

Hvorfor fungerer sertifikatet mitt i nettlesere, men ikke andre klienter

Noen ganger kan man oppleve at man har testet sertifikatet i en nettleser, og alt ser ut til å fungere fint, men likevel får man feilmeldinger fra andre klienter.

Dette skyldes nesten alltid at server ikke svarer med komplett chain for at sertifikatet skal kunne verifiseres mot et anker i klientens trust store. Typiske feil er at intermediate mangler fra chain som returneres fra server, at det er benyttet feil intermediate, eller at rekkefølgen er feil.

Grunnen til at dette likevel fungerer i nettlesere er fordi disse er mer tilgivende enn andre klienter, en slags bjørnetjeneste for brukere slik at de skal få tilgang også til feilkonfigurerte servere, når feilen ikke nødvendigvis kompromitterer sikkerheten. Denne tilnærmingen kalles AIA Fetching, og er kontroversiell bl.a. fordi den kan dekke over konfigurasjonsfeil på serveren. All den tid dette faktisk er en konfigurasjonsfeil, må den rettes for at sertifikatet skal være korrekt installert og fungere i alle klienter - også i flertallet som ikke har implementert AIA Fetching.

Det anbefales derfor ikke å bruke nettlesere for å teste om sertifikat er riktig installert og/eller fungerer. Bruk heller f.eks. cURL istedet (for HTTPS):

maskin.uio.no# curl -svo /dev/null https://foo.uio.no/

Eller OpenSSL direkte - denne metoden er protokollagnostisk, og kan dermed brukes mot annet enn HTTPS ved å endre portnummer:

maskin.uio.no# echo | openssl s_client -showcerts -servername foo.uio.no -connect foo.uio.no:443 2>/dev/null

Output fra disse kommandoene vil variere stort, men ser du en melding som "SSL certificate verify ok", "Verify return code: 0 (ok)", "Verification: OK" el.l. burde ting være på stell. Om du derimot ser en melding som "unable to get local issuer certificate" eller "unable to verify the first certificate", da returnerer tjenesten feil og/eller ukomplett chain, og må fikses.

For å løse dette, gå til avsnittet Legg opp sertifikat på server, start forfra, og sørg for at stegene følges nøyaktig.

Nøkkeltype, nøkkellengde og kurver

Denne kokeboken inneholdt tidligere instruksjoner for å generere sertifikatforespørsler med nøkkeltypen RSA, men er nå oppdatert til å istedet benytte nøkkeltype ECDSA. RSA er en gammel og treg algoritme fra 70-tallet, som i dag egentlig ikke kan vise til andre fordeler enn veldig stor utbredelse - en slags absolutt minste felles multiplum. ECDSA tilhører familien elliptisk kurve, gir mangfoldige ganger bedre ytelse, og er i dag mer enn utbredt nok til å kunne brukes eksklusivt. ECDSA er i dag støttet av alle moderne servere og klienter, og brorparten av UiOs mange websider m.m. bruker i dag kun ECDSA.

Vi anbefaler NIST P-256 (aka prime256v1 aka secp256r1 - merk r1, ikke k1) som kurve, da denne har størst utbredelse blant elliptiske kurver, og følgelig gir best kompatibilitet. 256 bits ECDSA gir 128 bits sikkerhet. Dette tilsvarer 3072 bits RSA, men er mangfoldige ganger raskere. Når man bruker RSA er det i skrivende stund vanligst å bruke 2048 bits nøkkel, hvilket gir 112 bits sikkerhet.

Oppsummert er altså dagens anbefaling av ECDSA med P-256 både raskere og sikrere enn den gamle anbefalingen av RSA med 2048 bits nøkkel. For spesielt interesserte finnes det mange gode artikler der ute som beskriver dette nærmere, samt demonstrerer at det i dag ikke er kompatibilitetsproblemer knyttet til dette valget. Om man ønsker å teste ytelsesforskjellene på egen hardware kan man bruke denne kommandoen:

maskin.uio.no# openssl speed rsa2048 ecdsap256

Typiske resultat vil vise at ECDSA P-256 er ca. 4 ganger raskere enn RSA 2048. Sammenligner man samme sikkerhetsnivå som ECDSA P-256 tilbyr (128 bits sikkerhet), altså RSA 3072, vil man se at ECDSA er ca. 75 ganger raskere.

For løsninger hvor det er et reelt behov for å støtte RSA, bør man undersøke hvorvidt man istedet kan bruke dual certificates, dvs. at løsningen benytter to sertifikat - både ECDSA og RSA - slik at RSA kun benyttes mot klienter som ikke støtter ECDSA. Dette bygger på en standardisert TLS extension, og er fullt bakoverkompatibelt med gamle/"dumme" klienter som ikke har kjennskap til denne. En slik løsning har i en årrekke vært støttet av f.eks. Apache, nginx, HAProxy m.m. (sammen med en tålelig moderne versjon av OpenSSL), men skaper naturligvis merarbeid, bl.a. i form av flere sertifikater å vedlikeholde, og er dermed frarådet med mindre man konkret vet at man har behov for å støtte (sære) klienter som er ute av stand til å forstå ECDSA. Dersom dere mener dere har tjenester som passer denne beskrivelsen, ta kontakt med www-drift som kan bistå med oppsett. Se også neste avsnitt spesifikt om RSA.

Kan jeg bruke RSA?

Helst ikke. Som nevnt ellers i denne kokeboken, bør ECDSA med P-256 benyttes overalt hvor det er mulig. Det er dog enkelte proprietære løsninger som ikke ennå har støtte for noe nyere enn RSA - dette gjelder i dag som regel alltid på serversiden, og er henimot aldri et problem på klientsiden. Eksempelvis er det kjent at visse løsninger fra VMWare og Cloudian per 2022 ikke er i stand til å benytte ECDSA. Løsninger typisk fra Microsoft som gjør seg avhengige av at det defineres Key Usage (kjente eksempler inkluderer MSSQL og AD domenekontrollere) er også nødt til å bruke RSA, ettersom Key Usage er deprecated for ECDSA. I slike tilfeller er det selvfølgelig greit å benytte RSA (man har vel strengt tatt ikke noe valg), men vi anbefaler alltid å teste ECDSA først, og kun benytte RSA dersom man har kunnet fastslå at den aktuelle løsningen ikke har mulighet til å benytte ECDSA.

Dersom man er tvunget til å bruke RSA, sørg for å lese neste avsnitt om nøkkellengde, samt avsnittet om proprietære løsninger.

Størrelse/lengde på nøkkel

Man ser stadig eksempler på at det benyttes RSA med 4096 bits nøkkel, formodentlig utifra prinsippet om at bigger is better. Dette frarådes, da det har en markant negativ effekt på ytelse, uten noen reell gevinst. Det er altså ikke slik at dette gir "dobbelt så sterk sikkerhet" eller noe slikt; i realiteten gir dette ca. "kun" 140 bits sikkerhet, men med en voldsom kost i form av ytelse, ettersom RSA er en treg og gammel algoritme. Sannsynligheten for at 112 bits kryptering kan brekkes innen utløpet av et sertifikat (for tiden maks 1 år) er per i dag i prinsippet ikke-eksisterende, og man oppnår dermed ingenting annet ved å bruke nøkkelstørrelser over 2048 med RSA enn å bruke mer strøm.

Følgelig er det heller ikke behov for å bruke andre/større kurver med ECDSA enn P-256. Dette kan gi kompatibilitetsproblemer dersom man ikke kjenner sitt publikum i detalj, og dette gjelder dermed særlig for bruk på web. Å velge f.eks. P-384 istedenfor P-256 vil dessuten gi vesentlig dårligere ytelse, og 192 bits sikkerhet er regnet som overkill for dagens bruk av sertifikater ved UiO. Man bruker da fire ganger mer strøm enn RSA 2048, eller 40 ganger mer strøm enn ECDSA P-256 på å oppnå et sikkerhetsnivå som er helt unødvendig, i tillegg til at man mister hele ytelsesfordelen (og mer til) fra å velge elliptisk kurve generelt.

Om man følger eksempelet fra avsnittet om nøkkeltype, vil man enkelt selv kunne verifisere at RSA 4096 er i snitt 180 ganger tregere enn ECDSA P-256 som er anbefalt. Sagt på en annen måte; ECDSA P-256 kan utføre samme mengde signeringsoperasjoner på ett minutt som RSA 4096 ville brukt tre timer på.

Qualys SSL Labs er også helt enig i denne vurderingen, og som de forklarer i sine best practices: "using a key that is too long will result in “too much” security and slow operation. For most web sites, using RSA keys stronger than 2,048 bits and ECDSA keys stronger than 256 bits is a waste of CPU power and might impair user experience. Similarly, there is little benefit to increasing the strength of the ephemeral key exchange beyond 2,048 bits for DHE and 256 bits for ECDHE. There are no clear benefits of using encryption above 128 bits."

Ingen regel uten unntak: Nasjonal sikkerhetsmyndighet gir anbefalinger for innhold omfattet av sikkerhetsloven, dvs. gradert innhold. Dersom du trenger et sertifikat for å beskytte innhold som er sikkerhetsgradert (og/eller berører rikets sikkerhet), kan du velge å følge deres anbefalinger. Hvis ikke, bør du nok heller følge anbefalingene i denne kokeboken.

Det kan også finnes hypotetiske argumenter for bruk av 4096 bits RSA med f.eks. PGP o.l., hvor en nøkkel forventes å leve vesentlig lengre, og signeringsoperasjoner finner sted langt sjeldnere enn f.eks. på web, men også for slik bruk anbefales det å heller ta i bruk elliptisk kurve.

TL;DR: Følg anbefalingene i denne kokeboken, og bruk ECDSA med P-256.

Dersom dere likevel mener dere har et legitimt behov for å bruke RSA, og/eller trenger større nøkler enn de anbefalt i denne kokeboken, ta kontakt med www-drift, som kan bistå med å vurdere behov. Men sørg for å lese avsnittet om nøkkeltype, nøkkellengde og kurver først.

Hva er OCSP?

Et sertifikat utstedt av en CA vil også kunne tilbakekalles (revoke) av samme CA. Det kan være forskjellige årsaker til at man ønsker å gjøre dette, f.eks. dersom nøkkelen har havnet på avveie, eller at man simpelthen ønsker å sørge for at sertifikatet ikke lenger skal kunne benyttes.

Litt forenklet kan man si at det finnes to forskjellige løsninger for dette: CRL og OCSP. CRL er i dag mindre i bruk, mens OCSP fortsatt benyttes aktivt. Begge har flere problemer, som Scott Helme forklarer grundig i en utførlig artikkel om temaet, og som dermed ikke trengs å gjentas her.

Utover de tekniske og funksjonelle problemene med OCSP, som i mange situasjoner kan og vil medføre at tiltenkt funksjonalitet simpelthen ikke vil fungere (og dessuten uten at bruker får vite noe om det), er det også et personvernelement. For å finne ut hvorvidt et sertifikat er tilbakekalt, må klienten spørre CAs OCSP-tjeneste, og dette må gjøres jevnlig for å få verifisert (på nytt) at sertifikatet (fremdeles) ikke er tilbakekalt. Dermed blir dette i prinsippet en "phone home"-aktig tjeneste, hvor CA jevnlig blir uoppfordret fortalt IP-adressene til besøkende av en tjeneste som benytter et sertifikat utstedt av samme CA, samt andre detaljer som klienter (eksempelvis nettlesere) avslører.

Grunnet alle disse problemene (og flere), er det stadig flere klienter som simpelthen skrur av støtte for slike tredjeparts OCSP-kall mot CA. Vesentligst av disse er kanskje Google Chrome, og derav også de fleste nettlesere basert på Chromium-motoren, som tilsammen utgjør et stort flertall av nettlesere i daglig bruk. Denne beslutningen er naturligvis både veloverveid og forståelig, men konsekvensen er at et absolutt flertall av dagens nettlesere vil aldri få vite om at et sertifikat har blitt tilbakekalt.

Nytteverdien av OCSP i sin opprinnelige form er dermed i dag høyst diskutabel. Ved UiO benyttes tilbakekallingsfunksjonaliteten for sertifikat svært sjeldent, men det vet jo ikke klienter med aktiv OCSP-støtte, og disse vil dermed like fullt jevnlig (og så å si alltid helt unødvendig) kontakte CAs OCSP-endepunkt.

Heldigvis har det etter hvert kommet bedre løsninger på de fleste av disse utfordringene, i form av utvidelsen OCSP stapling, dekket i neste avsnitt. Til forskjell fra standard OCSP krever dog OCSP stapling bevisst og aktivt oppsett på server-siden for å fungere. Har du giddet å lese så langt som dette, bør du definitivt også lese neste avsnitt.

Hva er OCSP stapling?

Med "vanlig" OCSP vil klienten motta et sertifikat fra server, parse dette, finne ut CAs OCSP-endepunkt fra sertifikatet, initiere en request mot CAs OCSP-endepunkt, få svar (eller ikke) på dette, og dersom svaret sier at sertifikatet er tilbakekalt, stoppe videre forbindelse(r) som benytter sertifikatet. Ved negativt svar, fortsetter ting som før. Ved intet svar, vil som regel forbindelsen fortsette likedant som ved negativt svar, ettersom de aller fleste klienter behandler dette som en "soft fail". I alle tilfelle vil forespørselen mot OCSP-endepunktet av ytelseshensyn skje i parallell, så hvis eksempelvis sertfikatet ble misbrukt til å spre malware som trigger on load, vil denne fremdeles kunne trigge dersom server svarer raskere enn OCSP-endepunkt - og selv når klienten ikke anser OCSP-feil som en soft fail (ettersom klienten som nevnt ikke vil vente på OCSP-svar - disse er non-blocking).

OCSP stapling snur den tradisjonelle mekanismen (beskrevet i forrige avsnitt) så å si på hodet. Istedenfor at hver klient selv skal måtte spørre OCSP-endepunktet, vil server som benytter sertifikatet spørre på vegne av alle klienter, for hvert sertifikat den benytter. Svaret fra OCSP-endepunktet vil så leveres til klienter samtidig som sertifikatet, med OCSP-svaret "stiftet" til sertifikatet. Svaret er kryptografisk signert, slik at klienter kan vite at det kan stoles på.

Dette løser dermed de fleste problemer med OCSP:

Klienten trenger ikke å selv kontakte OCSP-endepunktet
OCSP-svar gis tidlig nok til at inget innhold vil lastes før man får svar hvorvidt sertifikatet ikke er tilbakekalt
Personvern er ivaretatt ved at det ikke genereres trafikk fra klient til CA
Ytelse på klientsiden forbedres ved å eliminere et eksternt kall
OCSP-tjenester blir ikke "DDoS"-et i samme grad - hver server gjør i snitt ett kall i timen per sertifikat, istedenfor at alle klienter skal måtte gjøre det løpende
OCSP vil fungere selv om OCSP-endepunktet midlertidig er nede eller overbelastet, ettersom servere i prinsippet cacher svaret på dets vegne

For at OCSP stapling skal kunne fungere, må dog dette støttes av server (samt underliggende TLS-bibliotek), og skrus på og aktivt konfigureres. I konfigurasjonseksempelet for Apache er dette alt inkludert, og ved å lime inn foreslått konfigurasjon burde dette fungere uten videre. Tilsvarende konfigurasjon vil nok også etter hvert legges til for nginx. For andre løsninger enn dette bør man sjekke dokumentasjon eller kontakte leverandør. Se også neste avsnitt om proxy for OCSP stapling, som i de fleste tilfeller vil være nødvendig å ha med.

Hvordan kan serveren min snakke med et OCSP-endepunkt?

Om du har lest forrige avsnitt om OCSP stapling, og ønsker å aktivere dette for din tjeneste, er det et siste vesentlig hensyn for tjenester ved UiO som må tas. Mange av våre servere er satt opp på begrensede nett (typisk kat3 og nedover), som ikke har tilgang til å gjøre kall mot eksterne tjenester. Disse er nødt til å benytte en proxy for at dette skal fungere - enten en reverse proxy eller en forward proxy.

Dersom løsningen støtter bruk av forward proxy (HTTPS proxy, ikke f.eks. SOCKS proxy) for OCSP-kall, er det som regel enklest å benytte dette. I Apache er eksempelvis dette støttet fom. version 2.4.19, i form av konfigurasjonsdirektivet SSLOCSPProxyURL. Man benytter update-proxy til dette formålet, og konfigurasjon vil typisk se slik ut (som allerede er inkludert i foreslått config for Apache):

SSLOCSPProxyURL http://update.uio.no:3128/

Dersom løsningen ikke støtter bruk av forward proxy, må man istedet benytte en dedikert reversproxy. For dette formålet har vi satt opp ocsp-proxy.uio.no, en intern tjeneste som kun reversproxyer OCSP-endepunktet for UiOs til enhver tid gjeldende CA. For å benytte denne, bør løsningen ha en måte å overstyre hostnavn for OCSP-endepunktet, slik at server vil prate med adressen vi setter istedenfor adressen som er angitt i sertifikatet. Selv om sertifikatet spesifiserer at OCSP-kall skal gjøres mot geant.ocsp.sectigo.com, trenger vi altså å kunne fortelle server at de samme kallene istedet skal gjøres mot ocsp-proxy.uio.no.

For f.eks. nginx kan man fom. versjon 1.3.7 sette dette med konfigurasjonsdirektivet ssl_stapling_responder på denne måten:

ssl_stapling_responder http://ocsp-proxy.uio.no/;

For Apache-versjoner eldre enn 2.4.19, eksempelvis på RHEL 7, kan man gjøre tilsvarende med direktivet SSLStaplingForceURL:

SSLStaplingForceURL http://ocsp-proxy.uio.no/

Dersom løsningen støtter OCSP stapling, men mangler en funksjon for å la deg overstyre OCSP URL, er det i prinsippet mulig å bare overstyre DNS-oppslaget på server, ved å gjøre noe i stil med dette:

maskin.uio.no# echo geant.ocsp.sectigo.com $(getent hosts ocsp-proxy.uio.no | awk '{ print $1 }') | sudo tee -a /etc/hosts

Dette vil dog være en mindre robust løsning, og kan komme til å brekke i fremtiden, dersom f.eks. ocsp-proxy bytter IP, eller CA bytter OCSP-endepunkt. Dette bør dermed kun være en siste utvei, dersom ingen av de tidligere nevnte metodene er mulige.

Kan jeg bruke en annen CA, f.eks. Let's Encrypt?

Nei. Sertifikater for uio.no og andre domener eid av UiO skal kun utstedes av CA som UiO til enhver tid har avtale med, og gjennom UiOs rammeverk tilrettelagt i denne kokeboken. Vi benytter Certificate Authority Authorization (CAA, RFC 8659) som vil blokkere forespørsler mot ikke-godkjente CAer om å utstede nye sertifikater under uio.no. Forsøk på å utstede sertifikater fra en ikke-godkjent CA vil utløse varsling til IT-Sikkerhet.

Som regel dukker dette spørsmålet opp ifbm. med ønske om å bruke certbot. Dersom dere har et sterkt ønske om å bruke certbot, se eget avsnitt om dette.

UiO får utstedt sertifikater via en avtale gjennom Sikts (tidl. Uninett) Cybersikkerhetssenter for forskning og utdanning, som igjen baseres på den kollektive avtalen Trusted Certificate Services fremforhandlet av GÉANT (tidl. Terena). Det betales ikke stykkpris per sertifikat, og man kan i utgangspunktet utstede et ubegrenset antall sertifikat for godkjente domener.

Nåværende leverandør Sectigo er også kjent som Comodo Security Solutions, og er blant verdens desidert største kommersielle CAer, med størst utbredelse i trust stores. Gjennom konsolidering har de overtatt historiske CAer med roots som i dag representerer blant de aller eldste fortsatt gyldige roots man vil finne i noen trust store, og følgelig vil sertifikat utstedt av Sectigo ha svært god kompatibilitet med alskens klienter, nye så vel som (veldig) gamle.

Det burde dermed ikke være behov for å benytte en annen CA enn den godkjent av UiO, men dersom dere har helt spesielle behov som medfører at sertifikatene dere får utstedt ved å følge denne kokeboken ikke møter deres behov, kontakt www-drift og beskriv deres bruksområde. Det absolutt aller meste vil kunne løses innenfor rammene som er satt.

Kan jeg bruke ACME?

Det kommer an på. Vår sertifikatleverandør støtter ACME-protokollen (uttales "ækmi"), og dette er tatt i bruk for enkelte bruksområder. Deres implementasjon av ACME er dog noe begrenset hva gjelder finmasket tilgangskontroll/godkjenningsløp, og det er derfor ikke anledning til å gi ACME-tilgang direkte under uio.no. Intern policy tilsier at sertifikat utstedt direkte under dette navnerommet skal være gjenstand for manuell godkjenning før utstedelse, hvilket i skrivende stund ikke er mulig å få til med deres ACME-implementasjon.

Dersom dere er ansvarlig for et navnerom på et lavere nivå, f.eks. .institusjon.uio.no, eller et navnerom under et separat domene som kun dere kontroller (altså ikke uio.no, men som UiO har anledning til å utstede sertifikat for), kan ACME-tilgang i visse tilfeller innvilges. Dette vurderes på en case-by-case-basis, og tilbys fortrinnsvis til de som har behov for å hyppig utstede relativt mange sertifikat, for å lette arbeidsbyrden knyttet til dette og fasilitere automatisering med lav risiko. Dersom dette høres aktuelt ut, kontakt www-drift med beskrivelse.

CA tilbyr også et API, som gir muligheter for bl.a. utstedelse av sertifikater. Dette muliggjør automatisering med kode man selv må skrive, innenfor de samme rammene som for ACME beskrevet over. Det anbefales dog å heller benytte ACME som abstraksjonslag, da dette gir et generisk og standardisert grensesnitt som vil fortsette å fungere også ved fremtidige bytter av CA, eller API-endringer o.l.

Kan jeg bruke certbot?

certbot er én av svært mange tilgjengelige ACME-klienter, og er avhengig av å bruke ACME for å fungere. Med ACME-tilgang vil man kunne bruke certbot eller hvilken som helst annen ACME-klient, men ikke uten. Se avsnittet om ACME for mer detaljer.

Dersom du bruker certbot, sørg for at flg. innstillinger er satt i cli.ini, slik at genererte sertifikat får ønskede egenskaper:

key-type = ecdsa
elliptic-curve = secp256r1

Disse valgene kan også angis fra kommandolinjen dersom du benytter certbot uten konfigurasjonsfil.

Publisert 28. mars 2023 14:41 - Sist endret 12. apr. 2024 15:42