Cert showing wrong CN & Alternate Name (certbot-generated)

Help
1

My CN and Alternate Name are different to the domain for which I generated the certificate, and this is causing an Android app to fail to connect to my site. The domain name being used is another domain which I own, which is hosted on the same server.

I use port 443 for SSL. This is forwarded on my router to the nginx host machine (a Proxmox Lubuntu VM).
I used this command to generate the cert:

sudo certbot certonly --nginx -d home.richmondtech.co.uk

My domain is:home.richmondtech.co.uk

I ran this command:
openssl x509 -in /etc/letsencrypt/live/home.richmondtech.co.uk/fullchain.pem -text -noout |grep -A1 Subject

It produced this output:

Subject: CN = ianmanning.ddns.net
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
--
            X509v3 Subject Key Identifier: 
                E5:DA:48:0A:7C:C0:12:8B:07:7D:53:3D:3E:37:D2:40:D0:15:4D:2E
--
            X509v3 Subject Alternative Name: 
                DNS:ianmanning.ddns.net

My web server is (include version):nginx 1.18.0

The operating system my web server runs on is (include version):Lubuntu 20.04 LTS

My hosting provider, if applicable, is:Cloudflare

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):Cloudflare

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

2

Well, that's interesting.

That Subject Key Identifier is for ianmanning so it is odd to see that in a folder named for your richmond domain.

But, you did get several certs for richmond recently (below). It is far more likely something is wrong with your folder structure rather than a mis-issuance of this kind (far, far, more).

Can you show output of:
sudo certbot certificates

Have you ever used a --deploy-hook with any of your certs? Perhaps one that still exists in the Certbot hook folder?

image
image1908×234 54.3 KB

1 Like
3

This is the output of sudo certbot certificates:

Found the following certs:
  Certificate Name: home.richmondtech.co.uk-0001
    Serial Number: 4e7c8ff565731e47c9f24949b98624961f6
    Key Type: ECDSA
    Domains: home.richmondtech.co.uk
    Expiry Date: 2025-03-22 15:28:27+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/home.richmondtech.co.uk-0001/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/home.richmondtech.co.uk-0001/privkey.pem
  Certificate Name: home.richmondtech.co.uk
    Serial Number: 485c3adbb61917cdeb3377b5dc41f04b347
    Key Type: ECDSA
    Domains: ianmanning.ddns.net
    Expiry Date: 2025-03-16 17:50:31+00:00 (VALID: 84 days)
    Certificate Path: /etc/letsencrypt/live/home.richmondtech.co.uk/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/home.richmondtech.co.uk/privkey.pem
  Certificate Name: ianmanning.ddns.net
    Serial Number: 4d5e2c258f91ad8c20a67f7adc0bd2a5098
    Key Type: ECDSA
    Domains: ianmanning.ddns.net
    Expiry Date: 2025-03-21 12:54:49+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/ianmanning.ddns.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/ianmanning.ddns.net/privkey.pem

No, AFAIK I have never used a --deploy-hook.

4

Once again my post was instantaneously flagged/hidden as soon as I hit the Reply button
???!

5

I don't know. Sometimes you post as itm1960 and sometimes as itm60. Maybe try posting as itm60 the same as when you started this thread? I am just guessing - this is unusual.

1 Like
6

Oh sorry I post from 2 different machines and I choose to use my Github ID to login, but I haven't worked out how the authorisation is working as the login seems to prompt me for a user id each time I use that method.

1 Like
7

This can happen various ways. One possibility is that 6 days ago you did something like this:

sudo certbot certonly --nginx --cert-name home.richmondtech.co.uk -d ianmanning.ddns.net

There are other Certbot interactive options that lead to same result. The --cert-name is just the folder name (or, a profile name). Its name is not related to the domains in the cert. It could be --cert-name MyProdServer for example.

We could look at the /etc/letsencrypt/archive/home.richmondtech.co.uk for the few prior issued certs under this profile name. We could dissect each one and put together the chain of events. I just don't know if it is worth the trouble.

Now, the one below is the most recently issued but note the folder name has -0001 in it. Certbot does that when the domain names in the cert request don't match the folder profile it would normally use.

So, what to do? I would issue a new cert for the original home.richmond profile like this

sudo certbot certonly --nginx --cert-name home.richmondtech.co.uk -d home.richmondtech.co.uk

Certbot will ask about replacing it or expanding or something. Just reply as needed so that it uses just the richmond domain for this cert name / profile.

Further, I assume you don't reference the files in the -0001 folder so delete that.

sudo certbot delete --cert-name home.richmondtech.co.uk-0001

When all that is done re-run and show:

sudo certbot certificates
1 Like
8

Thanks so much - that seems to have resolved the issue.
This is how things now look:

Found the following certs:
  Certificate Name: home.richmondtech.co.uk
    Serial Number: 48429a4427b8e992270d8854b99d8349491
    Key Type: ECDSA
    Domains: home.richmondtech.co.uk
    Expiry Date: 2025-03-22 18:59:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/home.richmondtech.co.uk/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/home.richmondtech.co.uk/privkey.pem
  Certificate Name: ianmanning.ddns.net
    Serial Number: 4d5e2c258f91ad8c20a67f7adc0bd2a5098
    Key Type: ECDSA
    Domains: ianmanning.ddns.net
    Expiry Date: 2025-03-21 12:54:49+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/ianmanning.ddns.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/ianmanning.ddns.net/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 Like
9

But your hostname ianmanning.ddns.net is still sending the home.richmondtech.co.uk certificate.

Please double check your nginx configuration.

10

Yeah, I see what Osiris sees. Also use test site like this for each of your domains: SSL Checker

If you need help fixing your nginx config please show the server block for port 443 that has ianmanning.ddns.net in the server_name list.

1 Like
11

Hmmm...that's strange...this is the server block for ianmanning.ddns.net:

server {
        listen 80;
        listen [::]:80;

        root /var/www/ianmanning.ddns.net/html;
        index index.html index.htm index.nginx-debian.html;

        server_name ianmanning.ddns.net www.ianmanning.ddns.net;

        location / {
                try_files $uri $uri/ =404;
        }
}
12

Should I repeat the same procedure as before for the ianmanning.ddns.net cert?

13

That's the one for port 80. Do you have one for port 443 that refers to its own cert? Otherwise you'll get the default server block (which is probably richmond).

1 Like
14

No, that one looks fine as it is.

1 Like
15

Actually I don't have one for port 443 for ianmanning.ddns.net
???

16

SSL checker does show this for ianmanning.ddns.net:

Doesn't match Common Name or/and SANs
17

You need to make one if you want that nginx to reply to HTTPS requests for that domain

1 Like
18

Or not if you don't use the hostname ianmanning.ddns.net directly in a browser. Dynamic DNS hostnames are often used as a CNAME in more "fancy" hostnames.

E.g.: fancy.example.com IN CNAME less.fancy.ddns.url.example.net

Clients would type in fancy.example.com in their browser, Google would use that URL et cetera, but in the DNS the IP address of less.fancy.ddns.url.example.net would be used.

In the above scenario no virtualhost for less.fancy.ddns.url.example.net would be required, nor a certificate for that hostname, as it's only used for DNS purposes.

But if you do use the ianmanning.ddns.net hostname directly in browsers or other clients, then you'd want to have a HTTPS port 443 virtualhost for that hostname too.

19

Right now I don't use ianmanning.ddns.net directly in a browser, although I may do in the future. I guess I would only need to "clean up" the SSL cert as and when that time comes?

20

Euh, what do you mean by "clean up the cert"? Because the certificate looks fine in your last certbot certificates output. If you want to use ianmanning.ddns.net in the future, you need to add a HTTPS vhost for it in your nginx configuration. Not "clean up the cert".

1 Like