Centmin Mod Managing Letsencrypt DST Root CA X3 Certificate Expiration On CentOS 7

by                Reading Time: 11 minutes
Centmin Mod Managing Letsencrypt DST Root CA X3 Certificate Expiration On CentOS 7

On September 30, 2021, Letsencrypt’s DST Root CA X3 cross-sign (by IdentTrust) root certificate expired and was replaced with Letsencrypt’s own ISRG Root X1 CA root certificate. I’ll outline how Centmin Mod LEMP stack handled the Letsencrypt’s DST Root CA X3 certificate expiration for CentOS 7.x operating systems.

Originally, this change was thought to have more impact on older client devices and browsers which haven’t been updated to trust the newer ISRG Root X1 CA root certificate. However, there have been unexpected impacts across many companies and web applications on the internet, including software based security apps and firewalls. Letsencrypt has posted a new article for SSL certificates chaining helpful resources for those having issues too and I’ve updated this blog post to outline how Cloudflare Universal SSL users can switch from Letsencrypt to Digicert or Google Trust Services CA for their edge server SSL certificates. As such I’ll provide updates to this blog post as new information comes to light.

Centmin Mod 123.09beta01 or new versions are the only version that supports automatic Nginx HTTPS site configuration generation via Letsencrypt SSL certificates issuance using the official acmetool.sh wrapper addon script.


Update #1

On September 21, 2021, Centmin Mod 123.09beta01 was updated with a workaround fix which blacklisted the expired certificate in CentOS 7’s CA trust store to deal with CentOS 7’s older OpenSSL 1.0.2 crypto library’s incorrect handling of Letsencrypt’s DST Root CA X3 certificate expiration as outlined on OpenSSL’s own blog post.


Update #2

On September 24, 2021, Redhat/CentOS released updated ca-certificates YUM package which properly removed the expired Letsencrypt’s DST Root CA X3 certificate from CentOS 7’s CA trust store – effectively accomplishing the same workaround as the OpenSSL 1.0.2 fix previously done. Running yum -y update, would of updated ca-certificates YUM package and you’d be set.

Without the first 2 updates mentioned above, CentOS 7 would have definitely been impacted at least on YUM baseurl and mirrorlist side as a lot of the actual mirrors that are HTTPS based are still configured for the standard default Letsencrypt long certificate chain – ending at the expired Letsencrypt DST Root CA X3 root certificate. This would be problematic with CentOS 7’s OpenSSL 1.0.2 version without the 2 updates.

List all HTTPS domains referenced in baseurl and mirrorlist for all YUM repo files

egrep -rin '^baseurl|^mirrorlist' /etc/yum.repos.d | awk -F "=" '/https:\/\// {print $2}' | awk -F/ '{print $3}' | sort -u

download.docker.com
repo.ius.io

Their SSL certificates

myurls=$(egrep -rin '^baseurl|^mirrorlist' /etc/yum.repos.d | awk -F "=" '/https:\/\// {print $2}' | awk -F/ '{print $3}' | sort -u)
for domain in $myurls; do echo '------'; echo -n | timeout 2 openssl s_client -servername $domain -showcerts -connect $domain:443 2>&1 | egrep ' s:| i:'; done

------
0 s:/CN=*.docker.com
i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
i:/C=US/O=Amazon/CN=Amazon Root CA 1
2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
------
0 s:/C=US/ST=Texas/L=San Antonio/O=Rackspace US Inc./CN=secure11.san1.raxcdn.com
i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

List all HTTPS domains referenced in all mirrorlist.txt files

find /var/cache/yum/x86_64 -type f -name 'mirrorlist.txt'
/var/cache/yum/x86_64/7/base/mirrorlist.txt
/var/cache/yum/x86_64/7/extras/mirrorlist.txt
/var/cache/yum/x86_64/7/updates/mirrorlist.txt
/var/cache/yum/x86_64/7/centos-sclo-rh/mirrorlist.txt
/var/cache/yum/x86_64/7/centos-sclo-sclo/mirrorlist.txt
/var/cache/yum/x86_64/7/rpmforge/mirrorlist.txt
/var/cache/yum/x86_64/7/remi/mirrorlist.txt

and each mirrorlist SSL certificate chain – notice many still are configured for the long Letsencrypt SSL certificate chain ending with the expired DST Root CA X3 issuer.

find /var/cache/yum/x86_64 -type f -name 'mirrorlist.txt' -exec cat > urllist.txt {} +
urlmirror_domains=$(cat urllist.txt | awk '/https:\/\// {print $2}' | awk -F/ '{print $3}' | sort -u)
for domain in $urlmirror_domains; do echo '------'; echo -n | timeout 2 openssl s_client -servername $domain -showcerts -connect $domain:443 2>&1 | egrep ' s:| i:'; done

------
0 s:/CN=mirror.dogado.de
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
------
------
0 s:/CN=mirror.serverion.com
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
------
------
0 s:/C=ID/ST=Jawa Barat/L=Bandung/O=Telkom University/CN=*.telkomuniversity.ac.id
i:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
1 s:/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
------
0 s:/CN=remi.mirror.ate.info
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
------
0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.mirror.wearetriple.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=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services


However, it seems WordPress bundles their own CA Trust certificate bundle at wp-includes/certificates/ca-bundle.crt. It seems WordPress has updated their master branch code to remove the DST Root CA X3 expired certificate now.

Existing ca-bundle.crt bundle check for DST Root CA X3

grep 'DST Root' wp-includes/certificates/ca-bundle.crt
DST Root CA X3

Existing ca-bundle.crt compared to master branch version

diff -u wp-includes/certificates/ca-bundle.crt wp-includes/certificates/ca-bundle.crt-master 
--- wp-includes/certificates/ca-bundle.crt      2020-10-27 18:41:24.504948582 +0000
+++ wp-includes/certificates/ca-bundle.crt-master       2021-10-07 18:25:46.473617713 +0000
@@ -736,26 +736,6 @@
 vEsXCS+0yx5DaMkHJ8HSXPfqIbloEpw8nL+e/IBcm2PN7EeqJSdnoDfzAIJ9VNep+OkuE6N36B9K
 -----END CERTIFICATE-----
 
-DST Root CA X3
-==============
------BEGIN CERTIFICATE-----
-MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQK
-ExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4X
-DTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVowPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1
-cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQAD
-ggEPADCCAQoCggEBAN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmT
-rE4Orz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEqOLl5CjH9
-UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9bxiqKqy69cK3FCxolkHRy
-xXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40d
-utolucbY38EVAjqr2m7xPi71XAicPNaDaeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0T
-AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQ
-MA0GCSqGSIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69ikug
-dB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXrAvHRAosZy5Q6XkjE
-GB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZzR8srzJmwN0jP41ZL9c8PDHIyh8bw
-RLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubS
-fZGL+T0yjWW06XyxV3bqxbYoOb8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
------END CERTIFICATE-----
-
 SwissSign Gold CA - G2
 ======================
 -----BEGIN CERTIFICATE-----

Until WordPress pushes out the updated ca-bundle.crt file, you can manually update your local copy. Within SSH session log into your server and go to public web root of your WordPress installation. On Centmin Mod LEMP stack that would be /home/nginx/domains/yourdomain.com/public if you installed yourdomain.com WordPress site at web root. Then run these commands:

cd /home/nginx/domains/yourdomain.com/public
cp -a wp-includes/certificates/ca-bundle.crt wp-includes/certificates/ca-bundle.crt-orig
cd wp-includes/certificates/
wget https://raw.githubusercontent.com/WordPress/WordPress/master/wp-includes/certificates/ca-bundle.crt -O ca-bundle.crt
chown nginx:nginx ca-bundle.crt


Update #3

On September 25, 2021, Centmin Mod 123.09beta01 was updated again with a fix to address the conflict between the OpenSSL 1.0.2 fix and the ca-certificates YUM package update. The ca-certificates YUM package update physically removed the Letsencrypt’s DST Root CA X3 certificate so that the OpenSSL 1.0.2 workaround fix couldn’t find the certificate to blacklist and OpenSSL 1.0.2 workaround fix gave the following error:

unable to load certificate

140575175718800:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE


Update #4

October 1, 2021, updated Centmin Mod 123.09beta01’s acmetool.sh addon wrapper script to support both the default longer chain with DST Root CA X3 for older device and Android compatibility and also support the new shorter chain with ISRG Root X1 certificate via the persistent configuration file /etc/centminmod/custom_config.inc variable, ACME_PREFERRED_CHAIN. Unfortunately, this means for some folks they may need to decide on either using the longer chain with DST Root CA X3 and supporting older Android <7 and other older devices or the shorter chain using ISRG Root X1 for Centmin Mod Nginx HTTPS sites using Letsencrypt SSL certificates being able to be connected from older system client devices like command line tools for CentOS 6 or older based curl, wget and OpenSSL <1.0.1.

Centmin Mod Nginx HTTPS sites with front facing Letsencrypt SSL certificates may have the old longer DST Root CA X3 chain which has expired and on older client devices like Windows XP or Windows 7, the web browser like Chrome might report insecure connections to your sites:

NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_DATE_INVALID

Or the web browser message:

the certificate issuer’s certificate has expired. check your system date and time.

A full list of older devices which may be impacted are listed here and include:

Solution here is to update Centmin Mod 123.09beta01 via cmupdate command and then reissue your Letsencrypt SSL certificate for your domains using the new default shorter chain ISRG Root X1 via SSH command line using acmeotool.sh addon wrapper script. Replace yourdomain.com with your Centmin Mod Nginx site’s domain name or subdomain name. The reissue-only option will only touch your existing Centmin Mod Nginx site’s SSL certificate configuration leaving the rest of your Nginx HTTPS vhost configuration intact.

cmupdate
/usr/local/src/centminmod/addons/acmetool.sh reissue-only yourdomain.com live

By default, switched acmetool.sh addon script to use the new shorter chain with ISRG Root X1 certificate. This was easy to do as acmetool.sh addon script is an extensive wrapper to the official bash/shell based acme.sh client by Neil Pang which supports --preferred-chain flag on the command line when you issue and obtain new Letsencrypt SSL certificates during automated Nginx site generation routines.

Setting Preferred Chain System Wide with acme.sh

Update October 4, 2021: Neil has updated acme.sh client to v3.0.1 to support setting the preferred chain flag at a system wide level instead of requiring it to be passed as a --preferred-chain flag only on the command line for acme.sh issuances. So you don’t need to use acmetool.sh reissue-only one at a time for each domain. The below SSH commands, will first upgrade acme.sh client to a version that supports the new system wide flag i.e. v3.0.1+ and then set the default preferred chain and then reissue and renew all acme.sh site SSL certificates with the new preferred shorter chain for ISRG Root X1.

/root/.acme.sh/acme.sh --upgrade
/root/.acme.sh/acme.sh --set-default-chain --preferred-chain "ISRG" --server letsencrypt
/root/.acme.sh/acme.sh --renewAll --force

Once reissuing the updated shorter chain for your domain, you can check it with SSLLabs testing tool to inspect the available certificate chain paths that common applications take. For example testing against https://valid-isrgrootx1.letsencrypt.org for Mozilla, Apple, Android, Java and Windows shows it takes the shorter chain path to ISRG Root X1 certificate.

SSLLabs certificate chain paths

The other option is to use a different free SSL certificate provider other than Letsencrypt temporarily like Buypass or ZeroSSL (read further below on how you Centmin Mod users can switch from Letsencrypt to ZeroSSL based free SSL certificates).


Update #5

On October 3, 2021, updated Centmin Mod’s PHP-FPM curl used CA Trust bundle for PHP 7+ & PHP 8. Centmin Mod PHP 7+ install routines usually pulls the Mozilla CA Trust store cacert.pem file from https://curl.se/docs/caextract.html for PHP’s curl usage via the curl.cainfo directive specified path. However, that cacert.pem file was not updated to remove DST Root CA X3 expired certificate until September 30, 2021.

php --ri curl

curl

cURL support => enabled
cURL Information => 7.29.0
Age => 3
Features
AsynchDNS => Yes
CharConv => No
Debug => No
GSS-Negotiate => Yes
IDN => Yes
IPv6 => Yes
krb4 => No
Largefile => Yes
libz => Yes
NTLM => Yes
NTLMWB => Yes
SPNEGO => No
SSL => Yes
SSPI => No
TLS-SRP => No
Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp
Host => x86_64-redhat-linux-gnu
SSL Version => NSS/3.53.1
ZLib Version => 1.2.7
libSSH Version => libssh2/1.8.0

Directive => Local Value => Master Value
curl.cainfo => /etc/ssl/certs/cacert.pem => /etc/ssl/certs/cacert.pem


Update #6 – Cloudflare Universal SSL Certificate Switch To Digicert Or Google Trust Services CA

Cloudflare has a March 15, 2024 updated advisory posted here.

The Letsencrypt DST Root CA X3 expiration on September 30, 2021 may also impact Cloudflare orange cloud proxy enabled users as Cloudflare’s Universal SSL provides free SSL certificates through several CA SSL providers, Digicert, Letsencrypt, GlobalSign and Sectigo (Comodo). Update: Cloudflare plans to deprecate Digicert CA SSL certificates and already no longer uses Sectigo/Comodo. As such the only option for legacy devices or browsers is now their newly supported Google Trust Services CA SSL certificates which uses the GTS Root R1 Cross cross-signed certificate to maintain older browser and device compatibility. The GTS Root R1 Cross was cross-signed by GlobalSign Root CA – R1 which was created on September 1, 1998 and expires on January 28, 2028 and is found in many older devices and browsers CA Trust stores due to it’s age and validity since 1998. So folks have another 5+ yrs before it is a concern again for very old browser and legacy devices.

For Cloudflare Universal SSL users who have Cloudflare edge certificates issued by Letsencrypt, their web site’s visitors on very old browsers or devices i.e. Ubuntu 16, iOS <10, Android <7.1.1, Windows XP/7 or macOS <10.12.1 their web browsers like Chrome may report that the connection may not be secure or may not be private with the following errors: NET::ERR_CERT_AUTHORITY_INVALID or NET::ERR_CERT_DATE_INVALID.

There are a number of solutions for this:

  1. Contact Cloudflare tech support and request that they switch your Cloudflare Universal SSL edge certificates from Letsencypt CA provided to Digicert or Google Trust Services CA provided SSL edge certificates.
  2. Upgrade to Cloudflare Advanced Certificate Management (ACM) product at $10/month and you can create your own custom Cloudflare edge SSL certificate and choose Digicert or Google Trust Services as your CA provider for the Cloudflare edge SSL certificate.
  3. Or you can switch your Cloudflare Universal SSL edge certificates from Letsencrypt to Digicert (certificate_authority = digicert) or Google Trust CA (certificate_authority = google) provided via the Cloudflare API via the below curl command ran while logged into your SSH session on your server or local computer (Linux).

There are 4 commands below, where the last curl command is a single line command over 5 lines. You need to populate 3 session variables and pass certificate_authority = digicert or google value:

  • cfzoneid variable replace the value with your Cloudflare domain’s zone id (found on Cloudflare dashboard overview page’s bottom right side column)
  • cfemail variable replace value Cloudflare account’s registered email address
  • cfglobalkey variable replace the value with your Cloudflare account’s Global API Key found at https://dash.cloudflare.com/profile/api-tokens
cfzoneid='your_domain_zone_id'
cfemail='your_cloudflare_account_email'
cfglobalkey='your_cloudflare_account_global_api_key'

curl -4sX PATCH "https://api.cloudflare.com/client/v4/zones/$cfzoneid/ssl/universal/settings" \
     -H "X-Auth-Email: $cfemail" \
     -H "X-Auth-Key: $cfglobalkey" \
     -H "Content-Type: application/json" \
     --data '{"certificate_authority":"digicert"}' | tee /root/centminlogs/cf-universal-ssl-ca-switch.log

After populating SSH session variables and running the curl command, you should have the response from Cloudflare API outputted to your screen (example below) as well as saved copy in JSON format at /root/centminlogs/cf-universal-ssl-ca-switch.log. If you’re not using Centmin Mod LEMP stack, change /root/centminlogs directory location appropriately.

Example curl output:

{"result":{"enabled":true,"certificate_authority":"digicert"},"success":true,"errors":[],"messages":[]}

Using jq to show pretty JSON formatted saved output of file at /root/centminlogs/cf-universal-ssl-ca-switch.log

jq -r . /root/centminlogs/cf-universal-ssl-ca-switch.log
{
  "result": {
    "enabled": true,
    "certificate_authority": "digicert"
  },
  "success": true,
  "errors": [],
  "messages": []
}

How To Switch From Letsencrypt to ZeroSSL Free SSL Certificates

For the last 5yrs, acmetool.sh addon wrapper script has been using Neil Pang’s acme.sh client as the underlying tool to issue and obtain free Letsencrypt certificates. Over time acme.sh client has added support for other free ACME compatible CA SSL providers like Buypass (BuyPass Go SSL) and ZeroSSL. I chose to use ZeroSSL which provides and uses Sectigo (Comodo) CA Root certificate chain as it supports free wildcard SSL certificates and doesn’t have any rate limiting for SSL certificate issuance. Buypass Go SSL has much stricter rate limits and no support for Wildcard SSL certificates and max of 5 domains listed per SSL certificate.

ZeroSSL will in theory allow somewhat older devices to still work with ZeroSSL SSL certificates as they have three CA root certificates that are likely to be in devices’ trust stores – the first two listed are in most modern browsers while the third is cross-signed to support older devices:

  1. USERTrust RSA Certification Authority & USERTrust ECC Certification Authority root
  2. COMODO RSA Certification Authority & COMODO ECC Certification Authority root
  3. AAA Certificate Services root (cross-signed to support older devices)

SSLLabs shows there are two possible certificate chain paths for an issued ZeroSSL SSL certificate – one to modern USERTrust RSA CA root and the second path to cross-signed AAA Certificate Services CA root.

ZeroSSL SSL Certificate chains ZeroSSL SSL Certificate chains

The USERTrust RSA/ECC and COMODO RSA/ECC CA roots were added to the following devices since:

Apple:

  • macOS Sierra 10.12.1 Public Beta 2
  • iOS 10

Microsoft:

  • Windows XP (via Automatic Root Update; note that ECC wasn’t supported by Windows until Vista)
  • Windows Phone 7

Mozilla:

  • Firefox 3.0.4 (COMODO ECC Certification Authority)
  • Firefox 36 (the other 3 roots)

Google:

  • Android 2.3 (COMODO ECC Certification Authority)
  • Android 5.1 (the other 3 roots)

Oracle:

  • Java JRE 8u51

Opera:

  • [Browser release on December 2012]

360 Browser:

  • SE 10.1.1550.0 and Extreme browser 11.0.2031.0

And the cross-signed AAA Certificate Services root provides compatibility to older devices:

  • Apple iOS 3.
  • Apple macOS 10.4.
  • Google Android 2.3.
  • Mozilla Firefox 1.
  • Oracle Java JRE 1.5.0_08.

An interesting non-Centmin Mod note is that cPanel control panel’s own cPanel CA issued SSL certificates also use Comodo/Sectigo CA and have the very same cross-signed AAA Certificate Services root certificate as an alternative SSL chain path too.

cPanel CA chain to AAA Certificate Services CA root

Steps To Switching To ZeroSSL SSL Certificates

ZeroSSL optionally requires you to register an account with at ZeroSSL.com first to obtain the EAB credentials via https://app.zerossl.com/developer that you need to register so that acme.sh client and thus acmetool.sh addon for Centmin Mod’s automated Nginx HTTPS site creation to issue free ZeroSSL SSL certificates instead of Letsencrypt SSL certificates. Or you can just pass your email address on command line to register with ZeroSSL and automatically obtain and register your EAB credentials which end up being saved to the configuration file at /root/.acme.sh/ca/acme.zerossl.com/v2/DV90/ca.conf.

ls -lah /root/.acme.sh/ca/
total 0
drwxr-xr-x 4 root root  66 Sep 26 00:39 .
drwx------ 9 root root 233 Sep 30 23:43 ..
drwxr-xr-x 3 root root  23 Sep 26 00:06 acme-v02.api.letsencrypt.org
drwxr-xr-x 3 root root  16 Sep 26 00:39 acme.zerossl.com

Steps to switch Centmin Mod 123.09beta01 from using free Letsencrypt SSL certificates to using free ZeroSSL SSL certificates:

Step 1. Register an account at ZeroSSL.com and go to https://app.zerossl.com/developer to obtain the EAB credentials. This signup is actually optional as you can instead just provide your email address on the command line then you can actually skip Step 2:

acme.sh --register-account -m myemail@example.com --server zerossl

Step 2. SSH login to your Centmin Mod server and register your EAB credentials with acme.sh client via the command line:

acme.sh --register-account --server zerossl --eab-kid xxxxxxxxxxxx --eab-hmac-key xxxxxxxxx

Without the EAB credentials, you may get a message like:

no eab credentials found for zerossl, let’s get one

Step 3. Configure Centmin Mod acmetool.sh addon to use ZeroSSL instead of Letsencrypt as default CA SSL certificate provider via the persistent configuration file /etc/centminmod/custom_config.inc variable you add:

ACME_DEFAULT_CA='zerossl'

Update Oct 4, 2021: slight typo correction, the variable above was missing a closing single quote. Make sure it’s ACME_DEFAULT_CA=’zerossl’

If you want to switch back from ZeroSSL to Letsencrypt defaults you can remove that variable from the persistent configuration file /etc/centminmod/custom_config.inc or you can specifically set it to the already default value

ACME_DEFAULT_CA='letsencrypt'

The acmetool.sh addon will pickup whichever setting value you have for the variable set in the persistent configuration file /etc/centminmod/custom_config.inc which will override the default settings.

Step 4. Reissuing existing Nginx site’s SSL certificates using ZeroSSL instead of Letsencrypt as CA provider.

Once you have switched to ZeroSSL defaults from above step 1-3, you will need to reissue your SSL certificates for existing Centmin Mod Nginx sites on your server. You do this via acmetool.sh addon wrapper script’s reissue-only option specifying your existing already created Centmin Mod Nginx site’s domain name (without the www) or subdomain name. Replace yourdomain.com with your Centmin Mod Nginx site’s domain name or subdomain name. The reissue-only option will only touch your existing Centmin Mod Nginx site’s SSL certificate configuration leaving the rest of your Nginx HTTPS vhost configuration intact.

/usr/local/src/centminmod/addons/acmetool.sh reissue-only yourdomain.com live

You can then run acmetool.sh checkdates option to list all SSL certificates issued and configured at Nginx level for the current Centmin Mod server. Example below:

/usr/local/src/centminmod/addons/acmetool.sh checkdates

output

/usr/local/src/centminmod/addons/acmetool.sh checkdates
----------------------------------------------
nginx installed
----------------------------------------------

/usr/local/nginx/conf/ssl/zerossl.domain.com/zerossl.domain.com-acme.cer
SHA1 Fingerprint=06FE84519E09ACB75BBE11EDF26F7D41D0Bxxxxx
certificate expires in 83 days on 25 Dec 2021

/usr/local/nginx/conf/ssl/letsencrypt.domain.com/letsencrypt.domain.com-acme.cer
SHA1 Fingerprint=423A55D99E8BEEBBC4C42C82E2C8683684Cxxxxx
certificate expires in 87 days on 29 Dec 2021

----------------------------------------------
acme.sh obtained
----------------------------------------------

/root/.acme.sh/zerossl.domain.com/zerossl.domain.com.cer
SHA1 Fingerprint=06FE84519E09ACB75BBE11EDF26F7D41D0Bxxxxx
[ below certifcate transparency link is only valid ~1hr after issuance ]
https://crt.sh/?sha1=06FE84519E09ACB75BBE11EDF26F7D41D0Bxxxxx
certificate expires in 83 days on 25 Dec 2021

/root/.acme.sh/letsencrypt.domain.com/letsencrypt.domain.com.cer
SHA1 Fingerprint=423A55D99E8BEEBBC4C42C82E2C8683684Cxxxxx
[ below certifcate transparency link is only valid ~1hr after issuance ]
https://crt.sh/?sha1=423A55D99E8BEEBBC4C42C82E2C8683684Cxxxxx
certificate expires in 87 days on 29 Dec 2021

Notes:

  • If you use Cloudflare or any other CDN proxy in front of your Centmin Mod Nginx HTTPS site, then you may not see Letsencrypt or ZeroSSL SSL certificates being served to you as you will see Cloudflare or that CDN proxy’s SSL certificates instead.
  • You can read the Letsencrypt community Help forum for the various other potential issues folks are experiencing from the DST Root CA X3 certificate expiry.
  • If Centmin Mod users have further questions or comments, they can post them on the official Centmin Mod community forums

Further Reading Links:


Feb 8, 2024 onward Letsencrypt DST Root CA X3 final expiry on  September 30, 2024

Centmin Mod Nginx HTTPS uses Letsencrypt by default (since Oct 1, 2021) with addons/acmetool.sh responsible for Nginx HTTPS Letsencrypt SSL issuance and the addons/acmetool.sh by default is configured with ACME_PREFERRED_CHAIN=’ –preferred-chain “ISRG”‘ variable which tells Letsencrypt to issue free Letsencrypt SSL certificates for Centmin Mod Nginx using the recommended shorter chain = ISRG Root X1 as outlined here and above.

The only Centmin Mod Nginx HTTPS users who would be impacted by the changes in , would be folks that deliberately overrode the addons/acmetool.sh default by setting in persistent config file /etc/centminmod/custom_config.inc as per Preferred Chain the following: ACME_PREFERRED_CHAIN=’ –preferred-chain “DST Root CA X3″‘ to prefer using the longer and DST Root CA X3 which is no longer issued since Feb 8, 2024. To reverse this, just remove from persistent config file /etc/centminmod/custom_config.inc the ACME_PREFERRED_CHAIN=’ –preferred-chain “DST Root CA X3″‘ variable that you deliberately set and then reissue all Centmin Mod Nginx issued SSL certificates using the Centmin Mod/acmetool.sh/acme.sh setup cronjob command:

/root/.acme.sh/acme.sh --upgrade
/root/.acme.sh/acme.sh --set-default-chain --preferred-chain "ISRG" --server letsencrypt
/root/.acme.sh/acme.sh --renewAll --force

Once reissuing the updated shorter chain for your domain, you can check it with SSLLabs testing tool to inspect the available certificate chain paths that common applications take.

Now if you still have site visitors to Centmin Mod Nginx HTTPS site using these older devices, then you option is to switch Centmin Mod Nginx HTTPS default Letsencrypt SSL certificate provider to ZeroSSL SSL certificate provider. ZeroSSL SSL certificates uses AAA Certificate Services root which is cross-signed to support older devices like:

  • Apple iOS 3.
  • Apple macOS 10.4.
  • Google Android 2.3.
  • Mozilla Firefox 1.
  • Oracle Java JRE 1.5.0_08.

Cloudflare

Cloudflare has a March 15, 2024 updated advisory posted here. Similarly, if you need these older devices visitors to be able to access your Centmin Mod Nginx HTTPS site and you use Cloudflare and their free SSL certificates issue a Letsencrypt SSL certificate, you want to upgrade to Cloudflare Advance Certificate Management $10/month Introducing: Advanced Certificate Manager to be able to choose your SSL provider and select Google Trust Services CA SSL certificates as outlined above. Google Trust Services CA SSL certificates uses the GTS Root R1 Cross cross-signed certificate to maintain older browser and device compatibility. The GTS Root R1 Cross was cross-signed by GlobalSign Root CA – R1 which was created on September 1, 1998 and expires on January 28, 2028 and is found in many older devices and browsers CA Trust stores due to it’s age and validity since 1998. So folks have another 3yrs and 10 months before it is a concern again for very old browser and legacy devices.

Related posts:

  1. WordPress Cache Enabler Advanced Full Page Caching Guide
  2. How To Install WordPress On Centmin Mod LEMP Stack Guide
  3. How To Switch From Letsencrypt to ZeroSSL Free SSL Certificates On Centmin Mod
  4. How To Setup Cloudflare Argo Tunnel On CentOS 7
  5. Ran IPTables Flush? How To Regain SSH Access After Being Locked Out Of CSF Firewall Servers