emerge: WARNING:urllib3.connection:Certificate did not match

[Eggplants]

I'm seeing this when I do an emerge --sync:

Code: Select all

>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys via WKD ...WARNING:urllib3.connection:Certificate did not match expected hostname: gentoo.org. Certificate: {'subject': ((('countryName', 'US'),), (('stateOrProvinceName', 'California'),), (('localityName', 'San Francisco'),), (('organizationName', 'Fastly, Inc.'),), (('commonName', 'default.ssl.fastly.net'),)), 'issuer': ((('countryName', 'BE'),), (('organizationName', 'GlobalSign nv-sa'),), (('commonName', 'GlobalSign RSA OV SSL CA 2018'),)), 'version': 3, 'serialNumber': '729791010D5B03E97FD14F53', 'notBefore': 'Nov 18 16:26:16 2022 GMT', 'notAfter': 'Dec 20 16:26:15 2023 GMT', 'subjectAltName': (('DNS', 'default.ssl.fastly.net'), ('DNS', 'fastly.com'), ('DNS', '*.a.ssl.fastly.net'), ('DNS', '*.hosts.fastly.net'), ('DNS', '*.global.ssl.fastly.net'), ('DNS', '*.fastly.com'), ('DNS', 'a.ssl.fastly.net'), ('DNS', 'purge.fastly.net'), ('DNS', 'mirrors.fastly.net'), ('DNS', 'control.fastly.net'), ('DNS', 'tools.fastly.net')), 'OCSP': ('http://ocsp.globalsign.com/gsrsaovsslca2018',), 'caIssuers': ('http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt',), 'crlDistributionPoints': ('http://crl.globalsign.com/gsrsaovsslca2018.crl',)}

Anyone know what's going on? Is it safe to proceed with updates?

[greyhare]

Getting the same thing here for a couple days. It looks like the mirror doesn’t have Gentoo’s certificate, so the hosting provider is substituting their own, but I can’t be sure.

[soundrolf]

Same result today

Code: Select all

* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys via WKD ...WARNING:urllib3.connection:Certificate did not match expected hostname: gentoo.org. Certificate: {'subject': ((('countryName', 'US'),), (('stateOrProvinceName', 'California'),), (('localityName', 'San Francisco'),), (('organizationName', 'Fastly, Inc.'),), (('commonName', 'default.ssl.fastly.net'),)), 'issuer': ((('countryName', 'BE'),), (('organizationName', 'GlobalSign nv-sa'),), (('commonName', 'GlobalSign RSA OV SSL CA 2018'),)), 'version': 3, 'serialNumber': '729791010D5B03E97FD14F53', 'notBefore': 'Nov 18 16:26:16 2022 GMT', 'notAfter': 'Dec 20 16:26:15 2023 GMT', 'subjectAltName': (('DNS', 'default.ssl.fastly.net'), ('DNS', 'fastly.com'), ('DNS', '*.a.ssl.fastly.net'), ('DNS', '*.hosts.fastly.net'), ('DNS', '*.global.ssl.fastly.net'), ('DNS', '*.fastly.com'), ('DNS', 'a.ssl.fastly.net'), ('DNS', 'purge.fastly.net'), ('DNS', 'mirrors.fastly.net'), ('DNS', 'control.fastly.net'), ('DNS', 'tools.fastly.net')), 'OCSP': ('http://ocsp.globalsign.com/gsrsaovsslca2018',), 'caIssuers': ('http://secure.globalsign.com/cacert/gsrsaovsslca2018.crt',), 'crlDistributionPoints': ('http://crl.globalsign.com/gsrsaovsslca2018.crl',)}
                                                              [ !! ]

[mmogilvi]

I see the same thing, but only sometimes. Probably based on which DNS response (mirror) it happens to try first, each time.

I suspect it would be safe to follow a procedure:

• Control-C cancel the sync if you see that error.
• Re-start the sync
• When/if a sync doesn't give that message, let it finish, and then continue to update using with the result.

If you've already let it finish with the error, don't try to do anything that might partially execute ebuilds (possibly not even "emerge -p"), until you can follow the above procedure successfully (and watch out for the way emerge --sync typically aborts the sync if it detects that a timestamp file hasn't changed - that isn't a full sync). Or: If this is the "first" machine, and other machines on your LAN are set to sync to your first machine, you could try the procedure on those other machines (assuming they still get the keys from the external key servers), and if they work, then the "first" machine should also be OK.

It might be fairly safe to proceed with the update anyway, depending on exactly why emerge --sync decided to proceed with the sync despite the key update error.
FUTURE: If it were to explain its reasoning with a message like "key update failed; proceeding using previous keys", then I would be more confident that what it was doing was reasonably safe. (Or even better: fail, but have (and mention in the error message) a command-line option that could allow it to proceed using previous keys.) (However, I could still imagine an attack scenario where the old keys were leaked and replaced, and an attacker spoofs a key server that always fails (to prevent you from getting the new keys), and also spoofs a sync server with malware ebuilds/package manifests signed using the now-leaked old keys... (glossing over the plublic vs private parts of keys))

[Eggplants]

Looks like a bug has been filed on this:

https://bugs.gentoo.org/892976