Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: OndraNi 28. 06. 2022, 22:11:27
-
Ahoj, mám problém s ubuntu mirrorem od cz.nic přes https.
W: Failed to fetch https://cz.archive.ubuntu.com/ubuntu/dists/jammy/InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 2001:1488:ffff::63 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.
Ostatní mirrory mi fungují vpořádku. Zkoušel jsem reinstalovat ca-certificates, ale nepmohlo.
-
Zkouším to v Debianu i Ubuntu, koukám na certifikáty a připadá mi to všechno v pořádku. Buď už to tedy mezi tím opravili nebo je rozbitá ta instalace Ubuntu, na které to zkoušíš ty. Zkus to stáhnout ručně pomocí curl -v a podívat se, co se mu přesně nezdá.
-
Zdravím, jen takový nápad - pokud by v použitých certifikátech bylo LetsEncrypt, mohl by u staršího systému (v roli klienta) být problém s "dvojakostí" podpisu kořene LetsEncrypt a správném rozpoznání důvěry. Stručně - mohlo by pomoci na tvém Ubuntu poeditovat soubor /etc/ca-certificates.conf - najít řádek s /DST_Root_CA_X3.crt a zaremovat ho na tvar !mozilla/DST_Root_CA_X3.crt a pak dát update-ca-certificates, to vše samozřejmě jako root či přes sudo. A pak zkusit znovu apt-get update atd.
-
Podle URL jde o Ubuntu Jammy, tedy 22.04. To není staré…
Zkoušel jsem https://www.ssllabs.com/ssltest/analyze.html?d=cz.archive.ubuntu.com&s=2001:1488:ffff:0:0:0:0:63 a je tam „Chain issues: Incorrect order, Extra certs“. Nevidím ale, proč by se to mělo chovat u každého jinak.
-
Udělal jsem úplně čistou instalaci Ubuntu 22.04 ve VM a stejný problém. Ve starších 20.04 funguje bez problémů. Musí teda být problém na straně nic.cz a novější verze systému.
curl normálně jde bez žádných chyb
DST_Root_CA_X3.crt v /etc/ca-certificates.conf není
Ostatní mirrory fungují, mají dobré skóre na ssllabs
https://www.ssllabs.com/ssltest/analyze.html?d=mirror.dkm.cz&s=86.49.49.49
https://www.ssllabs.com/ssltest/analyze.html?d=ftp.sh.cvut.cz&s=147.32.127.196
-
Mám už několik měsíců stejný problém na několika strojích s Ubuntu 22.04. Zatím jsem to vždy řešil změnou mirroru na ten od IT4Innovations, který funguje v pořádku.
Zkoušel jsem https://www.ssllabs.com/ssltest/analyze.html?d=cz.archive.ubuntu.com&s=2001:1488:ffff:0:0:0:0:63 a je tam „Chain issues: Incorrect order, Extra certs“. Nevidím ale, proč by se to mělo chovat u každého jinak.
Podle https://stackoverflow.com/a/52858001/6440524 (https://stackoverflow.com/a/52858001/6440524) je to špatně. Může to být zdrojem chyby?
Jestli ano, dá se někde sehnat kontakt na někoho v CZ.NICu, kdo to má na starosti? Je trošku blbé, aby hlavní a výchozí český mirror měl nefunkční HTTPS na APT interface.
-
Ano, je tam zmatek v řetězci certifikátů, viz výpis z OpenSSL:
Certificate chain
0 s:CN = mirror-r-01.nic.cz
i:C = US, O = Let's Encrypt, CN = R3
1 s:CN = mirror-r-01.nic.cz
i:C = US, O = Let's Encrypt, CN = R3
2 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
4 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
Certifikáty číslo 0 a 4 tam být nemají. Poslal jsem to e-mailem na podporu CZ.NIC. Když už ten problém trvá pár měsíců, rychlost e-mailu by měla stačit :-)
-
Nedaří se mi to nijak reprodukovat, ale přeposlal jsem info a odkaz na snad platný kontakt správců z CZ.NICu. Snad se jim to podaří vyřešit.
-
mam starsi, avsak (skoro - max tyden, dva od posledniho update) aktualizovane 22.04 na vpsfree.cz a chybu nevidim:
wget https://cz.archive.ubuntu.com/ubuntu/dists/jammy/InRelease
--2023-02-24 09:38:24-- https://cz.archive.ubuntu.com/ubuntu/dists/jammy/InRelease
Resolving cz.archive.ubuntu.com (cz.archive.ubuntu.com)... 2001:1488:ffff::63, 217.31.202.63
Connecting to cz.archive.ubuntu.com (cz.archive.ubuntu.com)|2001:1488:ffff::63|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 270087 (264K)
Saving to: ‘InRelease’
InRelease 100%[===========================================================>] 263.76K --.-KB/s in 0.002s
2023-02-24 09:38:24 (113 MB/s) - ‘InRelease’ saved [270087/270087]
-
To, že se nějkaý software srovná s chybným seznamem certifikátů, neznamená, že tam ta chyba není. OpenSSL i SSL Report shodně ukazují stejné chyby v řetězci certifikátů (jsou tam 2 certifikáty navíc, problematický je hlavně ten zopakovaný certifikát serveru, který přerušuje hned na začátku řetězec důvěryhodnosti certifikátů).
-
Před obědem mi dorazila odpověď od správců z CZ.NICu, a Qualys SSL Labs už nic nenamítá.
Dobrý den,
duplicitní certifikát z chainu jsme odstranili. Snad by někteří uživatelé už neměli mít problém.
Děkuji za upozornění!
Prosím, kdo jste ten problém pozoroval, tak ověřte, jestli už je to v pořádku.
-
Před obědem mi dorazila odpověď od správců z CZ.NICu, a Qualys SSL Labs už nic nenamítá.
Dobrý den,
duplicitní certifikát z chainu jsme odstranili. Snad by někteří uživatelé už neměli mít problém.
Děkuji za upozornění!
Prosím, kdo jste ten problém pozoroval, tak ověřte, jestli už je to v pořádku.
Ano, také jsem dostal odpověď:
Dobrý den,
děkujeme za upozornění. Chybný chain jsme opravili.
S pozdravem.
Podle OpenSSL už jsou tam jen 3 certifikáty, které na sebe navazují správně:
Certificate chain
0 s:CN = mirror-r-01.nic.cz
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
Formálně by to tedy mělo být správně, teď je na uživatelích Ubuntu ověřit, zda tohle opravdu byla ta příčina.
-
Já jsem to dneska do CZ.NIC nahlásil a očividně to rychle řešili.
-
Prosím, kdo jste ten problém pozoroval, tak ověřte, jestli už je to v pořádku.
Dobrý den,
ano, mirror již nyní funguje bez problémů. Děkuji všem zúčastněným za nahlášení a CZ.NIC za rychlou opravu :))
--
Omlouvám se za prodlevu, najednou mi přestaly chodit notifikace.
-
Poslal jsem to e-mailem na podporu CZ.NIC. Když už ten problém trvá pár měsíců, rychlost e-mailu by měla stačit :-)
E-mail umí být i rychlý, doručení do 5s, při push notifikacích to MUA se dozví hned. Akorát ne všichni mail.provideři umí IDLE (u seznam.cz mi to nešlo). Za druhý někdy to doručení není v řádku vteřin, ale minut, vázne to.
Nemyslím, že problém je vyřešen všude. Někdy před 2 měsíci(hodně přibližně) to začlo zlobit, jsem zpozoroval jsem invalid certificate
depth=0 C = CZ, ST = "Praha, Hlavn\C3\AD m\C4\9Bsto", O = "CESNET, z\C3\A1jmov\C3\A9 sdru\C5\BEen\C3\AD pr\C3\A1vnick\C3\BDch osob",
CN = speedtest.cesnet.cz
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CZ, ST = "Praha, Hlavn\C3\AD m\C4\9Bsto", O = "CESNET, z\C3\A1jmov\C3\A9 sdru\C5\BEen\C3\AD pr\C3\A1vnick\C3\BDch osob",
CN = speedtest.cesnet.cz
verify error:num=21:unable to verify the first certificate
verify return:1
DONE
notBefore=Feb 21 00:00:00 2023 GMT
notAfter=Feb 21 23:59:59 2024 GMTTomu odpovídá Feb 21 a myslím, že to spolu souvisí i když to v názvu nemá NIC
-
Nemyslím, že problém je vyřešen všude. Někdy před 2 měsíci(hodně přibližně) to začlo zlobit, jsem zpozoroval jsem invalid certificate speedtest.cesnet.cz Tomu odpovídá Feb 21 a myslím, že to spolu souvisí i když to v názvu nemá NIC
Je to jiný web, jiný provozovatel webu, jiný problém… Doufám, že sem teď nebudete psát všechny problémy s certifikáty, na které narazíte.