youtube-dl: youtube-dl -U == ERROR: can't find the current version. Please try again later.

Checklist

I’m reporting a broken site support issue
I’ve verified that I’m running youtube-dl version 2020.11.12
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

[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-U', '-v']
[debug] Encodings: locale cp1252, fs mbcs, out cp437, pref cp1252
[debug] youtube-dl version 2020.11.12
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.19041
[debug] exe versions: none
[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\tmpwrmvn5tt\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\tmpwrmvn5tt\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.

Description

youtube-dl windows exe fails to update with -U flag.

Even after the github repo was restored this still fails. It appears from the debug trace that it is a SSL certificate issue. Interestingly if I manually go to the version URL https://yt-dl.org/update/LATEST_VERSION in my browser (latest windows chrome), I end up getting the 302 redirect, then I get the LATEST_VERSION file from github as expected. Likewise, if I use wget or curl from the command line I get the proper file with the current version. Only youtube-dl itself seems to have problems.

Perhaps an old version of the python SSL libraries is linked into the windows executable that doesn’t support TLS or something related to the SSL connection handshake / setup?

c:\>sha256sum youtube-dl.exe
97a8c9ac735911a722b5405861ede8a66b02635f00664c5199bd01fd3b67114f *youtube-dl.exe

c:\>youtube-dl --version
2020.11.12

c:\>youtube-dl -U
ERROR: can't find the current version. Please try again later.

About this issue

Original URL
State: open
Created 4 years ago
Comments: 23

Most upvoted comments

@jbrown123 : I had no issue whatsoever updating from v2020-11-12 to just released v2020-11-17:

<redacted>\youtube-dl>youtube-dl -U -v
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-U', '-v']
[debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253
[debug] youtube-dl version 2020.11.12
[debug] Python version 3.4.4 (CPython) - Windows-Vista-6.0.6003-SP2
[debug] exe versions: ffmpeg N-97309-g4e0cf81b49, ffprobe N-97309-g4e0cf81b49, p
hantomjs 2.1.1, rtmpdump 2.4
[debug] Proxy map: {}
Updating to version 2020.11.17 ...
Waiting for file handle to be closed ...

<redacted>\youtube-dl>pause
Press any key to continue . . . Updated youtube-dl to version 2020.11.17.

My hunch is your issue is a duplicate of https://github.com/ytdl-org/youtube-dl/issues/25541

yt-dl.org is sending the expired (30/05/2020) 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.

Possible duplicates are also https://github.com/ytdl-org/youtube-dl/issues/25469, https://github.com/ytdl-org/youtube-dl/issues/25476, https://github.com/ytdl-org/youtube-dl/issues/25491, https://github.com/ytdl-org/youtube-dl/issues/25536, https://github.com/ytdl-org/youtube-dl/issues/25537, https://github.com/ytdl-org/youtube-dl/issues/25539, https://github.com/ytdl-org/youtube-dl/issues/26168 and, most likely, many others…

That issue is caused as a combination of the following factors:

The 32-bit youtube-dl.exe binary officially released is built on Python 3.4.4, to satisfy Windows XP compatibility, at minimum (I’m not opposed to that, I myself am still on Vista SP2).
The Windows (32-bit) version of Python 3.4.4 bundles OpenSSL v1.0.2d for secure connections.
py344+OpenSSL v1.0.2d has a bug, fixed in later versions:

http://bugs.python.org/issue23476 https://bugs.python.org/issue36011

During the check-for-available-update process, youtube-dl has to connect securely with the yt-dl.org domain; https://whatsmychaincert.com/?yt-dl.org =>

yt-dl.org has a trusted chain containing an expired certificate. This chain will work with modern web browsers (they will use a chain to a different trusted root) but may fail with older clients, notably OpenSSL 1.0.x.

On May 30th 2020, an intermediate server certificate sent by yt-dl.org expired; if that certificate is STILL present in your Windows CA certstore, then youtube-dl.exe (on py344) will use that instead of creating a new certificate chain with the server, and will thus fail the secure connection; related issue: https://github.com/ytdl-org/youtube-dl/issues/25622; however, another reason for staying at py344 is that the python (official) module (py2exe) used to (cross-)compile the Windows binary doesn’t work on py3.5+ (but a fork does exist…).

TL;DR => Possible issue solving scenario: Navigate to your Windows CA certstore, by loading the certmgr.msc (certificates manager) snap-in; check on-line how to do that on your version of Windows:

crtmng

Expand Intermediate CAs -> Certificates, then sort stored intermediate certificates by Expiration Date; then proceed to delete ALL the expired ones (but be careful)! Restart your machine, for good measure… If your Windows setup is fairly new, it might lack needed certificates, so try visiting first yt-dl.org with a (native) browser that uses the Windows store, like IE and/or Edge; the browser will then download needed updated certs and place them in the store, making them available to youtube-dl.exe for future connections…

Best wishes 😄

Vangelis66 on Nov 18, 2020

If it’s that important to you, sure you can be “right”.

Now, for the rest of us … if you need your youtube-dl executable to work on windows, deleting expired certificates is a completely safe and functional work around.

jbrown123 on Dec 23, 2020

@Vangelis66 Thank you for the very detailed explanation and solution.

I can confirm that it was the intermediate certificate problem. I deleted several COMODO certs and a couple of USERFIRST certs that all expired 5/30/2020 and the problem immediately went away.

I strongly encourage that this get posted to the FAQ as a solution for this specific error message.

jbrown123 on Nov 17, 2020

it was because github repo was down. now it should work

pcislocked on Nov 17, 2020

Have you try to use youtube-dl -U --no-check-certificate to update?

MinkiNTN on Nov 16, 2020

I agree completely. I just suggest it as a simpler alternative than having people root around in their certificate store. Many people aren’t comfortable doing that and there’s a possibility of doing “damage” to your system that is difficult (though clearly not impossible) to recover from.

I think both should be offered with appropriate warnings. If not, I’m good with just telling people how to remove the offending certificates.

Thanks,

James

On Fri, Nov 20, 2020, at 6:28 PM, Vangelis66 wrote:

I also feel like the --no-check-certificate work-around is a good choice

Extra caution should be exercised whenever using the --no-check-certificate switch to bypass a broken certificate chain, because in essence it downgrades a secure (HTTPS) connection to a plain HTTP one, to allow for the client to connect to the remote server at all cost; it should only be used when one is absolutely certain that the destination server has not been otherwise compromised…

The CLI downloading tool wget has the same option, where associated security risks are explained in a more verbose fashion: https://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html

–no-check-certificate

Don’t check the server certificate against the available certificate authorities.

As of Wget 1.10, the default is to verify the server’s certificate against the recognized certificate authorities, breaking the SSL handshake and aborting the download if the verification fails. Although this provides more secure downloads, it does break interoperability with some sites that worked with previous Wget versions, particularly those using self-signed, expired, or otherwise invalid certificates. This option forces an “insecure” mode of operation that turns the certificate verification errors into warnings and allows you to proceed.

If you encounter “certificate verification” errors , you can use this option to bypass the verification and proceed with the download. Only use this option if you are otherwise convinced of the site’s authenticity, or if you really don’t care about the validity of its certificate. It is almost always a bad idea not to check the certificates when transmitting confidential or important data.

IOW, though this is an extremely unlikely scenario (but not unheard off…), imagine the case where yt-dl.org has been hacked; then the malicious actor (MITM) could redirect your --no-check-certificate insecure “check-for-update” request to somewhere else and/or serve you malicious code…

Just offered as food-for-thought…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ytdl-org/youtube-dl/issues/27003#issuecomment-731484564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE3QKPZHXARPWDE4PLANITSQ4JT3ANCNFSM4TXRVYOQ.

jbrown123 on Nov 21, 2020

I also feel like the --no-check-certificate work-around is a good choice

Extra caution should be exercised whenever using the --no-check-certificate switch to bypass a broken certificate chain, because in essence it downgrades a secure (HTTPS) connection to a plain HTTP one, to allow for the client to connect to the remote server at all cost; it should only be used when one is absolutely certain that the destination server has not been otherwise compromised…

The CLI downloading tool wget has the same option, where associated security risks are explained in a more verbose fashion: https://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html

–no-check-certificate

Don’t check the server certificate against the available certificate authorities.

As of Wget 1.10, the default is to verify the server’s certificate against the recognized certificate authorities, breaking the SSL handshake and aborting the download if the verification fails. Although this provides more secure downloads, it does break interoperability with some sites that worked with previous Wget versions, particularly those using self-signed, expired, or otherwise invalid certificates. This option forces an “insecure” mode of operation that turns the certificate verification errors into warnings and allows you to proceed.

If you encounter “certificate verification” errors <snipped>, you can use this option to bypass the verification and proceed with the download. Only use this option if you are otherwise convinced of the site’s authenticity, or if you really don’t care about the validity of its certificate. It is almost always a bad idea not to check the certificates when transmitting confidential or important data.

IOW, though this is an extremely unlikely scenario (but not unheard off…), imagine the case where yt-dl.org has been hacked; then the malicious actor (MITM) could redirect your --no-check-certificate insecure “check-for-update” request to somewhere else and/or serve you malicious code…

Just offered as food-for-thought…

Vangelis66 on Nov 21, 2020

@ValZapod wrote:

This is not a fix. a fix is to update openssl. (Python 3.8.2 has newer openssl.)

Well, it IS a fix in all intents and purposes, since the official devs team still wants to support Windows XP (py344 last to work there) & Windows Vista (py379 last to work there); py38x requires Win7 at minimum, plus the current stable python release, py39, requires Win8+; additionally, as I already pointed out, the team compiles the Windows executable via py2exe which, according to them, breaks in anything >py34x…

If you so wish, you can use the latest Python release compatible with your specific Windows version and compile youtube-dl.exe via, e.g. pyinstaller; or install the desired py version system-wide and use the zipped-executable release, youtube-dl, or, even, install youtube-dl via pip python module; it isn’t like there are no alternatives on Windows…

You do understand that you cannot delete the certificate?

… of course you CAN; and while you’re at it, one should also delete EXPIRED certificates inside Trusted Roots Certification Authorities -> Certificates (but also be extremely careful)!

Private key is still valid AND even not expired for code signing, and even after that if the binary is timestamped with secure server timestamp, thus signed by very old (until 2030) cert, the expiration of those AddTrust et al. certs will not mean expiration of signature?

What I discussed in my first comment in this issue involves intermediate server certificates sent by remote servers while negotiating secure connections between the server and the python client inside youtube-dl.exe; these are cached by Windows in the Intermediate CAs certstore (to alleviate the need of re-fetching them from the web) and can, of course, be removed at will!

These intermediate server certs are ONLY relevant in so far a secure connection needs be established, they have nothing to do with code-signing Windows executables (youtube-dl.exe isn’t code-signed, BTW…); I think you’ve probably mixed-up things here…

Vangelis66 on Nov 20, 2020

Still doesn’t work without using the --no-check-certificate flag.

Artanisx on Nov 17, 2020