Expanding a certificate to cover subdomains does not appear to be working

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: *.clubhelp.com.au (qcc.clubhelp.com.au, demo.clubhelp.com.au...)

I ran this command:
sudo certbot certonly --manual --preferred-challenges dns -d '*.clubhelp.com.au' -d clubhelp.com.au
It produced this output:

root@ip-172-30-1-44:/etc/letsencrypt/live# sudo certbot certonly --manual --preferred-challenges dns -d '*.clubhelp.com.au' -d clubhelp.com.au
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/clubhelp.com.au.conf)

It contains these names: clubhelp.com.au

You requested these names for the new certificate: *.clubhelp.com.au,
clubhelp.com.au.

Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: E
Renewing an existing certificate for *.clubhelp.com.au and clubhelp.com.au

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:

_acme-challenge.clubhelp.com.au.

with the following value:

pdtPCoPBXbWw7cuDTjlfIjU47pqtre363zy0xXSZzOk

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.clubhelp.com.au.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/clubhelp.com.au/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/clubhelp.com.au/privkey.pem
This certificate expires on 2024-08-08.
These files will be updated when the certificate renews.

NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

My web server is (include version):
nginx version: nginx/1.18.0 (Ubuntu)
The operating system my web server runs on is (include version):
Ubuntu 22.04.4 LTS
My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.10.0

The command appears to work fine. The nginx config entry is:

root@ip-172-30-1-44:/etc/letsencrypt# cat /etc/nginx/sites-enabled/qcc
server {
    listen 80;
    server_name qcc.clubhelp.com.au;

    return 301 https://$host$request_uri; # Redirect all HTTP traffic to HTTPS
}

server {
    listen 443 ssl; # managed by Certbot
    server_name qcc.clubhelp.com.au;


    location = /favicon.ico {
        root /home/qcc/qcc/collected_static;
        access_log off;
        log_not_found off;
    }

    location /static {
        alias /home/qcc/qcc/collected_static;
    }

    location / {
        root /home/qcc;
        include proxy_params;
        proxy_pass http://unix:/home/qcc/site.sock;

        auth_basic "Restricted Content. Contact paul.whipp at gmail.com for access.";
        auth_basic_user_file /etc/nginx/htpasswd;
    }

    ssl_certificate /etc/letsencrypt/live/clubhelp.com.au/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/clubhelp.com.au/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

However, accessing the site using chrome (and probably any other browser) results in:
Not secure: NET::ERR_CERT_COMMON_NAME_INVALID

Calling certbot renew tells me that the certificate is not due for renewal.

This all seemed to be working prior to renewal although I had accidentally created two certificates.

I removed one completely before attempting the above expansion.

It appears that the certificate is not supporting the wildcard subdomains in spite of my apparently successful attempt the expand it above. The certificate appears to have the wildcard in it:

root@ip-172-30-1-44:/etc/letsencrypt# openssl x509 -in /etc/letsencrypt/live/clubhelp.com.au/fullchain.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:cb:66:e5:97:ba:e4:20:e7:07:81:fc:c9:73:4a:21:ea:42
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: May 10 23:31:10 2024 GMT
            Not After : Aug  8 23:31:09 2024 GMT
        Subject: CN = *.clubhelp.com.au
        Subject Public Key Info:
...

Hi @pwhipp, and welcome to the LE community forum :slight_smile:

What shows?:
certbot certificates

3 Likes
root@ip-172-30-1-44:/etc/letsencrypt# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: clubhelp.com.au
    Serial Number: 3cb66e597bae420e70781fcc9734a21ea42
    Key Type: ECDSA
    Domains: *.clubhelp.com.au clubhelp.com.au
    Expiry Date: 2024-08-08 23:31:09+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/clubhelp.com.au/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/clubhelp.com.au/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Did you reload nginx after getting the wildcard cert?

Maybe like?

sudo systemctl reload nginx

Because the cert used being used for qcc.clubhelp.com.au right now is still the older non-wildcard version. All you showed above looks fine. Not reloading seems the most likely reason.

3 Likes
~ $ sudo systemctl stop nginx
~ $ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Sat 2024-05-11 15:09:27 AEST; 4s ago
       ...
~ $ sudo systemctl start nginx
~ $ sudo systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2024-05-11 15:09:38 AEST; 13s ago
       ...

~ $ wget https://qcc.clubhelp.com.au
--2024-05-11 15:10:05--  https://qcc.clubhelp.com.au/
Resolving qcc.clubhelp.com.au (qcc.clubhelp.com.au)... 54.252.68.134
Connecting to qcc.clubhelp.com.au (qcc.clubhelp.com.au)|54.252.68.134|:443... failed: Connection refused.

Restarting nginx does not appear to help.

Hmm... I deleted the nginx logs and restarted again. This seems to have fixed it. I'm guessing there was some sort of caching going on confusing the result.

Sorry for the confusion.

1 Like

No I don't think any cache was involved. Your wget got "connection refused" Which is more a general comms issue even maybe firewall related. That is not reflective of what might have happened after the restart with the certificate. Some good cert testing tools are

or

4 Likes

From the local IP going to the Internet IP:

Sounds like the router doesn't support hair-pinning.
[presuming the local IP is not 54.252.68.134]

3 Likes

How full is the disk?
What shows?:

df -h

3 Likes

It is not on the local network. The service is running on a remote AWS server.

root@ip-172-30-1-44:/var/log/nginx# df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root        7.6G  6.0G  1.6G  79% /
tmpfs            1.9G  1.1M  1.9G   1% /dev/shm
tmpfs            770M  888K  769M   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
/dev/nvme0n1p15  105M  6.1M   99M   6% /boot/efi
tmpfs            385M  4.0K  385M   1% /run/user/1001

The services all seem fine now. I've set up a renew task weekly.

It is strange that the multiple nginx restarts did not work as expected. I'm trusting this is all good now.

The recommended schedule is twice a day.
[it should check and just do nothing >99% of the time]

2 Likes

Why so frequent?

To respond quickly and automatically to CA-initiated revocations, and to give many chances (about 60 instead of about 4) to retry in case of network connectivity or infrastructure outages resulting in randomly failed renewal attempts.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.