1

It's working now, see final 2 edits

There have been multiple instance recently for me where sha256sum is failing or a certificate cannot be verified. This has happened during use of wget, winetricks, and lutris. It has not happened with firefox at all.

I recently upgraded my openssl to 1.1.1c. I'm not sure if that's the cause or not.

Does anyone have any ideas on how I can fix my issue? Is there something extra I need to do after installing openssl? Or is there a way to check to make sure my certificates in /etc/ssl/certs are correct?

Edit 1:

Two examples with wget

wget  https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
--2019-06-25 18:56:33--  https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.184.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.184.133|:443... connected.
ERROR: cannot verify raw.githubusercontent.com's certificate, issued by ‘CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US’:
  Unable to locally verify the issuer's authority.
To connect to raw.githubusercontent.com insecurely, use `--no-check-certificate'.

and

wget https://dl.google.com/dl/android/studio/ide-zips/3.4.1.0/android-studio-ide-183.5522156-linux.tar.gz
--2019-06-25 19:08:19--  https://dl.google.com/dl/android/studio/ide-zips/3.4.1.0/android-studio-ide-183.5522156-linux.tar.gz
Resolving dl.google.com (dl.google.com)... 2607:f8b0:4009:807::200e, 172.217.9.78
Connecting to dl.google.com (dl.google.com)|2607:f8b0:4009:807::200e|:443... connected.
ERROR: cannot verify dl.google.com's certificate, issued by ‘CN=Google Internet Authority G3,O=Google Trust Services,C=US’:
  Unable to locally verify the issuer's authority.
To connect to dl.google.com insecurely, use `--no-check-certificate'.

edit 2:
Adding ca_certificate=/etc/ssl/certs/ca-certificates.crt to /etc/wgetrc fixed the issue with wget. I still have issues with other programs sometimes though. I'm wondering if some system link got removed when I updated openssl. I should mention I built openssl from source following the instructions on the openssl website. I did not use a package manager because the version I needed was not available there yet.

edit 3:
Here is an example of lutris failing to verify a certificate via python 3 urllib

2019-06-25 19:36:04,485: Error while completing task <function fetch_script at 0x7f0533fd1730>: Unable to connect to server https://lutris.net/api/installers/hearthstone-dx11-to-vulkan-dxvk: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)>
<class 'lutris.util.http.HTTPError'> Unable to connect to server https://lutris.net/api/installers/hearthstone-dx11-to-vulkan-dxvk: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)>
  File "/usr/lib/python3/dist-packages/lutris/util/jobs.py", line 30, in target
result = self.function(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/lutris/installer/interpreter.py", line 56, in fetch_script
request.get()
  File "/usr/lib/python3/dist-packages/lutris/util/http.py", line 81, in get
raise HTTPError("Unable to connect to server %s: %s" % (self.url, error))

Edit 4:
I got it working! I needed to add a system link from /etc/ssl/certs to /usr/local/ssl/certs This must have be deleted when I upgraded openssl
This also fixed the sha256sum issues I was having with winetricks

Edit 5: Actually, /usr/local/ssl/certs was never deleted. It just never existed. The old version of openssl I had looked for certs in /usr/lib/ssl/certs. After upgrading, it was looking for them in /usr/local/ssl/certs. I was able to check this with the command openssl version -d

1

Get the current directory used by OpenSSL:

openssl version -d

Copy all the old certs to the current directory. Usual old directory is /etc/ssl/certs:

cp -P /etc/ssl/certs /usr/local/ssl/certs
0

Sums don't expire or anything. They identify a set of data to a reasonably unique value. Someone [who you are trusting] had the files and created an identifier (hash/sum). That identifier was then stored so that when you retrieve the file at a later date, you can confirm it is the exact same file. You've download a file that simply does not match the original and you have to determine a course of action with an untrusted file. A prime example of sum use is when you visit the Ubuntu download page and you are shown how to verify the current image:

echo "2da6f8b5c65b71b040c5c510311eae1798545b8ba801c9b63e9e3fd3c0457cbe *ubuntu-19.04-desktop-amd64.iso" | shasum -a 256 --check

In this case, you are getting the validated sum securely (https), and then use it to verify the integrity of the ISO. This allows you to download the ISO from a mirror, and know it hasn't been tampered with.

The OpenSSL update is not impacting this.


As for certificate failures, a website may not keep their certificates up-to-date. Things are forgotten, and updates are not made. Certificates do expire by default, and take work to maintain, so it is possible that this is the case. If you can obtain the URL for the file, you can inspect the certificate yourself. Though this may seem innocent enough, an unmaintained server could have far larger issues, making file it is serving insecure.

The OpenSSL update is very unlikely to be causing this issue. The certs are most likely invalid. You can provide examples if you want more details.

  • 1
    I added two examples. Seems unlikely that github and google would have issues with their certificates. Are you able to download either of those with wget? – John Oberhauser Jun 26 '19 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.