Certificate validation fails due to expired root CA

Target Turris OS: 4.0.5
DynDNS update constantly fails:

May 31 15:08:50 turris ddns-scripts[6887]: myddns_ipv4: GNU Wget Error: '5'
May 31 15:08:51 turris ddns-scripts[6887]: myddns_ipv4: Transfer failed - retry 31/0 in 60 seconds

More details here:

181809       : ERROR: cannot verify dynamicdns.park-your-domain.com's certificate, issued by        'CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB':
Issued certificate has expired.
To connect to dynamicdns.park-your-domain.com insecurely, use `--no-check-certificate'.

See the certificate failure:

openssl s_client -connect dynamicdns.park-your-domain.com:443 -servername dynamicdns.p
ark-your-domain.com </dev/null

depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=dynamicdns.park-your-domain.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

The issue is on depth 3 with an expired CN=AddTrust External CA Root:

root@turris:~# openssl x509 -text -in /etc/ssl/certs/AddTrust_External_Root.crt | grep After
            Not After : May 30 10:48:38 2020 GMT

If I open https://dynamicdns.park-your-domain.com in Firefox it validates, because CN=USERTrust RSA Certification Authority is self-signed and in the trust store, so no need for the expired AddTrust External CA Root signature.

So, who or what is supposed to retract expired root certificates from Turris/OpenWRT?

That cert is provided through OpenWrt’s ca-certificates package and from the source openwrt/package/system/ca-certificates/Makefile at openwrt-19.07 · openwrt/openwrt · GitHub it seems to be pulling the cert store from Index of /debian/pool/main/c/ca-certificates

Is the ca-bundle package installed on your node?

with gnutls-cli -V dynamicdns.park-your-domain.com | grep After I get

Not After: Mon Apr 05 23:59:59 UTC 2021
Not After: Tue Dec 31 23:59:59 UTC 2030
Not After: Sun Dec 31 23:59:59 UTC 2028

root@turris:~# opkg list-installed ca*
ca-bundle - 20190110-1.0
ca-certificates - 20190110-1.36

Odd I get the same, meaning the trust chain is different with gnutls-cli. Trust in this case is established by AAA Certificate Services Root CA signing for
USERTrust RSA Certification Authority. With openssl, AddTrust External CA Root is the signer.

Version: 3
	Serial Number (hex): 3972443af922b751d7d36c10dd313595
	Issuer: CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
		Not Before: Tue Mar 12 00:00:00 UTC 2019
		Not After: Sun Dec 31 23:59:59 UTC 2028
	Subject: CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey,C=US

Aaaaand, after installing gnutls-utils, OpenSSL is validating using the same trust chain. What is happening?

It’s not gnu-utils. The last ddns-script error in the log is from 4 hours ago, when it solved itself.
I don’t understand, the Firefox is still validating the same way as before, different than gnutls/openssl. Could it have been an outdated server certificate chain configuration that the admins solved in the mean time?

Most likely, considering that the admins missed the issue prior to

and since then been altered and rectified it.

For some closure: https://www.namecheap.com/support/knowledgebase/article.aspx/10228/14/sectigo-root-certificate-expiring-may-30-2020/.

Firefox normally uses its own certificate set that’s independent of what’s on the OS, I believe. (And any client browser will certainly be independent of certificates installed on the router.)