30. května vypršel 20letý termín platnosti kořenového certifikátu , který k vytvoření křížového podpisu (cross-signed) v certifikátech jednoho z největších certifikačních úřadů Sectigo (Comodo). Křížový podpis umožnil zajištění kompatibility se zastaralými zařízeními, v jejichž úložištích kořenových certifikátů nebyl přidán nový kořenový certifikát USERTrust.
Teoreticky by vypršení platnosti kořenového certifikátu AddTrust mělo vést pouze k narušení kompatibility se zastaralými systémy (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 atd.), jelikož druhý kořenový certifikát použitý v křížovém podpisu zůstává platný a moderní prohlížeče jej zohledňují při ověřování řetězce důvěry. V praxi problémy s ověřováním křížového podpisu v neprohlížečových TLS klientech, včetně těch založených na OpenSSL 1.0.x a GnuTLS. Bezpečné připojení přestalo fungovat s chybovým hlášením o zastaralosti certifikátu, pokud server používá certifikát Sectigo, který je spojen řetězcem důvěry s kořenovým certifikátem AddTrust.
Pokud uživatelé moderních prohlížečů nezaznamenali zastaralost kořenového certifikátu AddTrust při zpracování křížově podepsaných certifikátů Sectigo, začaly se objevovat problémy v různých externích aplikacích a serverových zpracovatelích, což vedlo k mnoha infrastruktur, které používají šifrované komunikační kanály pro interakci mezi komponenty.
Například se objevily problémy s přístupem k některým repozitářům balíčků v Debianu a Ubuntu (apt začal vracet chybu při ověřování certifikátu), došlo k selháním při volání ze skriptů pomocí nástrojů „curl“ a „wget“, objevily se chyby při používání Git, funkčnost a , začaly v aplikacích Heroku, se připojovat klienti OpenLDAP, objevily se problémy se zasíláním e-mailů na servery SMTPS a SMTP se STARTTLS. Kromě toho se objevují problémy v různých Ruby-, PHP- a Python skriptech, které používají modul s http klientem. Mezi prohlížeči se problém Epiphany, ve kterém přestaly fungovat seznamy blokování reklamy.
Programy v jazyce Go nejsou tomuto problému náchylné, protože v Go je nabízena TLS.
, že problém se týká starších verzí distribucí (včetně Debianu 9, Ubuntu 16.04, ) v nichž jsou používány problematické větve OpenSSL, avšak problém také při použití balíčkovacího systému APT v aktuálních verzích Debianu 10 a Ubuntu 18.04/20.04, jelikož APT používá knihovnu GnuTLS. Podstatou problému je to, že mnohé TLS/SSL knihovny interpretují certifikát jako lineární řetězec, přičemž dle RFC 4158 certifikát může představovat orientovaný cyklický graf s několika uzly důvěry, které je třeba zohlednit. O tomto nedostatku v OpenSSL a GnuTLS . V OpenSSL byla problém vyřešena ve větvi 1.1.1, ale v zůstává .
Jako obchvat k vyřešení selhání se doporučuje odstranit z úložiště certifikát „AddTrust External CA Root“ (například odstranit z /etc/ca-certificates.conf a /etc/ssl/certs, a poté spustit „update-ca-certificates -f -v“), po čemž OpenSSL začne správně zpracovávat křížově podepsané certifikáty, kterých se účastní. Při použití balíčkovacího systému APT je na vlastní nebezpečí možné vypnout kontrolu certifikátů pro jednotlivé požadavky (například „apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false“).
Pro blokaci problému a se doporučuje přidat certifikát AddTrust na černou listinu:
důvěryhodná dump —filter „pkcs11:id=;type=cert“
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust extract
Ale tento způsob pro GnuTLS (například se stále objevuje chyba při ověřování certifikátu při spuštění utility wget).
Na straně serveru lze certifikátů v řetězci důvěry, které server posílá klientovi (pokud bude certifikát související s „AddTrust External CA Root“ odstraněn ze seznamu, ověření klientem proběhne úspěšně). Pro ověření a generování nového řetězce důvěry lze použít službu . Společnost Sectigo také alternativní křížově podepsaný prostřední certifikát „“, který bude platný do roku 2028 a umožní zachovat kompatibilitu se staršími verzemi OS.
Doplnění: Problém také souvisí s LibreSSL.
Zdroj: opennet.ru
