Názory k článku Kořen Let's Encrypt na konci měsíce vyprší, dotkne se to starších klientů

Z nostalgie som minuly rok oprasil staru Nokiu N95, ocistil alebo vymenil zajdene plasty, kupil novu baterku (na treti pokus funkcnu), ale ako obrovsky problem sa ukazali byt zastarale korenove certifikaty. Ked pozriem do windowsu vidim zoznam 40 korenov ktore pouziva, da sa to cele nejako vyexportovat resp. existuje niekde hotovy balicek beznych korenovych certifikatov co sa da zobrat a naimportovat do stareho zariadenia?

Ve FreeBSD je /etc/ssl/cert.pm:
##
## ca-root-nss.crt -- Bundle of CA Root Certificates
##
## This is a bundle of X.509 certificates of public Certificate
## Authorities (CA). These were automatically extracted from Mozilla's
## root CA list (the file `certdata.txt').
##
## It contains certificates trusted for server authentication.
##
## Extracted from nss-3.69

Takže certifikáty by byly, jak je dostat do starého zařízení je jiná věc. Když jsme měli vlastní certifikační autoritu, tak jsem její certifikát dával do různých Androidů (5, 6) a nebylo to úplně bezproblémové - minimálně se zabezpečení pokaždé vztekalo, že systém může být kompromitovaný.
iOS zase od nějaké verze (12?) takovou důvěryhodnou autoritu nebral úplně 100% a v některých situacích chtěl potvrdit, že je to v pořádku.
Kromě toho bych čekal, že tam budou i problémy s verzemi SSL/TLS. Apple kvůli tomu vydával i update na dávno nepodporované verze (iOS 7, 9, 10), aby i tato stará zařízení nebyla odstřižena od komunikace.

Mám sice openssl-1.0.2r, ale certifikáty mám DST_Root_CA_X3.crt i ISRG_Root_X1.crt. To je myslím v pořádku, že?

Podle článku na OpenSSL.org to v pořádku nebude. Knihovna si všimne, že jedna z cest expirovala a vyhlásí chybu. Je nutné ten neplatný certifikát odebrat, aby se brala v potaz jen funkční cesta.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

Takže na Debianu upravit /etc/ca-certificates.conf

!mozilla/DST_Ro­ot_CA_X3.crt

(přidat !) a pak

sudo update-ca-certificates

a hotovo?

Celkem jednoduše si to zkontrolujte třeba https://www.sslshopper.com/ssl-checker.html - zobrazí celý chain, který posílá server, tam by ten X3 certifikát být neměl.
Nebo z shellu:
openssl s_client -connect host:port -showcerts </dev/null|certtool -i|less
Mě k tomu dokopal Nagios, začal si stěžovat na expirující element 4.

Diky, jsem rad ze toto nekdo sleduje. Ty dotcene systemy jsou teda fakt stare, ale radsi jsem to na serverech proveril...

Koukal jsem na ten seznam. Co tedy to zpusobi napr. pro kombinaci:

1] openssl 1.0.1t+deb7u4 (debian 8)
2] openssl 1.0.1t+deb8u11 (debian 7)

Protoze v seznamu je uvadeno starsi nez 1.0.2, starsi nez debian 8.

BTW: Diky p. Krcmar za upozornujici clanek.

Oprava:
ad1] je debian 7, ne debian 8
ad2] je debian 8, ne debian 7

23. 9. 2021, 14:56 editováno autorem komentáře

Tenhle problém celkem efektivně ukazuje na jedno podstatné nebezpečí plynoucí z komplikovaných a navíc centralizovaných systémů: jakmile se někdo rozhodne, že pro _většinu_ něco stačí, i třetinová menšina přestane kohokoliv zajímat.

A to je principielně úplně a naprosto špatně.

Ale tady to není o tom, že většina obětovala třetinu. Ten termín byl jasně daný 21 let. Skoro až nechápu, že tak dlouho, když uvážím, jak rychle se celé IT mění, ale podle článku to tak je.

Když si koupím majonézu se zárukou dva týdny, tak taky nebudu za půlroku nadávat, že se mi v ledničce zkazila. Měla danou životnost a ta prostě skončila. To že tu majonézu použiji do bramborového salátu, nebo od toho certifikátu odvodím jiný certifikát, mi to datum expirace zázračně neprodlouží.

Mohl byste být konkrétnější? Já totiž vůbec nechápu, o čem váš komentář má být. Který centralizovaný systém máte na mysli? Kdo se rozhodl? Kdo je ta většina a kdo je ta třetinová menšina?

Právě mi přestala fungovat kombinace mobilní aplikace Bakaláři <=> server W2019 s IIS a Let's Encrypt certifikátem. Přístup přes web je v pořádku (stejně URL).

Řešením přechodu z již neplatného mezilehlého X3 na nový R3 je restart Windows serveru s IIS po vypršení X3. Jinak totiž nelze dosáhnout, aby IIS použil pro automatický výběr mezilehlého certifikátu R3 (protože R3 je vydán dříve, je považován Windows za "starší", přestože má delší životnost). Odstranění X3 z cert storu mi nepomohlo (a není nutné) - je tam v mezilehlých i kořenových.

Tímto se obejde problém, že aplikace Bakaláři na Androidu pravděpodobně interně používá staré openssl (místo systémového cert storu Androidu).

No a fakt se dneska v noci spustě lidí na linuxu, zejména ti, co mají ode mně starou SeaMonkey co nemá autoupgrade, rozbila půlka internetu :(

Nevíte prosím někdo o nějaké alternativě k Let's Encryptu, kde to vydrží co nejdýl?
Já dělám eshopy, tak jsem už rovnou varoval největšího klienta a zeptal se, jestli je ochotný event. platit za komerční certifikát...

A ještě něco, dá se detekovat ten problém v loogu Apache?

1. 10. 2021, 03:48 editováno autorem komentáře

Každý kořenový certifikát jednoho dne vyprší, mají platnost na 20 let. Let's Encrypt ten původní používal šest let, to není krátká doba. Komerční autorita to nespasí, jí také certifikát jednou expiruje. Pokud nebudete aktualizovat software, narazíte na to po čase znovu.

To chápu, svým kamarádům SeaMonkey upgraduju, ale v mezičase, než ty neupgradovatelný klienti zmizej, tak se mým zákaníkům, co mají ten let s'encrypt část návštěvíků nedostane na stránky, tak i kdyby to bylo na rok, nevíte, pane Krčmáři, kde bych měl šanci na co nejdelší odklad problému? Vzhledem k tomu, že let s'encrypt má i Seznam, tak Češi asi za pár týdnů upgradujou, ale co cizinci, který mi přijdou se starým mobilem na Obecní dům se poodívat co hrajou? Budou Němci taky pod tlakem upgradovat nebo je tam ten let s'encrypt míň rošířenej a budou si stěžovat, že jim web nechodí? Poznám nějakej error v logu apache, abych viděl, kolik jich bylo?

Pokud to mají pět let neaktualizované, tak mají smůlu a už se jim ta chyba objevuje. Včera původní kořen vypršel. V logu na serveru to vidět není, problém vzniká u klienta a server o něm nemá tušení. Rychlým řešením by samozřejmě bylo přejít na jinou autoritu se starším kořenem, který ještě platí. Ale tím se ten problém opět jen odloží, protože se to časem zopakuje.

Seznam sice má Let's Encrypt, ale používá nový kořenový certifikát ISRG Root X1, který je stále platný a noví (mladší než pět let) klienti ho znají, takže s tím není problém. Problém je skutečně jen s velmi starým a neaktualizovaným softwarem.

Děkuju moc za rady. Tak asi zkusím vyparsovat z logu ty starý user agenty a budu vidětl, že mají jen jeden request a pak nic. Ale jestli to bude pár procent uživatelů, tak třeba ten Obecňák radši zaplatí Digicert.

Jenže ten sh*t LE to udělal dost blbě. Ta nová "root CA" je podepsána tou starou mrtvou root CA, není opravdu kořenová.
Systémy, které jsou správně přísné, to odhalí, vbědí kam online sáhnout a nelíbí se jim to. LE jsou šumáci a neumí si udělat zcela novou nezávislou "root CA".
A je smutné, že webu typu root či seznam používají certifikáty LE.
Protože certifikát serveru není jen o šifrováí komunikace, ale i o důvěryhodnosti serveru. A LE má důvěruhodnost takřka zápornou... :D

Až na to, že to tak vůbec není. Existují dva různé certifikáty ISRG Root X1. Jeden je klasický kořenový, druhý je speciální křížově podepsaný expirovaným certifikátem DST. Ten první je úplně standardní kořen, jako mají všichni. Ten druhý je specialita jen kvůli starým Androidům a jejich nestandardnímu přístupu ke kořenům.

Takže to LE neudělal blbě, udělal to úplně normálně a navíc udělal jeden volitelný krok, pokud vás trápí staré Androidy. Pro zbytek světa si udělali „zcela novou nezávislou root CA“.