yt-dl.org (YouTube-DL main Hosting Site) broken certificate

[tfabris]

Checklist

• I'm reporting a broken site support issue
• I've verified that I'm running youtube-dl version 2020.05.29
• I've checked that all provided URLs are alive and playable in a browser
• I've checked that all URLs and arguments with special characters are properly quoted or escaped
• I've searched the bugtracker for similar bug reports including closed ones
• I've read bugs section in FAQ

Verbose log

wget https://yt-dl.org/downloads/latest/youtube-dl

--2020-06-01 10:50:40--  https://yt-dl.org/downloads/latest/youtube-dl
Resolving yt-dl.org (yt-dl.org)... 95.143.172.170
Connecting to yt-dl.org (yt-dl.org)|95.143.172.170|:443... connected.
ERROR: cannot verify yt-dl.org's certificate, issued by ‘CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB’:
  Issued certificate has expired.
To connect to yt-dl.org insecurely, use `--no-check-certificate'.

Description

The main site that hosts the download of the YouTube-DL binary program itself, has an expired security certificate. The error message says:

 "ERROR: cannot verify yt-dl.org's certificate, issued by ‘CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB’:  Issued certificate has expired."

This started occurring on approximately Friday 2020-05-29, though I'm not certain exactly. You can reproduce the issue by typing this command at a bash prompt:

wget https://yt-dl.org/downloads/latest/youtube-dl

This problem affects me, because I do not want to download and use the latest version of YouTube-DL if there is a security risk on the site hosting it.

[dstftw]

yt-dl.org certificate is fine and not expired. You're hit by expired AddTrust External CA Root which is still on your CA store.

[tfabris]

@dstftw - Thank you so much for that information.

I'm having trouble understanding how to fix it on my end, though. I have some automation which grabs the latest version of YouTube-DL with wget, and the automation now fails. I don't want to add the --no-check-certificate command to the wget call because then it would be insecure for all certificate issues, not just this issue.

Ideally I'd like to fix the cert in my local CA store, but I'm having trouble knowing how to do it. Do you have any suggestions?

The site that you linked says that the certificate should already be fixed on the operating systems that I'm encountering the issue upon, but clearly it's not fixed there yet. For example, I encounter the error message on these operating systems when I issue the command wget https://yt-dl.org/downloads/latest/youtube-dl at a bash prompt:

• MacOS Catalina version 10.15.4 (19E287) - running OpenSSL version "LibreSSL 2.8.3"
• Linux 3.2.40 Only some videos download in a series from same catchup TV site #25426 SMP PREEMPT Tue May 12 04:38:00 CST 2020 i686 GNU/Linux synology_evansport_214play - Running OpenSSL version "OpenSSL 1.0.2u-fips 20 Dec 2019"

The latter one is the primary target for my automation, it's a Synology NAS running a version of GNU Linux, and it's the thing that's failing with the error. I see that others our there are having the same problem as me, for instance this reddit thread is about someone encountering the same thing (no solution there yet). I also see someone describing a fix here at this site, but there are some instructions there which don't apply to me, and so I can't use it as a guide. There is another page here which seems to have a simpler solution that I'll see if I can try.

Any other suggestions?

[cslycord]

The fix for me for this on debian linux was to:

1. edit /etc/ca-certificates.conf
2. comment out the line with "mozilla/AddTrust_External_Root.crt"
3. run update-ca-certificates -f -v

[tfabris]

@cslycord - Indeed this was the solution described at this web site, but in my case, the Synology machine that's encountering the problem doesn't have a "update-ca-certificates" command to run. So I can't implement that solution. I'm able to edit the file, but then I don't know how to update the CA certificates after editing the file.

I've been looking around for a command line parameter for OpenSSL that could do the same thing. For instance, issuing a command like "sudo openssl ca -updatedb", but that one gets an error, and I don't even know if that's barking up the right tree at all.

[cslycord]

@tfabris If your machine doesn't have an update-ca-certificates command, then you likely have to install the "ca-certificates" package.

[tfabris]

@cslycord - I'm don't think I can install that package on this Synology NAS. For example, "apt-get" doesn't exist on the system either. I have a hunch that there's gotta be a way to fix this from within OpenSSL without having to install extra packages, I just don't know what the procedure is.

(Update: https://community.synology.com/enu/forum/17/post/41047 )

[tfabris]

Or better yet, is there a way to work around the issue with the Bash command line when the file is being downloaded? Either with Wget or Curl or something else I have available that doesn't require a package install on that Synology system. My criteria would be:

• Doesn't completely shut off certificate checking. For example, wget with "--no-check-certificate" is not on the table.
• Skips the certificate checking for that particular known certificate problem while still enforcing the check for everything else.

I don't think this is do-able via simple command lines to wget or curl. Though I think I have an idea. The script that I'm running, which calls wget, could theoretically look at the error text coming back out of wget. If the text exactly matches that one exact "known issue" error message, with no other cert errors, then it could run wget a second time with the cert checking turned off. Doesn't solve the root of the problem, but works around the issue for my particular use-case.

[tfabris]

I've worked around this issue myself by doing the thing I suggested: In my script, I detect if it gets that exact specific error message, and if so, then it retries the download with cert checking turned off. Works for me for now.

[zhenyahacker]

Looks like there is a problem not only with wget under macos&linux (mentioned above), but with ytdl itself under windows. Since about last week, it can`t update itself due to same reasons.

C:\Youtube>"C:\Videoediting\livestreamer-v1.12.2-win32\youtube-dl.exe" --update --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--update', '--verbose']
[debug] Encodings: locale cp1251, fs mbcs, out cp866, pref cp1251
[debug] youtube-dl version 2020.05.29
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.18362
[debug] exe versions: ffmpeg git-2019-12-26-b0d0d7e
[debug] Proxy map: {}
Traceback (most recent call last):
  File "C:\Python\Python34\lib\urllib\request.py", line 1183, in do_open
  File "C:\Python\Python34\lib\http\client.py", line 1137, in request
  File "C:\Python\Python34\lib\http\client.py", line 1182, in _send_request
  File "C:\Python\Python34\lib\http\client.py", line 1133, in endheaders
  File "C:\Python\Python34\lib\http\client.py", line 963, in _send_output
  File "C:\Python\Python34\lib\http\client.py", line 898, in send
  File "C:\Python\Python34\lib\http\client.py", line 1287, in connect
  File "C:\Python\Python34\lib\ssl.py", line 362, in wrap_socket
  File "C:\Python\Python34\lib\ssl.py", line 580, in __init__
  File "C:\Python\Python34\lib\ssl.py", line 807, in do_handshake
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpxtvjzx45\build\youtube_dl\update.py", line 46, in update_self
  File "C:\Python\Python34\lib\urllib\request.py", line 464, in open
  File "C:\Python\Python34\lib\urllib\request.py", line 482, in _open
  File "C:\Python\Python34\lib\urllib\request.py", line 442, in _call_chain
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpxtvjzx45\build\youtube_dl\utils.py", line 2736, in https_open
  File "C:\Python\Python34\lib\urllib\request.py", line 1185, in do_open
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)>

ERROR: can't find the current version. Please try again later.

C:\Youtube>

[54ac]

Yeah, this also happens on Windows. I have to use --no-check-certificate with some websites and when checking for updates as a workaround.

[antdude]

I am also having this problem in my very old Debian Jessie v8 box:

$ youtube-dl -v -U
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', '-U']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2020.05.29
[debug] Python version 3.4.2 (CPython) - Linux-3.16.0-10-amd64-x86_64-with-debian-8.11
[debug] exe versions: ffmpeg 3.2.10-1, ffprobe 3.2.10-1, rtmpdump 2.4
[debug] Proxy map: {}
Traceback (most recent call last):
File "/usr/lib/python3.4/urllib/request.py", line 1174, in do_open
h.request(req.get_method(), req.selector, req.data, headers)
File "/usr/lib/python3.4/http/client.py", line 1142, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.4/http/client.py", line 1180, in _send_request
self.endheaders(body)
File "/usr/lib/python3.4/http/client.py", line 1138, in endheaders
self._send_output(message_body)
File "/usr/lib/python3.4/http/client.py", line 963, in _send_output
self.send(msg)
File "/usr/lib/python3.4/http/client.py", line 898, in send
self.connect()
File "/usr/lib/python3.4/http/client.py", line 1282, in connect
server_hostname=sni_hostname)
File "/usr/lib/python3.4/ssl.py", line 364, in wrap_socket
_context=self)
File "/usr/lib/python3.4/ssl.py", line 577, in init
self.do_handshake()
File "/usr/lib/python3.4/ssl.py", line 804, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/ant/bin/youtube-dl/youtube_dl/update.py", line 46, in update_self
newversion = opener.open(VERSION_URL).read().decode('utf-8').strip()
File "/usr/lib/python3.4/urllib/request.py", line 455, in open
response = self._open(req, data)
File "/usr/lib/python3.4/urllib/request.py", line 473, in _open
'_open', req)
File "/usr/lib/python3.4/urllib/request.py", line 433, in _call_chain
result = func(*args)
File "/home/ant/bin/youtube-dl/youtube_dl/utils.py", line 2736, in https_open
req, **kwargs)
File "/usr/lib/python3.4/urllib/request.py", line 1176, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)>

ERROR: can't find the current version. Please try again later.

My friend's Fedora v31 box had no problems. I assume it is very my old OS. :( I had no issues a few days ago too (5/29/2020 18:35:34 [LA, CA, USA time zone]).

[antdude]

FYI. #25491 (comment) for workaround worked. What does this mozilla/AddTrust_External_Root.crt affect for other sites and servers? I hope I can get it back soon.

Also, it would be nice if youtube-dl error did not say "ERROR: can't find the current version. Please try again later." which is misleading. It should say your OS needs an updated SSL cerificate or something.

[bughit]

@dstftw

expired AddTrust External CA Root which is still on your CA store.

Your server (yt-dl.org) is sending the expired intermediate cert (the last one in the below openssl output, "COMODO RSA Certification Authority"), which is what's causing validation to fail in python. Browsers are evidently smart enough to ignore it, and build an alternate chain, but the python client is not.

 echo q | openssl s_client -connect yt-dl.org:443 -CApath /usr/lib/ssl/certs -showcerts
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = yt-dl.org
verify return:1
---
Certificate chain
 0 s:OU = Domain Control Validated, OU = PositiveSSL, CN = yt-dl.org
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
-----BEGIN CERTIFICATE-----
MIIGPzCCBSegAwIBAgIQMZS8dhHXcUB+Xw/VCtIQ5DANBgkqhkiG9w0BAQsFADCB
kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV
BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0xODAyMDEwMDAwMDBaFw0yMTAyMTgyMzU5NTlaME0xITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxEjAQ
BgNVBAMTCXl0LWRsLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AJqSiXCTmmdFE2EStjBrXAd62YD5lFWdS55i1fJQjUzmk0SYTFFlM63pLl46J/Xv
KXKlQhz94+l4RpG+Y4/lTJpKQCvATiJ+YB3nd40Py08VbUhLRqafcXCY72JC5aoG
6CHOxzYpMITImNVkVCnDSbFoEEzu6cHHtK8YLDCbxbAt9Jxb6fd43tCJRxiJyC72
MBTtURIWL5dVzWFppHBUuHcmFyCjDXlWcnNWPK9M0h1KEAlv3my/vfvYCHWKOaVZ
0a9qpHZojhzIEhuGdg00QxBB9jd7CVwsQOYDOgfn2wEZCP1bHYlITFmWeEIxeBTd
cAiVkjsDYQScY/ll+EeB+ONzBJ2vjsSmMKY0YdYU5qKRZcZvzMVTY+TaKTQN9Bzv
MKauvZ1cCLEz/NeewTkGILXzHpkXl1rZwQN0oDEZJAG3rUn0L0t9FccA5zG/1uxV
cvYp//1DWulbC7/8KZQKrJN4DDxeXgFj7gaYptrxdxY8N9jWTBWORflky9r5YT8J
gAqLMPS8GpBOCUOsaMpAu92GZsxKM46Qy0MDv3xXYxL7GQ4L/9O9neENv3mOVAS9
4c5P8w5x5vTQ+mpeS44Upij0eYbU+Axp6/tZGA2QMwBv9HPpX+1ez59kAC/MBLQs
0t6gu/pc0k4d8KmvY3nc0eS7yLitOOzoub2dzMM38SutAgMBAAGjggHVMIIB0TAf
BgNVHSMEGDAWgBSQr2o6lFoL2JDqElZz30O0Oija5zAdBgNVHQ4EFgQUq7j9Gob+
eMDqG4+pwvoyOAI1eP4wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYBBAGy
MQECAgcwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNvbS9D
UFMwCAYGZ4EMAQIBMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5j
cmwwgYUGCCsGAQUFBwEBBHkwdzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5jb21v
ZG9jYS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNB
LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCMGA1Ud
EQQcMBqCCXl0LWRsLm9yZ4INd3d3Lnl0LWRsLm9yZzANBgkqhkiG9w0BAQsFAAOC
AQEAUMCK4vJAeMvNOGEQp1fcI4PvQ1sGLaPbawVkEwCOA3IW5hfQG7xObxI9qywv
7xweXLlF9YB01j/ovb7Oxg11iLsdJ4ESo6pkqiUsAsLRQPSp/3MuRMUgzLqH1Hh0
BX3yBAUGnVxZV/jORpUjlKDQLrpIdWTIfuYhQzH2uuBN2iqjzQBb7biahX3naNjl
Qu1MGeJhjO4aKQMXVLbs0MJ7QGGqr+t1VyjjOluy6nftsd6EJdZ44hnOfOArL9Hm
dLDQ1FExCPwvZyvVTHaCk4PcbuYF+DecvaRkeDejEYxMza2ULbK6AiaLRem6G/4M
TdC1MRnuYlnaCkcYVVyYu1ejGw==
-----END CERTIFICATE-----
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh
bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh
bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0
Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6
ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51
UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n
c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY
MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz
30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG
BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB
AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E
T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v
ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p
mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/
e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps
P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY
dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc
2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG
V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4
HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX
j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII
0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap
lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf
+AZxAeKCINT+b72x
-----END CERTIFICATE-----
 2 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow
gYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYD
VQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkq
hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkehUktIKVrGsDSTdxc9EZ3SZKzejfSNw
AHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/EZfH9IY+Cvo+XPmT5jR6
2RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0NyvQwA1onr
ayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt
4Q08RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIq
m1y9TBsoilwie7SrmNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/
vOldxJuvRZnio1oktLqpVj3Pb6r/SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT
8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPevtQ0iTMARgexWO/bTouJbt7IE
IlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w0MOiqiwhqkfO
KJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO
GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/
s1Hap0flhFMCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9
MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVy
bmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAGS/g/FfmoXQ
zbihKVcN6Fr30ek+8nYEbvFScLsePP9NDXRqzIGCJdPDoCpdTPW6i6FtxFQJdcfj
Jw5dhHk3QBN39bSsHNA7qxcS1u80GH4r6XnTq1dFDK8o+tDb5VCViLvfhVdpfZLY
Uspzgb8c8+a4bmYRBbMelC1/kZWSWfFMzqORcUx8Rww7Cxn2obFshj5cqsQugsv5
B5a6SE2Q8pTIqXOi6wZ7I53eovNNVZ96YUWYGGjHXkBrI/V5eu+MtWuLt29G9Hvx
PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR
pu/xO28QOG8=
-----END CERTIFICATE-----

[bughit]

@dstftw

you have to stop sending the expired intermediate cert because your own python client can't handle it

https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration

Fortunately, modern clients with well-written certificate validators (this includes all mainstream web browsers) won't have a problem with the expiration. Since they trust the USERTrust RSA Certification Authority root, they will build a chain to that root and ignore the fact that the server sent an expired intermediate certificate.

Other clients, notably anything using OpenSSL 1.0.x or GnuTLS, will have a problem. Even if these clients trust the USERTrust RSA Certification Authority root, and could build a chain to it if they wanted, they'll end up building a chain to AddTrust External CA Root instead, causing the certificate validation to fail with an expired certificate error.

Fixing this problem as a server operator
Basically, you need to remove the intermediate certificate issued by AddTrust External CA Root from your certificate chain.

[Seblor]

I'd argue this issue should be reopened. As it is, I cannot install youtube-dl using the curl or wget commands provided in the download page.

With Curl:

curl: (60) SSL certificate problem: certificate has expired

With wget:

ERROR: The certificate of 'yt-dl.org' is not trusted.
ERROR: The certificate of 'yt-dl.org' has expired.

A workaround that every user needs to apply is not a fix.

[ariel-co]

I do think it's the bundled Python (urllib?). Even after disabling the AddTrust Root CA certs via certmgr, I get CERTIFICATE_VERIFY_FAILED.

Now, building from source in Windows:

> pyinstaller youtube_dl\__main__.py --onefile --name youtube-dl
216 INFO: PyInstaller: 3.6
216 INFO: Python: 3.7.8 (conda)
216 INFO: Platform: Windows-10-10.0.19041-SP0
[...]
46230 INFO: Appending archive to EXE D:\src\youtube-dl-win\youtube-dl-master\dist\youtube-dl.exe
46276 INFO: Building EXE from EXE-00.toc completed successfully.

> .\dist\youtube-dl.exe -vv -U
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-vv', '-U']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, pref cp1252
[debug] youtube-dl version 2020.06.16.1
[debug] Python version 3.7.8 (CPython) - Windows-10-10.0.19041
[debug] exe versions: none
[debug] Proxy map: {}
youtube-dl is up-to-date (2020.06.16.1)

[RingoTheDog]

This worked for me on Windows hopefully it will help someone else:
(I got this info from: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020)

To get the new AddTrust Certificate so YouTube-DL can update again, in internet explorer to go to: http://testsites.test.certificatetest.com/ and click on https://addtrustexternalcaroot.test.certificatetest.com/
..then test your certificates with the links at the bottom of the page.

Here is the Verbose output before and after updating the certificate:

`

youtube-dl.py -v -U
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', '-U']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, pref cp1252
[debug] youtube-dl version 2020.07.28
[debug] Python version 3.8.5 (CPython) - Windows-2012ServerR2-6.3.9600-SP0
[debug] exe versions: ffmpeg N-71727-g46778ab, ffprobe N-87871-g7480f232d2, rtmp
dump 2.4
[debug] Proxy map: {}
Traceback (most recent call last):
File "C:\Program Files\Python38\lib\urllib\request.py", line 1350, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
File "C:\Program Files\Python38\lib\http\client.py", line 1255, in request
self._send_request(method, url, body, headers, encode_chunked)
File "C:\Program Files\Python38\lib\http\client.py", line 1301, in _send_reque
st
self.endheaders(body, encode_chunked=encode_chunked)
File "C:\Program Files\Python38\lib\http\client.py", line 1250, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "C:\Program Files\Python38\lib\http\client.py", line 1010, in _send_outpu
t
self.send(msg)
File "C:\Program Files\Python38\lib\http\client.py", line 950, in send
self.connect()
File "C:\Program Files\Python38\lib\http\client.py", line 1424, in connect
self.sock = self._context.wrap_socket(self.sock,
File "C:\Program Files\Python38\lib\ssl.py", line 500, in wrap_socket
return self.sslsocket_class._create(
File "C:\Program Files\Python38\lib\ssl.py", line 1040, in _create
self.do_handshake()
File "C:\Program Files\Python38\lib\ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verif
y failed: certificate has expired (_ssl.c:1123)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Transmogrifier\youtube-dl.py\youtube_dl\update.py", line 46, in updat
e_self
newversion = opener.open(VERSION_URL).read().decode('utf-8').strip()
File "C:\Program Files\Python38\lib\urllib\request.py", line 525, in open
response = self._open(req, data)
File "C:\Program Files\Python38\lib\urllib\request.py", line 542, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
File "C:\Program Files\Python38\lib\urllib\request.py", line 502, in _call_cha
in
result = func(*args)
File "C:\Transmogrifier\youtube-dl.py\youtube_dl\utils.py", line 2734, in http
s_open
return self.do_open(functools.partial(
File "C:\Program Files\Python38\lib\urllib\request.py", line 1353, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certifica
te verify failed: certificate has expired (_ssl.c:1123)>
ERROR: can't find the current version. Please try again later.

youtube-dl.py -v -U
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', '-U']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, pref cp1252
[debug] youtube-dl version 2020.07.28
[debug] Python version 3.8.5 (CPython) - Windows-2012ServerR2-6.3.9600-SP0
[debug] exe versions: ffmpeg N-71727-g46778ab, ffprobe N-87871-g7480f232d2, rtmp
dump 2.4
[debug] Proxy map: {}
youtube-dl is up-to-date (2020.07.28)
`

[catalano]

Any update on this? On a brand new installation of Mojave using the curl command from the download page in Terminal yields the certificate error.

[brokenzeus]

Same problem on mac...

[mayeaux]

+1 what's going on? :| kind of a big issue for this cert thing to still be throwing errors

[vbertola]

Same problem on my raspi (Raspbian Jessie), even after running update-ca-certificates. I worked around this by using the wget download line with --no-check-certificate, but that's not a real fix - please make sure that you use a certificate which is valid out of the box for all OSes including old ones, without requiring users to mess up with CAs.

[mayeaux]

Same problem on my raspi (Raspbian Jessie), even after running update-ca-certificates. I worked around this by using the wget download line with --no-check-certificate, but that's not a real fix - please make sure that you use a certificate which is valid out of the box for all OSes including old ones, without requiring users to mess up with CAs.

Amen. Can this get re-opened? It's certainly still an issue.

[technimad]

This is still a problem on macOS 10.14:

$./youtube-dl --version
2020.06.06
$ ./youtube-dl -v -U
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'-v', u'-U']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2020.06.06
[debug] Python version 2.7.16 (CPython) - Darwin-18.7.0-x86_64-i386-64bit
[debug] exe versions: ffmpeg 4.2.3-tessus, ffprobe 4.2.3-tessus
[debug] Proxy map: {}
Traceback (most recent call last):
  File "./youtube-dl/youtube_dl/update.py", line 46, in update_self
    newversion = opener.open(VERSION_URL).read().decode('utf-8').strip()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 429, in open
    response = self._open(req, data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 447, in _open
    '_open', req)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "./youtube-dl/youtube_dl/utils.py", line 2736, in https_open
    req, **kwargs)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1198, in do_open
    raise URLError(err)
URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)>

ERROR: can't find the current version. Please try again later.

Please reopen, or provide a clear work around.