Domain's that starts with numbers create a conflict for subdomain's ssl

Please fill out the fields below so we can help you better.

My domain is:

  • 12t9edda.site

I ran this command:

$ certbot --webroot -w /var/www/letsencrypt -d www.12t9edda.site -d 12t9edda.site --installer nginx

It produced this output:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/www.12t9edda.site/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/www.12t9edda.site/privkey.pem
This certificate expires on 2021-11-14.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for www.12t9edda.site to /etc/nginx/conf.d/12t9edda.site.conf
Successfully deployed certificate for 12t9edda.site to /etc/nginx/conf.d/12t9edda.site.conf
Your existing certificate has been successfully renewed, and the new certificate has been installed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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 20.04

My hosting provider, if applicable, is :

  • DigitalOcean

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 CONTROL PANEL

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot) :

  • certbot 1.18.0

PROBLEM :

I have a digitalocean droplet with Nginx installed this webserver serves some content for different websites, some for subdomains (somthing.example.com) others for mapped root domains (foo.com, bar.com...).
SSLs are generated with cerboot for root domains, and for subdomains I have obtained a wild-card certificate that points to "*.example.com", everything was fine until I had to point this domain "12t9eda.site" with the command provided above (this domain is the only one that starts with numbers ) when I create SSL certificate for this domain (12t9edda.site) other subdomains (*.example.com) got affected and lost their certificate (browsers show a message that this subdomain is not secure and the certificate was issued to 12t9edda.site) if I remove the SSL certificate for "12t9edda.site" everything works as expected.
i been struggling with this problem for about 2 weeks now and I found no clue on the internet or just how to debug certificates with Nginx and certbot.
hope this was clear, thanks to anyone that can provide some help
thanks in advance

1 Like

Your website is currently using the certificate for *.storeino.com which is invalid for the domain you are trying to use. You could post your nginx config here and perhaps someone can help.

I believe the important part with nginx is that you declare a servername for every site https configuration, otherwise you'll get the default (unless you have multiple IP addresses):

 server {

        listen   443;
        **server_name example.com;**

        root /usr/share/nginx/www;
        index index.html index.htm;

        ssl on;
        ssl_certificate /etc/nginx/ssl/example.com/server.crt;
        ssl_certificate_key /etc/nginx/ssl/example.com/server.key;
}
2 Likes

Welcome to the Let's Encrypt Community, Brahim :slightly_smiling_face:

Let's get to the bottom of this. :face_with_monocle:

What are the outputs of:

sudo nginx -T
sudo ls -lRa /etc/nginx
sudo ls -lRa /etc/letsencrypt
sudo certbot certificates

Please put 3 backticks above and below each output, like this:

```
output
```

2 Likes

nginx loads the included configs alphabetically.
That explains three things:

  1. Why you see this cert when that file is in use (numbers come before letters in alpha sorting).
  2. Your config fails to properly serve the other sites and simply uses the default site.
  3. There is no configured default TLS site - which is exemplified by the alpha sort order use.

So, this can be "fixed" in three different ways:

  1. Define the config that you want to serve those other names to be the default TLS site config.
  2. Rename the config that you want to serve those other names to be lower numerically (or start it with an underscore: _this1comes1st.conf).
  3. Fix configs so that all names being served are properly covered by their corresponding config file.

Note: "fixed" here is generalized to mean - make things works to a minimal level of satisfaction.
[There is only one real "fix" here; And that is #3]

2 Likes

The output of: nginx -T
Would show you the problem completely.

1 Like

thanks sir @rg305 for your answer, the second solution solved the problem for me, renaming the config file that has my wildcard certificate to 00-example.conf solved it.
but for _example.conf it didn't change the order after checking with nginx -T
overall your explanation was on point and was helpful, thanks.
and also thanks to griffin and webprofusion for their replies :raised_hands:

2 Likes

I'm happy if you're happy :slight_smile:
Cheers from Miami :beers:

#FreeCuba

2 Likes

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