Setup server for ACME certificate request

When I try to request a certificate, using certbot run, it fails with

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: lubel.me
  Type:   unauthorized
  Detail: 3.33.251.168: Invalid response from http://lubel.me/.well-known/acme-challenge/yaou05cxqC334XiFC2Aty0s8wHFmY1mpXORWNodcdGU: 403

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

When I try to point my browser at my static IP to check nginx is accessible from the Internet, it fails with

Forbidden
Rejected request from RFC1918 IP to public server address

I know you would like me to provide all the software and OS types and versions but I have a slightly more fundamental misunderstanding from the many (somewhat contradictory) examples available on the Web. If the answer to the following question doesn't set things right, I'll post all the more intimate details in a new question.

All the examples are very specific to the OS or Webserver being used but (insofar as I can see) don't explain the principles. I'm very much a 'teach a man to fish' not a 'give a man a fish' person and so what I'd really appreciate is a simple explanation of the concepts and principles. The main confusion for me is: does certbot want to look in:

  • /srv/www/letsencrypt/ OR
  • /srv/www/lubel.me/ OR
  • /srv/www/lubel.me/letsencrypt OR
  • some other path?

I'm on OpenSuSe Tumbleweed and the nginx config seems to be in /etc/nginx/nginx.conf, which has an events section and a longer http section, which includes an include conf.d/*.conf; statement but conf.d is empty
Snippet of conf file - is this the correct config file in OpenSuSe?

events {
        multi_accept on;
        worker_connections 1024;
}

http {
        include mime.types;
        default_type application/octet-stream;

        #log_format main '$time_local - $http_host - $remote_addr - $status "$request" $body_bytes_sent - $http_referer - "$http_user_agent"';
        #access_log /var/log/nginx/access.log main;

        http2 on;
        sendfile on;
        #tcp_nopush on;
        #tcp_nodelay on;

        #keepalive_timeout 0;
        keepalive_timeout 70;

        #gzip on;

        include conf.d/*.conf;

        server {
                listen 80;
        #       server_name localhost;
                server_name lubel.me;

                # Include location directive for Let's Encrypt ACME Challenge
                include /etc/nginx/snippets/letsencrypt-acme-challenge.conf;
                # ------------------------------------------------------------



                #access_log /var/log/nginx/host.access.log main;

                location / {
                        #                       root /srv/www/htdocs;
                        root /srv/www/lubel.me;
                        index index.html index.htm;
                        autoindex on;
                        autoindex_exact_size off;
                        autoindex_format html;
                        autoindex_localtime on;
                }
        include vhosts.d/*.conf;
}

File hierarchy of served content - Probably needs a tidy up?

tree -L 5 -a /srv/www/lubel.me
/srv/www/lubel.me
β”œβ”€β”€ html
β”‚   β”œβ”€β”€ index.html
β”‚   └── letsencrypt
β”‚       └── .well-known
β”‚           └── acme-challenge
β”‚               └── index.html
└── .well-known
    └── acme-challenge
        └── ping.txt

forgot to mention permissiosn

[drwxr-xr-x greg    ]  /srv/www/lubel.me
[drwxr-xr-x greg    ]  /srv/www/lubel.me/html
[drwxr-xr-x root    ]  /srv/www/lubel.me/html/letsencrypt
[drwxr-xr-x root    ]  /srv/www/lubel.me/html/letsencrypt/.well-known
[drwxr-xr-x root    ]  /srv/www/lubel.me/html/letsencrypt/.well-known/acme-challenge
[drwxr-xr-x greg    ]  /srv/www/lubel.me/.well-known
[drwxr-xr-x greg    ]  /srv/www/lubel.me/.well-known/acme-challenge

changed root perms

[drwxr-xr-x greg    ]  /srv/www/lubel.me
[drwxr-xr-x greg    ]  /srv/www/lubel.me/html
[drwxr-xr-x greg    ]  /srv/www/lubel.me/html/letsencrypt
[drwxr-xr-x greg    ]  /srv/www/lubel.me/html/letsencrypt/.well-known
[drwxr-xr-x greg    ]  /srv/www/lubel.me/html/letsencrypt/.well-known/acme-challenge
[drwxr-xr-x greg    ]  /srv/www/lubel.me/.well-known
[drwxr-xr-x greg    ]  /srv/www/lubel.me/.well-known/acme-challenge

but same issue exists

Perhaps some of your confusion is how Certbot, an ACME Client, interacts with Let's Encrypt, the ACME Server.

Certbot's --nginx option prepares your nginx server to receive an HTTP Challenge request from the LE Server. This request comes over the public internet using the A (or AAAA) IP in the public DNS. Once the challenge is successful, the LE server will issue a certificate that Certbot retrieves and places on your system.

Currently you have 3 IP addresses in the public DNS. That won't work using the --nginx option. There are other options but I think you just have your DNS setup wrong anyway.

If you explain what these are we can help further

lubel.me.		3600	IN	A	45.13.7.37
lubel.me.		3600	IN	A	3.33.251.168
lubel.me.		3600	IN	A	15.197.225.128
2 Likes
45.13.7.37

this is my correct static IP. I assumed the others (on 123reg.com) were some sort of internal specification, so I didn't want to play with those. Should I delete those associations?

Yes, probably. It depends on what those do and how you planned to use them. For example, maybe they are for a CDN or a domain name forwarding service.

But, my best guess is that you should have only the public IP for your nginx server. Those extra A records kind of look like a domain name forwarding service to me. That's a common GoDaddy thing we see and 123reg is owned by them so ...

You thought by eliminating answers things would be easier. Those answers help us understand more of your intentions.

3 Likes

Just been on to 123reg and the other two records were automatic additions to do with a spurious 'forwarding group' I'd set up (my misunderstanding)

(Sorry about my presumption)

Having removed the forward group and seen the other IP addresses disappear, is there a delay before certbot stops giving me

  Domain: lubel.me
  Type:   connection
  Detail: 45.13.7.37: Fetching http://lubel.me/.well-known/acme-challenge/zQAaLQYmrXtD0DMuOdelM6RVUisSyUdVwwCktOOIwrg: Connection refused

and my browser

Forbidden
Rejected request from RFC1918 IP to public server address

or are my permissions still wrong?

What should I post to give you what you need?

RFC1918 specifies private IP addresses, meaning that there is a private IP address attempting to communicate with a public IP address.

3 Likes


Would this be anything relevant?

That indicates a firewall or something else that is actively refusing connections to your domain. Since it shows your public IP we know it is using the right IP. This is a good test site: Let's Debug

This isn't related to your connection problem, but ...

Normally the server block for your domains are placed in separate config files

Different distros have different styles. Yours is described here: Nginx - openSUSE Wiki

It is fine to leave that "localhost" one in nginx.conf. Just create a new file in the location described at that page for your new server block for your domain name.

3 Likes

Thanks @MikeMcQ . I'll dig a little further

Thanks to you and @griffin for your helpful insights

3 Likes

Now would be a good time to answer those other questions :slight_smile:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

The version of my client is (e.g. output of certbot --version):

3 Likes

If you can, please provide a screenshot regarding that RFC error you're seeing. Which machine are you seeing that on?

3 Likes

Answers inserted above, against sections

That's on my Firerfox on my Linux Desktop (permanently on) see post above for OS details.

PC firewall is off but my Router firewall is on (OpenWRT - latest version) - I can post rules, if that's helpful?

Should mention that NGINX is also running on that PC

Hurrah. I now have a certificate, installed by certbot.
The last hurdle was setting up two firewall rules on my OpenWRT router to forward port 80 and port 443 to my NGINX server (on my PC)

Thanks guys

2 Likes

I think that RFC1918 message involves router "hair pinning". Looks like your router does not allow it or isn't setup for it.

I don't know a lot about that and it's not related to Let's Encrypt anyway.

3 Likes