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 ? masesp?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:
-----BEGIN CERTIFICATE REQUEST----- MIIBQjCB6gIBADBQMQswCQYDVQQGEwJOTzEdMBsGA1UECgwUVW5pdmVyc2l0ZXRl dCBpIE9zbG8xDTALBgNVBAsMBFVTSVQxEzARBgNVBAMMCmZvby51aW8ubm8wWTAT BgcqhkjOPQIBBggqhkjOPQMBBwNCAARIyJASwtMo/SBoxsEeN8z81yGTuvwHncnr /dqdJ+dbe5245qWtXZIDKRPe+/IRzfDDV0pH/VCi94K/OL/P/BSqoDgwNgYJKoZI hvcNAQkOMSkwJzAlBgNVHREEHjAcggpmb28udWlvLm5vgg53d3cuZm9vLnVpby5u bzAKBggqhkjOPQQDAgNHADBEAiA+O9D6TMa86DBrKcuFpdWbb+zJLgU9H1kx139Z 0Y5X4wIgL9zwfnCEdxigd4+1c7SW25qMxYRDiP4wE3EFTjmwIWo= -----END CERTIFICATE REQUEST-----
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.
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? forrige punkt.
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.