Maximální délka platnosti HTTPS certifikátů bude zkrácena na 1 rok

Apple v únoru 2020 na setkání zástupců certifikačních autorit a prohlížečů CA/B Forum v Bratislavě (a později oficiálně) oznámil, že od 1. září 2020 bude maximální délka platnosti TLS certifikátů v Safari (a nejspíš i v celém macOS a iOS a všech aplikacích na nich spuštěných) pouze 1 rok, přesněji 398 dní. V létě toho roku se pak ke stejnému kroku odhodlal i Chrome a Mozilla. A to je skvělé, ale proč vlastně?

Apple tedy efektivně udělal to, co většina certifikačních autorit udělat nechtěla: zkrátil maximální platnost vydávaných certifikátů na cca rok. A ačkoliv ostatní browsery o zkrácení neuvažují (zatím?), tak certifikáty s delší platností to mají v podstatě za sebou. A když píšu o certifikátech, tak myslím ty koncové a vystavené důvěryhodnými certifikačními autoritami.

Jak to bylo dřív

Maximální délka platnosti TLS certifikátů v prohlížečích je dnes 825 dní (2 roky a něco), do března 2018 byla 39 měsíců (tři a čtvrt roku) a kdysi dávno jste mohli mít certifikát platný třeba 5 nebo 10 let. Tzv. EV certifikáty měly vždy maximální platnost 2 roky (825 dní od března 2018, předtím 27 měsíců).

V září 2019 neprošel návrh na zkrácení platnosti všech typů certifikátů na 398 dní. Všechny prohlížeče zastoupené v CA/B Forum sice byly pro, ale z certifikačních autorit se ten nápad zalíbil jen třetině, což na schválení nestačilo. Ale i přesto se některé certifikační autority zavázaly, že platnost zkrátí dobrovolně. Certifikační autorita Let's Encrypt již od svého vzniku vydává certifikáty s maximální platností 90 dní (a doporučují obnovu po 60 dnech).

Apple to tedy vzal od lesa a pokud budete chtít, aby vašemu certifikátu s platností od 1. září 2020 důvěřovalo Safari (a nejspíš i všechny další prohlížeče na macOS i iOS), tak bude muset být vystaven jen na rok maximálně. Jinak návštěvníci při návštěvě vašeho webu uvidí chyby jako NET::ERR_CERT_VALIDITY_TOO_LONG apod.

Omezení platnosti v prohlížečích se tak nějak očekávalo, ale osobně jsem tipoval, že s tím přijde jako první Chrome. Ten stejnou změnu oznámil o něco později v červnu, Mozilla se přidala v červenci.

Ten samý měsíc se toto zkrácení promítlo i do základních požadavků na certifikační autority („Baseline Requirements“), které certifikát s delší platností od září už ani nesmějí vystavit. Některé autority se tím ale moc nenechaly znepokojovat a pár desítek takových certifikátů stejně 1. září vystavily.

Zneplatnění certifikátů (nefunguje)

Zkracovat maximální délku platnosti certifikátů je obecně dobrý nápad z několika důvodů: tím hlavním je asi to, že některé prohlížeče platnost certifikátů vlastně nekontrolují.

Zkuste si to sami na revoked.badssl­.com – mě se stránka ve Firefoxu (SEC_ERROR_REVOKED_CERTIFICATE) a Chrome (NET::ERR_CERT_REVOKED) na Windows i iOS nenačte, na Androidu v obojím však ano. Před nedávnem se mi ale načítala i v Chrome na Windows i přesto, že certifikát byl zneplatněn („revokován“) v podstatě hned po jeho vydání.

Pro kontrolu platnosti by prohlížeče musely stahovat tzv. CRL seznamy (Certificate Revocation List), které mohou být docela velké a načítání stránky by se zbytečně prodlužovalo, což by mohlo vést k vypneme HTTPS a bude to rychlejší! Browsery by také mohly posílat dotaz na platnost certifikátu na OCSP (Online Certificate Status Protocol) servery, které ale zrovna nemusí fungovat a co pak. Zobrazit stránku, nebo nezobrazit, to je oč tu běží.

Další možností je OCSP Stapling, kdy na planost certifikátu se zeptá rovnou server a odpověď poté po následujících X dní „přicvakává“ k certifikátu, takže browser s certifikátem dostane rovnou i informaci o tom, jestli platí, nebo ne. Jenže se na to nedá spolehnout, nelze použít rozšíření TLS Feature (OCSP Must Staple), protože třeba takový nginx v klidu pošle odpověď bez OCSP statusu, pokud ji ještě nestáhl.

A tak místo toho prohlížeče používají vlastní push update technologie na kontrolu platnosti. Firefox má OneCRL a nově testuje CRLite – systém, který umí do browseru jednorázově stáhnout informace o všech revokovaných certifikátech (10 MB balík obsahuje informace o 30 milionech takových certifikátů, tedy méně než 1 bajt na certifikát) a další zneplatněné certifikáty si prohlížeč stahuje na pozadí (přírůstky mají v průměru 580 KB za den). Chrome má CRLSets, ale v nich nemusí být všechny zneplatněné certifikáty.

Takže nejjistější je počkat do konce platnosti certifikátu a nový vyrobit s novými klíči. A je o dost velkej fous lepší čekat maximálně rok, než čekat maximálně dva roky. Ale i ten rok je pořád hodně a v již nastoleném trendu zkracování maximální platnosti bychom měli i nadále pokračovat.

EV certifikáty (nechcete)

S tou kontrolou platnosti je to trochu složitější, každý browser to (ne)dělá jinak a jsou i podstatné rozdíly mezi EV a DV certifikáty. Pro detaily a grafy a měření koukněte na články od Aarona Peterse a Matta Hobbse.

Z nich mimo jiné vyplývá, že tzv. „zelené“ EV certifikáty používat nechcete, protože kromě toho, že to jsou vyhozené peníze (browsery je na první pohled zobrazí jako DV certifikáty a název firmy, kdysi zobrazovaný hned vedle adresy stránky, je vidět až po kliknutí), tak vám to ještě zpomalí načítání webu.

Chrome totiž pokaždé, když načítá stránku s EV certifikátem, posílá dotaz na OCSP, i když se používá OCSP Stapling. Firefox platnost online neověřuje při použití OCSP Staplingu za podmínky, že platnost online ověřil nedávno ¯\(°_o)/¯

Pro úplnost: Chrome se v případě DV certifikátů nikdy nedotazuje certifikační autority na platnost, Firefox se neptá pokud DV certifikát má „přicvaknutý“ status. OCSP Stapling ❤

Logy Certificate Transparency

Dalším důvodem pro krátkou platnost je Certificate Transparency, systém logování HTTPS certifikátů. Každý certifikát musí být ve dvou nebo více (také podle délky platnosti) logách, aby ho Chrome vůbec přijal, ale co když některý log bude zneplatněn, jako se již v minulosti stalo? Log nebude zneplatněn hned, ale třeba až za půl roku od oznámení vyřazení ze seznamu známých logů. S delší platností je ale pravděpodobnější, že log bude vyřazen ještě během platnosti certifikátu, čímž ho vlastně zneplatní, protože certifikát již nebude splňovat pravidla prohlížečů.

Další důvody pro kratší platnost popisuje Scott Helme: změna podpisových algoritmů, výměna klíčů apod.

Takže suma sumárum, certifikáty s krátkou platností chceme a Apple teď „zařídil“ zkrácení na max 1 rok, děkujeme. Kupovat certifikáty s platností 2 roky už nemá moc cenu a ač to dělat stále můžete, tak od září to dělat nechcete. Byly by to vyhozený prachy a to je raději můžete dát za… třeba za účast na mém školení HTTPS (nejbližší termín: termín zatím nevypsán). Nebo za 🍻. Nebo za obojí.

Osobně používám 90 denní certifikáty od Let's Encrypt a automatizovaně (to je důležité) je obnovuji tři týdny před koncem jejich platnosti (to taky, protože kdyby automatizace selhala, a že se to občas převážně mojí vinou stane, tak pořád mám pár týdnů na opravu) a používám OCSP Stapling. Pro získání certifikátů používám Certbot (podporuje různý Linuxy a Unixy a nově existuje i beta verze pro Windows), který volám ze svého wrapperu.

A víte o tom, že existoval návrh na „STAR“ (Short Term Auto Renewed) certifikáty s platností pár hodin až maximálně pár týdnů?

---

Mohlo by vás také zajímat

• EV Certificates Make The Web Slow and Unreliable říká Aaron Peters ve svém článku
• The impact of SSL certificate revocation on web performance od Matta Hobbse
• Scott Helme ukazuje, že tato změna se dotkne cca 25 % všech HTTPS webů
• CRLite pejpr