Päävarmenteen 30 vuoden voimassaoloaika päättyi 20. toukokuuta Joka luoda ristiin allekirjoitettuja varmenteita yhdeltä suurimmista varmenneviranomaisista Sectigo (Comodo). Ristiallekirjoitus salli yhteensopivuuden vanhojen laitteiden kanssa, joiden juurivarmennesäilöön ei ollut lisätty uutta USERTRust-juurivarmennetta.
Teoriassa AddTrust-juurivarmenteen lopettamisen pitäisi johtaa vain yhteensopivuuden rikkomiseen vanhojen järjestelmien kanssa (Android 2.3, Windows XP, Mac OS X 10.11, iOS 9 jne.), koska toinen ristiallekirjoituksessa käytetty juurivarmenne säilyy. kelvolliset ja nykyaikaiset selaimet ottavat sen huomioon tarkastellessaan luottamusketjua. Käytännössä Ongelmia ristiinallekirjoituksen vahvistamisessa muissa TLS-asiakkaissa, jotka eivät ole selaimia, mukaan lukien OpenSSL 1.0.x- ja GnuTLS-pohjaiset. Suojattua yhteyttä ei enää muodosteta, ja varmenteen vanhentumisesta ilmoittaa virhe, jos palvelin käyttää Sectigo-varmennetta, joka on linkitetty luottamusketjulla AddTrust-juurivarmenteeseen.
Jos nykyaikaisten selainten käyttäjät eivät huomanneet AddTrust-juurivarmenteen vanhentumista käsitellessään ristiin allekirjoitettuja Sectigo-varmenteita, ongelmia alkoi ilmetä useissa kolmannen osapuolen sovelluksissa ja palvelinpuolen käsittelijöissä, mikä johti monet infrastruktuurit, jotka käyttävät salattuja viestintäkanavia komponenttien väliseen vuorovaikutukseen.
Niitä oli esimerkiksi pääsyn joihinkin Debianin ja Ubuntun pakettivarastoihin (apt alkoi tuottaa varmenteen vahvistusvirhettä), "curl"- ja "wget"-apuohjelmia käyttävien komentosarjojen pyynnöt alkoivat epäonnistua, virheitä havaittiin käytettäessä Gitiä, Roku-suoratoistoalusta toimii, käsittelijöitä ei enää kutsuta и , alkoi Heroku-sovelluksissa, OpenLDAP-asiakkaat muodostavat yhteyden, havaitaan ongelmia sähköpostin lähettämisessä SMTPS:ään ja SMTP-palvelimiin STARTTLS:llä. Lisäksi ongelmia havaitaan erilaisissa Ruby-, PHP- ja Python-skripteissä, jotka käyttävät moduulia http-asiakkaan kanssa. Selain ongelma Epiphany, joka lopetti mainosten estoluetteloiden lataamisen.
Tämä ongelma ei vaikuta Go-ohjelmiin, koska Go tarjoaa TLS.
että ongelma koskee vanhempia jakelujulkaisuja (mukaan lukien Debian 9, Ubuntu 16.04, ), jotka käyttävät ongelmallisia OpenSSL-haaroja, mutta ongelma myös silloin, kun APT-paketinhallinta on käynnissä Debian 10:n ja Ubuntu 18.04/20.04:n nykyisissä julkaisuissa, koska APT käyttää GnuTLS-kirjastoa. Ongelman ydin on, että monet TLS/SSL-kirjastot jäsentävät varmenteen lineaarisena ketjuna, kun taas RFC 4158:n mukaan varmenne voi edustaa suunnattua hajautettua ympyräkaaviota, jossa on useita huomioitavia ankkureita, jotka on otettava huomioon. Tietoja tästä OpenSSL- ja GnuTLS-virheestä . OpenSSL:ssä ongelma korjattiin haarassa 1.1.1 ja in jäännökset .
Kiertokeinona suositellaan "AddTrust External CA Root" -sertifikaatin poistamista järjestelmävarastosta (poista esimerkiksi tiedostoista /etc/ca-certificates.conf ja /etc/ssl/certs ja suorita sitten "update-ca". -sertifikaatit -f -v"), jonka jälkeen OpenSSL alkaa normaalisti käsitellä ristiinallekirjoitettuja varmenteita osallistumallaan. Kun käytät APT-paketinhallintaa, voit poistaa yksittäisten pyyntöjen varmenteen vahvistamisen käytöstä omalla vastuullasi (esimerkiksi "apt-get update -o Acquire::https::download.jitsi.org::Verify-Peer=false"). .
Voit estää ongelman и AddTrust-sertifikaatin lisäämistä mustalle listalle ehdotetaan:
trust dump —filter «pkcs11:id=%AD%BD%98%7A%34%B4%26%F7%FA%C4%26%54%EF%03%BD%E0%24%CB%54%1A;type=cert» \
> /etc/pki/ca-trust/source/blacklist/addtrust-external-root.p11-kit
update-ca-trust-ote
Mutta tämä menetelmä GnuTLS:lle (esimerkiksi varmenteen vahvistusvirhe näkyy edelleen, kun wget-apuohjelma suoritetaan).
Palvelimen puolella voit palvelimen asiakkaalle lähettämän luottamusketjun varmenteiden luettelointi (jos "AddTrust External CA Root" -sovellukseen liittyvä varmenne poistetaan luettelosta, asiakkaan vahvistus onnistuu). Voit tarkistaa ja luoda uuden luottamusketjun käyttämällä palvelua . Sectigo myös vaihtoehtoinen ristiin allekirjoitettu välitodistus "", joka on voimassa vuoteen 2028 asti ja säilyttää yhteensopivuuden vanhojen käyttöjärjestelmän versioiden kanssa.
Lisäys: Ongelma myös LibreSSL:ssä.
Lähde: opennet.ru