Common names mismatch

Help
1

Hello!

We've mentioned that some users get error

NET::ERR_CERT_COMMON_NAME_INVALID

We've found out that this applies only to our https://www.domain.ru, not https://domain.ru. But we use nginx, and these two domains must be equal.

For example, our another domain, simulative.ru is ok with this.

My domain is:

https://www.itresume.ru # with problem
https://itresume.ru # ok

I ran this command:

certbot certificates

It produced this output:

 Certificate Name: itresume.ru
    Serial Number: 4da382681685a0bf6277199608468478b70
    Key Type: RSA
    Domains: itresume.ru airflow.itresume.ru api.itresume.ru apitest.itresume.ru apitest2.itresume.ru beta.itresume.ru cps.itresume.ru
    Expiry Date: 2022-09-20 07:47:15+00:00 (VALID: 68 days)
    Certificate Path: /etc/letsencrypt/live/itresume.ru/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/itresume.ru/privkey.pem
....
....
  Certificate Name: simulative.ru
    Serial Number: 331b31bf880b1250e0d9c5f354aac4109be
    Key Type: RSA
    Domains: simulative.ru mailer.simulative.ru
    Expiry Date: 2022-09-20 07:47:40+00:00 (VALID: 68 days)
    Certificate Path: /etc/letsencrypt/live/simulative.ru/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/simulative.ru/privkey.pem

The result of SSL Checker is following:

None of the common names in the certificate match the name that was entered (www.itresume.ru). You may receive an error when accessing this site in a web browser. Learn more about name mismatch errors.
	Common name: simulative.ru
SANs: simulative.ru, www.simulative.ru
Valid from June 22, 2022 to September 20, 2022
Serial Number: 039f13a5a0a8b91c9d8b6cb7be84085c0478
Signature Algorithm: sha256WithRSAEncryption
Issuer: R3

My web server is:

nginx

The operating system my web server runs on is:

ubuntu

I can login to a root shell on my machine (yes or no, or I don't know):

yes

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

certbot 1.29.0

We tried to renew certificates but with no effect. Help please :slight_smile:

4

Where is the cert that covers the FQDN "www.simulative.ru" ?

Is there some device in front of your server [MiTM] that is doing HTTPS inspection/termination?

Is this your IP?:

Name:    www.simulative.ru
Address: 89.108.103.208
3 Likes
5

Sorry, here is a part of certbot certificates which matches www.simulative.ru. Is this what you've answered?

  Certificate Name: www.simulative.ru
    Serial Number: 39f13a5a0a8b91c9d8b6cb7be84085c0478
    Key Type: RSA
    Domains: simulative.ru www.simulative.ru
    Expiry Date: 2022-09-20 07:47:59+00:00 (VALID: 68 days)
    Certificate Path: /etc/letsencrypt/live/www.simulative.ru/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/www.simulative.ru/privkey.pem

About "device" - we have our hosting-provider and nginx. Or what do you mean?

89.108.103.208 is our IP, yes. We have several domains and projects on one server managed with nginx.

6

Does your nginx server_name include www.itresume.ru in the same server block as itresume.ru?

Because the cert returned for the www is for your other domain simulative.ru so it looks like nginx is not matching the www.itresume.ru domain so is using the default server block (simulative?) instead.

And, you don't have a cert that covers the www.itresume.ru domain

4 Likes
7

We replace www with no-www, it's all the same for all domains (including simulative.ru).

server {
    server_name ~^www\.(?<domain>.+)$;
    return  301 $scheme://$domain$request_uri;
}

I suppose, certificate for www.itresume.ru may be an old one, when we didn't have any replacement. But I can't even find it in certbot certificates.

And our server_name always include only non-www version.

8

Don't test with the "www" in the name - that will fail.

3 Likes
9

If that server is handling https requests (port 443) it needs all the rest of the SSL config just like the server block for itresume.ru. Items like ssl_certificate and so on. You can check what cert your domain names return using a site like this one

4 Likes
10

If I'm not mistaken, requests are handled by another server-block:

# itresume.ru

## to https redirect
server {
    listen 80;
    server_name _;
    return 301 https://$host$request_uri;
}

## from www redirect
server {
    server_name ~^www\.(?<domain>.+)$;
    return  301 $scheme://$domain$request_uri;
}

## Main site
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    #listen 80;
    #listen [::]:80;
    server_name itresume.ru;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        include errors.conf;
    }

    # SSL
    include configs/ssl.conf;
    ssl_certificate /etc/letsencrypt/live/itresume.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/itresume.ru/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/itresume.ru/chain.pem;
}

In this case we don't need to add SSL config to no-www-server-block, right?

And I don't understand why common name for www.itresume.ru is simulative.ru...

11

Since there is no HTTPS server block serving "www.itresume.ru", the default (or first) HTTPS server block answers.

5 Likes
12

Ok, so, do we need to add SSL config to Main site server block, despite replacing www to non-www?

I mean here:

## Main site
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    #listen 80;
    #listen [::]:80;
    server_name itresume.ru;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        include errors.conf;
    }

    # SSL
    include configs/ssl.conf;
    ssl_certificate /etc/letsencrypt/live/itresume.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/itresume.ru/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/itresume.ru/chain.pem;
}
13

This server block does not handle HTTPS requests since it is not listening on port 443 (and does not have any ssl config). It only redirects HTTP requests from a www request to http://(domain) but that is all it does. To make it redirect to HTTPS you should change $scheme to https

For https requests, when a request arrives for https://itresume.ru it goes to your default https server which is the first https server block or one marked default (in your case it is the simulative https server block). You can review the nginx docs for how server blocks are selected.

You have several options. Just two are:

One is to make a small server block configured for ssl with the server_name www.itresume.ru which just redirects to the https://itresume.ru$request_uri

Another idea is in your existing https server block for itresume.ru to change your server_name to this:

server_name itresume.ru www.itresume.ru;

And add this to that server block:

    if ($host = www.itresume.ru) {
        return 301 https://itresume.ru$request_uri;
    }

In all cases, you should expand your cert to include the www.itresume.ru name

6 Likes
14

Maybe this can better explain "the problem":
There are four possible ways to directly connect to your site:

  • http://site [this can be redirected to https://site]
  • http://www.site [this can be redirected to http://site]
  • https://site [this is where you want everyone to end up - no redirection needed]
  • https://www.site [this requires a cert before it can do any redirection]
4 Likes
15

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