net::ERR_CERT_COMMON_NAME_INVALID using IP address

Help
1

My domain is: http://staging.simulator-backend.studylink.fr/

My web server is (include version): Nginx 1.10.3

The operating system my web server runs on is (include version): Ubuntu 17.10

My hosting provider, if applicable, is: OVH

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

I successfuly generated a certificate using sudo certbot-auto certonly --nginx on my staging server, it created the certification files at /etc/letsencrypt/live/staging.simulator-backend.studylink.fr/ I then copied those files (fullchain and privkey) onto my application folder and restarted my app.

When I go at http://staging.simulator-backend.studylink.fr/ no certificate is found at all.
When I go at https://51.254.213.17:3001 a valid certificate is found, but it displays NET::ERR_CERT_COMMON_NAME_INVALID

image
image.png588×506 17.8 KB

I read on another topic that HTTPS doesn’t work with IP address, domain names must be used. If so, it explains this behavior.

My main provider is AlwaysData, that’s where the domain “studylink.fr” is registered. But the server at 51.254.x.x is under another provider, OVH.

I made a DNS link, using A type from staging.simulator-backend to 51.254.213.17, I believe this should work for both http and https.

If I try to go to https://staging.simulator-backend.studylink.fr/ (secure version) it doesn’t work, connexion refused.

Here is my Nginx configuration:

server {
    listen 80;
    server_name http://staging.simulator-backend.studylink.fr;
    location / {
        proxy_pass https://51.254.213.17:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
     }
}

What did I miss? Thanks for your help.

2

Nothing, you've already found the answer yourself:

The browser checks if the hostname in the address bar (being a FQDN or IP address) is in the SAN list of FQDNs of the certificate. Let's Encrypt doesn't issue certificates with an IP address as a SAN. Therefore, Let's Encrypt certificate will never be accepted as a valid certificate when someone uses the IP address as hostname in the address bar.

Note: the CA/B Forum doesn't forbid the issuing of publically accessible IP addresses as hostname in certificates. It's just Let's Encrypt doesn't allow it. You can search more about this on the community forum, I think there's a thread about it somewhere.

1 Like
3

Any idea why https://staging.simulator-backend.studylink.fr doesn’t work? I can’t tell if it’s related to the DNS or to my Nginx configuration.

4

It seems to be refusing connections on port 443. Is Nginx configured to listen on port 443? Is there a firewall blocking it? Is that what you want?

https://staging.simulator-backend.studylink.fr:3001/ works.

5

Well, thanks. I didn’t know that url (https://staging.simulator-backend.studylink.fr:3001/) was working indeed…

And I just spent quite some time trying to figure out why. My nginx configuration is completely useless and gets bypassed when accessing the url directly like this.
I don’t even see the point keeping nginx, since using it doesn’t seem to work with https.

6

Taking a quick look into the documentation, i doubt that this is correct. You should omit the protocol (http://) from the argument to server_name.

1 Like
7

Indeed, I did it already. Actually I wasn’t specifying the protocol until later testing around. Thanks.

8

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