Certificate error when using pubic IP. only works when using domain name

Help
1

My domain is:
https://54.82.251.209
niels.operationbim.com

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): AWS

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

image
image1142×592 17.4 KB

Image is in dutch, but it basicly says that the certificate is from the domain name and wont register for the IP one and thus won't validate https

server {

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name niels.operationbim.com;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
}

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/niels.operationbim.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/niels.operationbim.com/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
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name niels.operationbim.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

server {
 #   if ($host = niels.operationbim.com) {
        return 301 https://$host$request_uri;
 #   } # managed by Certbot


        listen 80 default_server;
        listen [::]:80 default_server;

        server_name niels.operationbim.com;
#    return 404; # managed by Certbot


}

Quite new to all this as its my first "lesson on making sites trough aws / lets encyrpt' so apologies if some data is missing

2

This is normal. Certificates for IP address are unusual and Let's Encrypt does not issue them currently. (They were on the roadmap but were removed at some point.)

Often multiple sites are hosted on the same IP address anyway, so it would be ambiguous what site you were accessing if you use the IP.

3

The only semi-free CA that currently offers certs for IP addresses that I know of is ZeroSSL and only using their web interface (or REST API perhaps), but not using their ACME API. And when using their web interface (or REST API), you'll only get 3 free certs in total per account.. So you'd need to register a new account within every 270 days (90 * 3, but less due to the fact you'd want to renew before your certificate expires).

That said, I agree with @dtaylor84 and my advice would be: just don't use the IP address to surf to your website.

4

Unless you have some specific need why you need to access it via ip, I think it's a good idea to redirect the requests coming to the ip directly or any unrecognized domain names to the correct domain. That way you will avoid any cert or duplicate content issues.

Add a default virtual host, something like this:

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

        root /var/www/html;

        server_name _;

        return 301 https://niels.operationbim.com$request_uri;

}

server {
        listen 443 default_server;
        listen [::]:443 default_server;

        root /var/www/html;

        server_name _;

        ssl_certificate /etc/letsencrypt/live/niels.operationbim.com/fullchain.pem; 
        ssl_certificate_key /etc/letsencrypt/live/niels.operationbim.com/privkey.pem;
        include /etc/letsencrypt/options-ssl-nginx.conf; 
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; 

        return 301 https://niels.operationbim.com$request_uri;

}

That way if the user somehow lands on your server requesting anything other than your domain, he will be redirected to the proper domain.

5

Yeah, but that requester is almost certainly a bot or scanner. And, if you have multiple server blocks there is no one place to redirect to.

Instead of the return 301 statement I prefer

deny all;

or (per the nginx docs here)

return 444;

For the port 443 (HTTPS) server block I just use a self-signed cert.