QNAP and expired Let's Encrypt root certificates
17 Apr 2023We recently received an email into the blisshq.com support inbox…
I’ve been using Bliss on my QNAP TS-219P II for years (currently running 4.3.3.2211).
I just uninstalled Bliss (2022 version but can’t remember exactly) and attempted to install the latest 2023 version but for whatever reason I am unable to complete the install (it fails at 4%-5%). Reinstalling older versions of the app (that I found on my computer) also fail even though I had them all installed at one point.
Trying the install myself, on our test TS-251 NAS, I got the same behaviour.
Checking the system logs on the QNAP I could see a little more detail:
WGET_URL =
WGET_FILENAME =
SYS_PUBLIC_PATH = /share/MD0_DATA/Public
There was a problem downloading from the official download link,
Alternatively, you may download this file manually and place it in the 'public' shared folder.
which was "
Fatal Error Fetching bliss install files
Those empty WGET_ variables seemed suspicious. We publish the source code for the QNAP installer in Github, so it was easy to quickly review what was going on.
WGET_URL is actually the URL the installer uses to download the bliss installer from the blisshq.com website. It’s populated by GETting http://www.blisshq.com/app/latest-linux-version which returns a URL to the latest version. Only here, the URL appeared to be empty.
So I dropped to the command line of the QNAP. I ssh’d in and:
[~] # wget -qO- http://www.blisshq.com/app/latest-linux-version
[~] #
Ok; no result. That’s not what we want, but it’s consistent with the logging from the installer where the WGET_ variables were empty.
I changed the wget command to be more verbose:
[~] # wget -O- https://www.blisshq.com/app/latest-linux-version
--2023-04-17 10:40:43-- https://www.blisshq.com/app/latest-linux-version
Resolving www.blisshq.com... 172.67.217.150, 104.21.75.85, 2606:4700:3032::ac43:d996, ...
Connecting to www.blisshq.com|172.67.217.150|:443... connected.
ERROR: cannot verify www.blisshq.com's certificate, issued by ‘CN=R3,O=Let's Encrypt,C=US’:
Issued certificate has expired.
To connect to www.blisshq.com insecurely, use `--no-check-certificate'.
[~] #
A-ha! wget thinks the certificate for blisshq.com is expired.
So I tried this from my workstation (not the QNAP):
$ openssl s_client -servername www.blisshq.com -connect www.blisshq.com:443 | openssl x509 -noout -dates
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.blisshq.com
verify return:1
notBefore=Mar 27 00:16:11 2023 GMT
notAfter=Jun 25 00:16:10 2023 GMT
That’s strange - everything seems fine. Let’s run it on the QNAP:
[~] # openssl s_client -servername www.blisshq.com -connect www.blisshq.com:443 | openssl x509 -noout -dates
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
notAfter=Sep 30 18:14:03 2024 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
notAfter=Sep 15 16:00:00 2025 GMT
verify return:1
depth=0 CN = *.blisshq.com
notAfter=Jun 25 00:16:10 2023 GMT
verify return:1
notBefore=Mar 27 00:16:11 2023 GMT
notAfter=Jun 25 00:16:10 2023 GMT
This is consistent with the behaviour of wget when a root or intermediate certificate has expired. In this case it’s an OS level issue; it’s the OS that retains the records of root and intermediate certificates. blisshq.com uses Let’s Encrypt, and it appears the QNAP root certicates are now out of date.
Fortunately, Andrea Draghetti had published his commands for updated certificates on a QNAP. I had to make a few small changes to get the commands to parse (and update the location for the certificates, which has since changed).
On the QNAP:
cd /share/
curl https://curl.se/ca/cacert.pem -O -k
mkdir certs
cat cacert.pem | awk 'split_after==1{n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {if(length($0) > 0) print > "certs/cert" n ".pem"}'
for filename in certs/*pem; do mv $filename `openssl x509 -hash -noout -in $filename`.0; done;
cp *.0 /etc/ssl/certs/
Now we can test again:
# wget -O- https://www.blisshq.com/app/latest-linux-version
--2023-04-17 11:05:07-- https://www.blisshq.com/app/latest-linux-version
Resolving www.blisshq.com... 104.21.75.85, 172.67.217.150, 2606:4700:3032::ac43:d996, ...
Connecting to www.blisshq.com|104.21.75.85|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 60 [binary/octet-stream]
Saving to: ‘STDOUT’
- 0%[ ] 0 --.-KB/s h- 100%[=========================================>] 60 --.-KB/s in 0s
2023-04-17 11:05:08 (4.12 MB/s) - written to stdout [60/60]
Success! Our root certicates are updated, and we can now issue GETs to websites secured using Let’s Encrypt once more.
An alternative workaround, if you have control over the wget command, is to include the --no-check-certificate option.