3

I have Nginx setup and successfully serving SSL to example.com using certbot/letsencrypt. But when I try to reverse proxy to a local machine I get NET::ERR_CERT_COMMON_NAME_INVALID. Here's the basic setup

role name ip
Nginx server example.com 192.168.1.1
Web server test01.example.com 192.168.1.10
Web server test02.example.com 192.168.1.11

Both web servers are currently using self-signed certs. I can access them internally via https://192.168.1.10:8443. But again, if I try to access https://test01.example.com I get NET::ERR_CERT_COMMON_NAME_INVALID.

Here is my basic config:

server {
    listen          443 ssl http2;
    server_name     example.com;
    root            /usr/share/nginx/html/;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    include ssl.conf;
}

server {
    listen          443;
    server_name     test01.example.com;

    location / {
        proxy_pass      $scheme://192.168.1.10:8443;
    }
}

I'll probably have over 20 of these web servers. Do I need to generate a cert for each one?

2
  • 1
    FYI, I just went down a wild rabbit hole trying to figure out why the table in your question wasn't rendering properly. Looks like it was caused by a known bug. Commented Jan 26, 2023 at 8:42
  • Thanks for fixing it. It looked fine in preview of course, and I didn't notice it was wrong after posting. Commented Jan 26, 2023 at 13:46

3 Answers 3

3

I was able to get this to work with a wildcard cert. I generated the cert with certbot using this command:

sudo certbot certonly --agree-tos --email emailaddress --manual --preferred-challenges=dns -d *.example.com --server https://acme-v02.api.letsencrypt.org/directory

I then added ssl_certificate and ssl_certificate_key directives to the server block. I did this with an include so I don't have to duplicate the lines for every subdomain.

wildcard.conf

ssl_certificate       /etc/letsencrypt/live/example.com-wc/fullchain.pem;
ssl_certificate_key   /etc/letsencrypt/live/example.com-wc/privkey.pem;

nginx.conf

 server {
    listen          443 ssl;
    server_name     test01.example.com;
    include         wildcard.conf;

    location / {
            proxy_redirect  off;
            proxy_pass      $scheme://192.168.1.10:8443;
    }

}
2

You can do this either way - a wildcard cert, or multiple Subject Alt Names in a single cert.

The advantage of a wildcard cert is that it easy to add additional hosts, and quite clean. The disadvantage is that it is harder to generate a LetsEncrypt Cert for it. If you have the hooks into DNS this is the way to go. but if not then you need to manually generate a new cert every 2 months which can be a PITA.

The reverse is more-or-less true for a multi-domain cert - you can use standard HTTP validation, so this process can be fully automated until you need to add an additional domain name.

The third option (and I'm not advocating it, just listing for completeness) is to purchase a wildcard cert, which means you only need to jump through validation hoops once a year.

1

In addition to the aforementioned answers, there exists a graphical user interface (GUI) known as Nginx Proxy Manager, which may appeal to individuals who prefer not to work with code directly. The suggested approach to utilizing the Nginx Proxy Manager involves installing it on Docker and utilizing it to forward traffic to Docker containers within the same network. Following installation, generating SSL certificates is a simple process that can be achieved with a single click.

Source : Nginx Proxy Manager (Video) Website: Nginx Proxy Manager (Official Website)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.