The Certificate Authority failed to download the challenge files from the temporary standalone webserver

My domain is:
personal24.darknet.page

I ran this command:
certbot certonly --standalone

It produced this output:

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: personal24.darknet.page
Type: connection
Detail: 80.108.248.36: Fetching http://personal24.darknet.page/.well-known/acme-challenge/v3az1deGEui3HRC4kPRe68tRlmqPeqem55S-QT9sCBw: Error getting validation data

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

My web server is (include version):
apache(nextcloud)

The operating system my web server runs on is (include version):
Fedora Server kernel 5.19.4-200.fc36

My hosting provider, if applicable, is:
self hosted

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

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

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

Other:
Since I do portforwarding from my router, the routers ip and the servers ip are different, but they are successfully connected(I can connect to my server using the domain via ssh).

when scanning with nmap:
80/tcp filtered http

Welcome to the community @Bkeinn

It seems to me you could use Apache to handle the http challenge. But, to debug your standalone try adding:

certbot certonly --standalone --debug-challenges -v --dry-run

certbot will start its standalone server and pause. Leaving it paused you can check port 80 with nmap. certbot will also show you the URL needed to satisfy the challenge. You can try that from another machine from outside your local network (like a cell phone with wifi off).

The --dry-run just uses the Let's Encrypt test system so you don't have problems with Rate Limits on the production system until you have it working.

5 Likes

I think I managed to solve this problem but I still am not able to visit the website.
The Error: SEC_ERROR_UNKNOWN_ISSUER
https://personal24.darknet.page/

Peer's Certificate issuer is not recognised.

HTTP Strict Transport Security: true

HTTP Public Key Pinning: false

Certificate chain:

-----BEGIN CERTIFICATE-----

Does Firefox not trust lets encript

There's no Let's Encrypt certificate installed, but some kind of self-signed certificate. Note that when using certonly, Certbot does not install the certificate into a webserver. Please install the newly issued certificate into the appropriate webserver and try again.

4 Likes

What is the version of Firefox you are using? And on what Operating System and version?

2 Likes

104.0 on Fedora

I believe that Mozilla Firefox 104 has the proper LE root CA certificates in it (I know it does on Windows 10)

1 Like

As @Osiris already noted, your standalone command only got a cert. You must configure Apache yourself to use it. Had you chosen the --apache plug-in for certbot it may have configured it for you. It's fine if you want to do you own but you must do it.

Refer to this mozilla page and enter your versions for suggestions

3 Likes

Where does the current command save the key file

The private key is in privkey.pem in the same folder you find the fullchain.pem file:

So, /etc/letsencrypt/live/personal24.darknet.page/

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.