I’m getting CERTIFICATE_VERIFY_FAILED when e.g. using youtube-dl:
$ python2 /usr/local/bin/youtube-dl -s https://devstreaming-cdn.apple.com/videos/wwdc/2019/722l6blhn0efespfgx/722/722_hd_introducing_combine.mp4?dl=1
[generic] 722_hd_introducing_combine: Requesting header
WARNING: Could not send HEAD request to https://devstreaming-cdn.apple.com/videos/wwdc/2019/722l6blhn0efespfgx/722/722_hd_introducing_combine.mp4?dl=1: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>
[generic] 722_hd_introducing_combine: Downloading webpage
ERROR: Unable to download webpage: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)> (caused by URLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)'),))
Is there a certificate store that needs to be updated?
The resource is accessible on other systems.
Not sure if relevant:
$ apt show ca-certificates
Package: ca-certificates
Version: 20200601~deb9u1
Installed-Size: 380
Maintainer: Michael Shuler <michael@pbandjelly.org>
Architecture: all
Depends: openssl (>= 1.0.0), debconf (>= 0.5) | debconf-2.0
Enhances: openssl
Breaks: ca-certificates-java (<< 20121112+nmu1)
Description-en: Common CA certificates
Contains the certificate authorities shipped with Mozilla's browser to allow
SSL-based applications to check for the authenticity of SSL connections.
.
Please note that Debian can neither confirm nor deny whether the
certificate authorities whose certificates are included in this package
have in any way been audited for trustworthiness or RFC 3647 compliance.
Full responsibility to assess them belongs to the local system
administrator.
Description-md5: e867d2a359bea1800b5bff209fc65bd1
Multi-Arch: foreign
Tag: protocol::ssl, role::app-data, security::authentication
Section: misc
Priority: optional
Filename: pool/main/c/ca-certificates/ca-certificates_20200601~deb9u1_all.deb
Size: 159692
MD5sum: c91a91f7b3b5141d6e7eafc6eb2412f5
SHA256: d6fc9275de84bdf598b3703a50935dc69d2e80105317a44f6cba465c073f88f9
This is reported a few times on the youtube-dl GitHub issue tracker.
It’s possible a Python dependency is not installed; so while the certificates are present on the system, they can’t be used yet due to a missing Python package.
$ wget --server-response -O /dev/null https://devstreaming-cdn.apple.com
--2020-09-18 16:44:29-- https://devstreaming-cdn.apple.com/
Slår upp devstreaming-cdn.apple.com (devstreaming-cdn.apple.com)... 17.253.39.206, 17.253.39.202, 2a01:b740:a08:f000::3, ...
Ansluter till devstreaming-cdn.apple.com (devstreaming-cdn.apple.com)|17.253.39.206|:443... ansluten.
FEL: Certifikatet för "devstreaming-cdn.apple.com" är inte pålitligt.
FEL: Certifikatet för "devstreaming-cdn.apple.com" saknar en känd utfärdare.
Just making a note that the last command fails repeatedly on OSMC and succeeds repeatedly on macOS 10.14 and Ubuntu 18.04 from the same IP. Not sure if that is indicative of anything. I’ll try again tomorrow.
Version 20190110 of ca-certificates, which is the version on stable Debian buster, still works. I supect that’s the one Sam used.
I ran a strace on the curl command above and it produced these lines:
stat64("/etc/ssl/certs/116bf586.0", 0xffe4d300) = -1 ENOENT (No such file or directory)
stat64("/etc/ssl/certs/e3d20ab2.0", 0xffe4d300) = -1 ENOENT (No such file or directory)
The first hash points to GeoTrust_Primary_Certification_Authority_-_G2.pem
The second hash can’t be found.
The GeoTrust certificate doesn’t appear in the 20200601 package.
Furthermore, last time we had a major Debian-specific certificate
verification issue, we discovered that Debian is not actually capable
of restoring previously-removed certificates without manual user
intervention, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743339. That means
that even once these certificates are restored, users who have already
updated to the affected version of ca-certificates will suffer
permanently broken certificate verification unless they have found this
bug report and know to take manual intervention, because the
certificates will remain disabled locally.
It worked successfully on my Pi3, though that’s no guarantee of success on your box and, though it’s a downgrade, is the version currently provided for Debian Buster/stable. Debian -- Package Search Results -- ca-certificates
As I understood my quoted excerpt from the bug thread the issue is not with what certificates Debian provide, and that it won’t work even when the certificate is reintroduced into the package, since if that were the case then there would be no problem to speak of.
Do you mean that you received certificate errors, then downgraded, and the problem was gone? Or that you succeeded in downgrading the package?