Setting up Certbot for use with nginx port 80 conflict

Which of those files covers the FQDN you are trying to obtain a cert for?
[please show the contents of that file]

1 Like

They are all subdomains of the FQDN. Here's one of them...

server {
    listen         80;
    return         301 https://$host$request_uri;

server {
    listen 2443 ssl;

    add_header Strict-Transport-Security "includeSubDomains" always;

    ssl_certificate	C:/ssl/;
    ssl_certificate_key	C:/ssl/;
    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  5m;

    access_log C:/nginx/logs/;

    location / {
        proxy_set_header  	X-Real-IP  $remote_addr;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_redirect off;
        proxy_buffering off;


Where is that being served?
[what I see there is ssl on port 2443]

1 Like

Where is the FQDN being served from?

1 Like

FQDN means fully qualified domain name. An FQDN includes all dns labels.

These are five different FQDNs:

1 Like

What I don't like of your setup is that you used one server block for each FQDN on port 80. For example, I did the same redirect on multiple subdomains like this:

server {
        listen 80;
        listen [::]:80;
        # simplified form -- see

        location /.well-known/acme-challenge/ {
                root /var/www/acme;

        location / {
                return 301 https://$host$request_uri;

And I only have this block on port 80. Several on 443.

A wanted side effect, all subdomains have the same webroot as far as Let's Encrypt is concerned. On port 443, they serve different things.

1 Like

@9peppe, I originally had it coded similarly, but someone else strongly suggested I separate them out... What's a guy to do :upside_down_face:

Domain name @ NameCheap
That's the redirect offered to me... direct all port 80 traffic to SSL port 2443.

Coming back to the problem I'm having w/ certbot... Where's the issue in authenticating the domains? What needs to be addressed?

It needs for certbot to be able to write whatever files are served under the /.well-known/acme-challenge path.

So, either one for all or one each you should have a similar location block to the one you see in my config.

1 Like

@9peppe How are you including your subdomains? Are they listed in one conf file?

Not sure this matters, but when I run that certbot line, I watch the folder and see the /.well-known/acme-challenge/ directory being created, then removed, so certbot can access the /static directory.



server_name *

1 Like

That may be true...
But since I'm the explicit type, I always use the second line :wink:


The documentation goes further and tells you that explicitly specifying the most used subdomains is faster

server_name *

I don't do this because when I add a new 443 server block then I don't have to go and add the subdomain to the 80 block.


I'm still not understanding why I get the below error. Certbot has access to the respective directory, as I watch it actually being created. Specifically, what doesn't have access to where, accessing what?

C:\Windows\system32>certbot certonly --webroot -v
Saving debug log to C:\Certbot\log\letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel):
Requesting a certificate for
Performing the following challenges:
http-01 challenge for
Input the webroot for (Enter 'c' to cancel): /nginx/static
Creating a web.config file in C:\nginx\static\.well-known\acme-challenge to allow IIS to serve challenge files.
Waiting for verification...
Challenge failed for domain
http-01 challenge for

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Type:   connection
  Detail: Fetching Error getting validation data

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

The Let's Encrypt acme server is not finding the challenge file.

Certbot is the acme client which places the challenge file in the webroot folder. It then instructs the LE server to look for it. The server does not know your server file system, it just looks here: of challenge file)

For this to work, the webroot folder used with certbot must be same as the root folder value used in nginx for the server.

You could run the certbot command adding

--debug-challenge -v

to be instructed what exactly will be looked for by the LE server. You can try accessing that link to see if it would work. Or, if you leave it paused maybe one of us will be able to check it too.


I see in the test process, it's attempting to access...

Certbot has access to this location and actually creates '.well-known/acme-challenge/' on the fly.

The problem may be in how its attempting to get there from the outside. I noticed its using http. I have nginx setup so that all http traffic is routed to the SSL port 2443.

Furthermore, in order for me to use, say,, I must add the port 2443 to the url, so

Is it possible that nginx is not allowing the connection because of this? I have found no way around requiring the port in the url.

"Routed to" via an HTTP redirect, or "routed to" via a port forward, or some other way?

What does it look like to someone connecting from outside of your network?


The validation server only follows redirects to ports 80 and 443, not any other port.

You should validate on port 80 or move your https listener on 443.


Before you continue testing with LE production services...
Please place a test text file in the expected challenge location:

Then see if it can be reached directly from the Internet.