Setting up Certbot for use with nginx port 80 conflict

Help
21

Figured out webroot, though I continue to get the download error. Here's the complete dialog...

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): winvm.link
Requesting a certificate for winvm.link
Performing the following challenges:
http-01 challenge for winvm.link
Input the webroot for winvm.link: (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 winvm.link
http-01 challenge for winvm.link

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: winvm.link
  Type:   connection
  Detail: Fetching http://winvm.link/.well-known/acme-challenge/GvyAC1krRuuMJvj3-DI-KSkK9V1lr2Odf74JpiLe8I4: 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.
22

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

1 Like
23

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

server {
    listen         80;
    server_name    radarr.winvm.link;
    return         301 https://$host$request_uri;
}

server {
    listen 2443 ssl;
    server_name radarr.winvm.link;

    add_header Strict-Transport-Security "includeSubDomains" always;

    ssl_certificate	C:/ssl/winvm.link-crt.pem;
    ssl_certificate_key	C:/ssl/winvm.link-key.pem;
    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  5m;

    access_log C:/nginx/logs/radarr.winvm.link.log;

    location / {
        proxy_pass     		http://127.0.0.1:7878;
        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;

    }
}
24

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

1 Like
25

Where is the FQDN being served from?

1 Like
26

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

These are five different FQDNs:

  • radarr.winvm.link
  • sonarr.winvm.link
  • bazarr.winvm.link
  • sabnzbd.winvm.link
  • qbt.winvm.link
1 Like
27

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;
        server_name .example.com; 
        # simplified form -- see http://nginx.org/en/docs/http/server_names.html

        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
28

@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:

29

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

30

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

31

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
32

@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.

33

server_name .example.com

means

server_name example.com *.example.com

1 Like
34

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

2 Likes
35

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

server_name example.com www.example.com blog.example.com *.example.com

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.

2 Likes
36

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): winvm.link
Requesting a certificate for winvm.link
Performing the following challenges:
http-01 challenge for winvm.link
Input the webroot for winvm.link: (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 winvm.link
http-01 challenge for winvm.link

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: winvm.link
  Type:   connection
  Detail: Fetching http://winvm.link/.well-known/acme-challenge/GvyAC1krRuuMJvj3-DI-KSkK9V1lr2Odf74JpiLe8I4: 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.
37

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:

http://winvm.link/.well-known/acme-challenge/(name 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 winvm.link 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.

2 Likes
38

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

http://winvm.link/.well-known/acme-challenge/

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, radarr.winvm.link, I must add the port 2443 to the url, so radarr.winvm.link:2443

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.

39

"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?

3 Likes
40

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.

2 Likes