Anglická Wikipedie definuje PKI jako: A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
T. J. se nejedná pouze o software, ale i o procedury, hardware a politiky sloužící při správě digitálních certifikátů
PKI není jediný způsob, jak řešit důvěryhodnost a distribuci asymetrických šifrovacích klíčů, alternativou je třeba Web of Trust z PGP
Certifikát
Zjednodušeně je to tvrzení certifikační autority, že určitý veřejný klíč patří určitému subjektu (webovému serveru, osobě, organizaci)
Konkrétněji:
Žadatel odesílá certifikační autoritě žádost o vytvoření certifikátu s údaji, které jí dodá (např. jméno organizace/osoby, doména webového serveru atd.)
Jak taková žádost technicky vypadá specifikuje RFC 2511
Certifikační autorita nějakým způsobem ověří, že údaje jsou v pořádku (žadatel zašle nějaké své dokumenty potvrzující, že vlastní společnost/je to on, provede se nějaká automatická kontrola a pod.)
Pokud se dojde k závěru, že certifikát s uživatelem danými údaji je v pořádku vydat, podepíše uživatelem odeslané údaje certifikační autorita svým soukromým klíčem
Přidává informace o tom, o jakou certifikační autoritu se jedná, kdy je certifikát možno považovat za platný (od kdy do kdy) a další dodatečné údaje
Přes všechnu magii je certifikát pouze obyčejný soubor s určitým formátem
K reprezentaci certifikátů se používá formát X.509, který je definován v RFC 5280
RFC 5280 nedefinuje, jak certifikát vypadá na binární úrovni, pouze definuje, jak vypadá jeho ASN.1 podoba
O atributech certifikátu podrobněji
Subject certifikátu - identifikuje, komu byl certifikát vydán, složen z následujících položek - země, název organizace, část organizace (organizational unit), common name a další (viz. RFC 5280)
Při vytváření certifikační autoritou dostane sériové číslo
Délka platnosti certifikátu sice technicky omezená není, ale na certifikační autority je vyvíjen tlak, aby ji zkracovaly, aktuálně (od 1. 9. 2020) prohlížeče nepřijmou nový certifikát s dobou platnosti delší než 397 dnů
Kromě základních atributů obsahuje certifikát i rozšíření (např. specifikaci, k jakým účelům lze certifikát použít, pro jaká další jména (typicky subsomény u TLS certifikátu) je platný, jestli se jedná o certifikát CA atd.)
Pokud klient při validaci certifikátu narazí na rozšíření, které nezná, může ho ignorovat, ale pouze pokud toto rozšíření nemá nastavený příznak critical
Certifikační autorita (CA)
Entita, která vydává certifikáty
Certifikační autoritou se může stát v zásadě kdokoliv
Ale certifikáty vydané takovou autoritou nebudou mít značnou hodnotu (nikdo nově vzniklé CA ve výchozím stavu nevěří)
To může nově vzniklá CA vyřešit několika způsoby:
Její kořenový certifikát podepíše jiná CA, očekává se, že ta už důvěru má
Projde dostatkem auditů, aby byl její certifikát zařazen do úložišť důvěryhodných certifikátů v operačních systémech, prohlížečích a pod.
Například požadavky společnosti Mozilla pro zařazení nové kořenové certifikační autority jso na https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Techničtěji o certifikátech CA
Certifikáty CA musí obsahovat critical extension basic constraints s hodnotou CA nastavenou na true
Dále by měly obsahovat SubjectKeyIdentifier extension s hashem veřejného klíče
Kořenový certifikát CA je podepsán sám sebou
Typicky se kořenový certifikát nepoužívá k podepisování klientských certifikátů, na to je jeho soukromý klíč příliš cenný
CA spíš vygeneruje mezilehlý CA certifikát podepsaný kořenovým, který používá pro podepisování klientských certifikátů
Důvěryhodné autority
Aby bylo možné ověřit certifikát, který byl vydán nějakou CA, musíme mít seznam důvěryhodných certifikátů autorit, kterým věříme
Tento seznam má operační systém, ale některé aplikace (Firefox, Google Chrome, Java) mají seznam vlastní
Systémový seznam důvěryhodných certifikátů se udržuje při běžných aktualizacích systému
Někdy ale potřebujeme na úrovni systému prohlásit za důvěryhodnou nějakou CA, kterou ani třeba nechceme do distribuovaných seznamů důvěryhodných dostat (autorita používaná firmou, autorita pro testovací účely)
Naučit se jeden postup bohužel nestačí, liší se to od distribuce k distribuci
Debian a deriváty
Certifikát nově přidávané CA ve formátu pem zkopírujeme do /usr/local/share/ca-certificates
Spustíme s rootovskými oprávněními update-ca-certificates
Fedora, CentOS, Arch Linux (obecně cokoli používajícího p11-kit)
Certifikát (opět ve formátu pem) zkopírujeme do /etc/pki/ca-trust/source/anchors
Jako root spustíme update-ca-trust
Alternativa k modelu PKI, DANE
DANE - DNS-based Authentication of Named Entities
Ümožňuje ověřit, že se při navazování TLS spojení jedná o certifikát zamýšlený administrátorem vzdálené služby i bez certifikačních autorit
K této asociaci se používají tzv. TLSA RR (Resource records)
Ty jsou uloženy jako DNS záznamy domény
Je nutné, aby doména byla podepsána pomocí DNSSEC
Využití
Lze omezit CA, které mohou vydávat certifikáty pro doménu (ochrana před certifikáty vydanými sice důvěryhodnými CA, o které ale žádal někdo jiný, než majitel domény)
Lze specifikovat certifikát, který musí být používán při komunikaci se službou na daném portu a protokolu
K tomu se “zneužívá” subdoména v DNS, např. pro službu na portu 443 protokolu TCP na doméně example.com by TLSA záznam byl pro subdoménu _443._tcp.example.com.
Kdy se to hodí
Prohlížeč navazuje TLS spojení a potřebuje zkontrolovat, že dostal správný certifikát
Bohužel, podpora v prohlížečích v zásadě neexistuje
Mnohem lepší situace je, když se DANE používá k autentizaci e-mailových serverů
Podporu má jak Postfix, tak Exim4
Práce s certifikáty, aneb úvod do OpenSSL, který snad neprozradí, jak udělat domácí úkol
Utilita openssl umí s X.509 certifikáty a požadavky o certifikát (CSR) všechno možné - vytváření, vypisování obsahu, konverze atd.
Vytvoření žádosti - openssl req -new, pokud se předá ještě -x509, vytvoří se self signed certifikát, ne žádost
Pokud už máme žádost o certifikát a certifikáty CA, certifikát vytvoříme následovně: ~openssl x509 -req -in client.csr -CA subca.crt -CAkey subca.key -out client.crt -CAcreateserial~
Parametr -CAcreateserial zajistí vytvoření sériového čísla certifikátu
Bacha na to, že pokud má mít podepisovaný certifikát nějaká extensions, musí být uvedena volba -extfile a správně vytvořený soubor s konfigurací, na kterou -extfile odkazuje
Revokace certifikátů
Někdy je certifikát potřeba revokovat - hacker ukradne soukromý klíč, ztratíme k němu přístup, zjistí se, že byl certifikát vydán neoprávněně atd.
Dvě možnosti
CRL
Přes HTTP stahovaný seznam certifikátů, které mají být považovány za již neplatné, je pochopitelně podepsaný danou CA
Kde CRL sehnat říká certificate extension crlDistributionPoints
Nemusíme se ale o zneplatnění dozvědět včas - CRL nemusí být úplně aktuální
Operace nad crl viz. manuálová stránka openssl crl - vypisování a pod., openssl ca - generování a další CA operace
OCSP
Používá klient-server model, t. j. klient dostane aktuální informace o stavu certifikátu, na který se zeptá
Nemusí se stahovat potenciálně dost velký soubor revokovaných certifikátů