Runing letsencrypt container failed with error

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: thetradinghall.com

I ran this command:

podman run --name letsencrypt -it -e PUID=0 -e GUID=0 -e TZ=Europe/Paris -e URL=thetradinghall.com -e SUBDOMAINS=www, -e VALIDATION=http -e staging=true -p 443:443 -v /etc/letsencrypt:/config:Z docker.io/linuxserver/letsencrypt

It produced this output:

DH parameters successfully created - 2048 bits
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are:  -d www.thetradinghall.com
No e-mail address entered or address invalid
http validation is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Registering without email!
An unexpected error occurred:
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 160, in _new_conn
    (self._dns_host, self.port), self.timeout, **extra_kw)
  File "/usr/lib/python3.7/site-packages/urllib3/util/connection.py", line 57, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/lib/python3.7/socket.py", line 748, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Try again

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 603, in urlopen
    chunked=chunked)
  File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 344, in _make_request
    self._validate_conn(conn)
  File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 843, in _validate_conn
    conn.connect()
  File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 316, in connect
    conn = self._new_conn()
  File "/usr/lib/python3.7/site-packages/urllib3/connection.py", line 169, in _new_conn
    self, "Failed to establish a new connection: %s" % e)
urllib3.exceptions.NewConnectionError: <urllib3.connection.VerifiedHTTPSConnection object at 0x7f08f851d6a0>: Failed to establish a new connection: [Errno -3] Try again

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
    timeout=timeout
  File "/usr/lib/python3.7/site-packages/urllib3/connectionpool.py", line 641, in urlopen
    _stacktrace=sys.exc_info()[2])
  File "/usr/lib/python3.7/site-packages/urllib3/util/retry.py", line 399, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f08f851d6a0>: Failed to establish a new connection: [Errno -3] Try again'))

During handling of the above exception, another exception occurred:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f08f851d6a0>: Failed to establish a new connection: [Errno -3] Try again'))
Please see the logfiles in /var/log/letsencrypt for more details.
ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container

My web server is (include version):
nginx-1.14.2-2.fc29.x86_64

The operating system my web server runs on is (include version):
NAME=Fedora
VERSION=“29.20190805.0 (Atomic Host)”
ID=fedora
VERSION_ID=29

My hosting provider, if applicable, is:
gandi

I can login to a root shell on my machine (yes or no, or I don’t know):
I can ssh my server as regular user then sudo. No root loging via ssh

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
docker.io/linuxserver/letsencrypt container

Hi @gabx

I don’t know how that client works.

But checking your domain there was an older check - 20 minutes old - https://check-your-website.server-daten.de/?q=thetradinghall.com

You have ipv4- and ipv6 - addresses.

Host T IP-Address is auth. ∑ Queries ∑ Timeout
thetradinghall.com A 83.166.144.177 Geneva/Switzerland (CH) - Infomaniak Network SA Hostname: ov-6e2c0a.infomaniak.ch yes 1 0
AAAA 2001:1600:4:8:f816:3eff:fe2e:4f73 Carouge/Geneva/Switzerland (CH) - Infomaniak Network SA yes

Letsencrypt prefers ipv6. But checking /.well-known/acme-challenge/random-filename there is a http status 200 - not the expected 404.

Domainname Http-Status redirect Sec. G
http://thetradinghall.com/
83.166.144.177 200 0.054 H
http://thetradinghall.com/
2001:1600:4:8:f816:3eff:fe2e:4f73 200 0.060 H
https://thetradinghall.com/
83.166.144.177 -2 1.070 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 83.166.144.177:443
https://thetradinghall.com/
2001:1600:4:8:f816:3eff:fe2e:4f73 -2 1.087 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2001:1600:4:8:f816:3eff:fe2e:4f73]:443
http://thetradinghall.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
83.166.144.177 200 0.053
Visible Content: Welcome to nginx on TheTradingHall.com This page is used to test the proper operation of the nginx HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly. Website Administrator This is the default index.html page that is distributed with nginx on Fedora. It is located in /usr/share/nginx/html . You should now put your content in a location of your choice and edit the root configuration directive in the nginx configuration file /etc/nginx/nginx.conf .
http://thetradinghall.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2001:1600:4:8:f816:3eff:fe2e:4f73 200 0.060
Visible Content: Welcome to nginx on TheTradingHall.com This page is used to test the proper operation of the nginx HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly. Website Administrator This is the default index.html page that is distributed with nginx on Fedora. It is located in /usr/share/nginx/html . You should now put your content in a location of your choice and edit the root configuration directive in the nginx configuration file /etc/nginx/nginx.conf .

Your older check has only V-results, now ipv4 and ipv6 are working.

But why is there a http status 200?

PS: Can your server talk with Letsencrypt?

curl https://api...

Following this thread , all the commands asked have been ran fine from my server.
As for talking to letsencrypt, I can show you this:

curl -v https://acme-v01.api.letsencrypt.org/directory 
*   Trying 2a02:26f0:3000:299::3a8e...
* TCP_NODELAY set
* Connected to acme-v01.api.letsencrypt.org (2a02:26f0:3000:299::3a8e) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=acme-v02.api.letsencrypt.org
*  start date: Jul 19 04:46:54 2019 GMT
*  expire date: Oct 17 04:46:54 2019 GMT
*  subjectAltName: host "acme-v01.api.letsencrypt.org" matched cert's "acme-v01.api.letsencrypt.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> GET /directory HTTP/1.1
> Host: acme-v01.api.letsencrypt.org
> User-Agent: curl/7.61.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Content-Type: application/json
< Content-Length: 658
< Replay-Nonce: qFSKcE5i9zpYCN5VblT9QplSuQfnmdO_Ur-OyF3Io6M
< X-Frame-Options: DENY
< Strict-Transport-Security: max-age=604800
< Expires: Sun, 18 Aug 2019 10:41:08 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Sun, 18 Aug 2019 10:41:08 GMT
< Connection: keep-alive
< 
{
  "SXCGa2XAw_o": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "key-change": "https://acme-v01.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org"
  },
  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
  "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",
  "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",
  "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"
* Connection #0 to host acme-v01.api.letsencrypt.org left intact
}#   

or this:

head -c 50 /dev/urandom | base64 | curl -v -d @- -X POST -i -m 10 -H 'Expect:' https://acme-v02.api.letsencrypt.org/acme/new-acct
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 2a02:26f0:3000:299::3a8e...
* TCP_NODELAY set
* Connected to acme-v02.api.letsencrypt.org (2a02:26f0:3000:299::3a8e) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=acme-v02.api.letsencrypt.org
*  start date: Jul 19 04:46:54 2019 GMT
*  expire date: Oct 17 04:46:54 2019 GMT
*  subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> POST /acme/new-acct HTTP/1.1
> Host: acme-v02.api.letsencrypt.org
> User-Agent: curl/7.61.1
> Accept: */*
> Content-Length: 68
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 68 out of 68 bytes
< HTTP/1.1 415 Unsupported Media Type
HTTP/1.1 415 Unsupported Media Type
< Server: nginx
Server: nginx
< Content-Type: application/problem+json
Content-Type: application/problem+json
< Content-Length: 168
Content-Length: 168
< Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
< Replay-Nonce: XHjLiIlo9XgELT0N11eX7J4kNNru-XBxFn7CbwkwoKQ
Replay-Nonce: XHjLiIlo9XgELT0N11eX7J4kNNru-XBxFn7CbwkwoKQ
< Expires: Sun, 18 Aug 2019 10:38:50 GMT
Expires: Sun, 18 Aug 2019 10:38:50 GMT
< Cache-Control: max-age=0, no-cache, no-store
Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
Pragma: no-cache
< Date: Sun, 18 Aug 2019 10:38:50 GMT
Date: Sun, 18 Aug 2019 10:38:50 GMT
< Connection: close
Connection: close

< 
{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Invalid Content-Type header on POST. Content-Type must be \"application/jose+json\"",
  "status": 415
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
}#                                                                                                                                                                                                                 root@thetradinghall➤➤ ~ # head -c 30000 /dev/urandom | base64 | curl -v -d @- -X POST -i -m 10 -H 'Expect:' https://acme-v02.api.letsencrypt.org/acme/new-acct
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 2a02:26f0:3000:28b::3a8e...
* TCP_NODELAY set
* Connected to acme-v02.api.letsencrypt.org (2a02:26f0:3000:28b::3a8e) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=acme-v02.api.letsencrypt.org
*  start date: Jul 19 04:46:54 2019 GMT
*  expire date: Oct 17 04:46:54 2019 GMT
*  subjectAltName: host "acme-v02.api.letsencrypt.org" matched cert's "acme-v02.api.letsencrypt.org"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> POST /acme/new-acct HTTP/1.1
> Host: acme-v02.api.letsencrypt.org
> User-Agent: curl/7.61.1
> Accept: */*
> Content-Length: 40000
> Content-Type: application/x-www-form-urlencoded
> 
* We are completely uploaded and fine
< HTTP/1.1 415 Unsupported Media Type
HTTP/1.1 415 Unsupported Media Type
< Server: nginx
Server: nginx
< Content-Type: application/problem+json
Content-Type: application/problem+json
< Content-Length: 168
Content-Length: 168
< Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
< Replay-Nonce: kZ3g04aFuAW0eBNrYvzmlTwtGk7fRpsjRC_HkyotMRw
Replay-Nonce: kZ3g04aFuAW0eBNrYvzmlTwtGk7fRpsjRC_HkyotMRw
< Expires: Sun, 18 Aug 2019 10:40:21 GMT
Expires: Sun, 18 Aug 2019 10:40:21 GMT
< Cache-Control: max-age=0, no-cache, no-store
Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
Pragma: no-cache
< Date: Sun, 18 Aug 2019 10:40:21 GMT
Date: Sun, 18 Aug 2019 10:40:21 GMT
< Connection: close
Connection: close

< 
{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Invalid Content-Type header on POST. Content-Type must be \"application/jose+json\"",
  "status": 415
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
}#                                                         

so I would say yes, I can talk to letsencrypt.

I do think I made a mistake as nginx is not listening on 443. I will check my configuration files.

The 443 port isn’t relevant if there is no redirect http -> https.

More important: Where does that tool create the validation file? Is it possible to test that? And why has /.well-known/acme-challenge/random-filename a 200, not a 404?

basic question: 443 is not set yet on myNginx configuration.Am I right to install first Letsencrypt and then configure ssl?
Following free ssl website, I placed files on my html root/.wellknown/acme_challenge. Following the procedure, I got this error:

Domain "thetradinghall.com" challenge3 failed. Response from "https://acme-v02.api.letsencrypt.org/acme/challenge/9YpKUKuQPPIg4UAjTAcY_AYwXgYelnPvF1zvCmIk_pQ/19698693335" was:

Warning: Your verification URL is not returning the correct contents to our verification servers. The URL looks like it is blocking bots and which inadvertently blocks our servers from receiving the correct content. Contact your host, a professional developer or admin for further help with fixing it.

Error: Invalid response from http://thetradinghall.com/.well-known/acme-challenge/9zW8pIB-2MrVJoDgNf9GjJf5H1MvDpnm3Ayo-lcROD4 [2001:1600:4:8:f816:3eff:fe2e:4f73]: "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.1//EN\" \"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd\">\n\n<html xmlns=\"http://www.w3.or"

Full Error: { "type": "http-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Invalid response from http://thetradinghall.com/.well-known/acme-challenge/9zW8pIB-2MrVJoDgNf9GjJf5H1MvDpnm3Ayo-lcROD4 [2001:1600:4:8:f816:3eff:fe2e:4f73]: \"\u003c!DOCTYPE html PUBLIC \\\"-//W3C//DTD XHTML 1.1//EN\\\" \\\"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd\\\"\u003e\\n\\n\u003chtml xmlns=\\\"http://www.w3.or\"", "status": 403 }, "url": "https://acme-v02.api.letsencrypt.org/acme/challenge/9YpKUKuQPPIg4UAjTAcY_AYwXgYelnPvF1zvCmIk_pQ/19698693335", "token": "9zW8pIB-2MrVJoDgNf9GjJf5H1MvDpnm3Ayo-lcROD4", "validationRecord": [ { "url": "http://thetradinghall.com/.well-known/acme-challenge/9zW8pIB-2MrVJoDgNf9GjJf5H1MvDpnm3Ayo-lcROD4", "hostname": "thetradinghall.com", "port": "80", "addressesResolved": [ "83.166.144.177", "2001:1600:4:8:f816:3eff:fe2e:4f73" ], "addressUsed": "2001:1600:4:8:f816:3eff:fe2e:4f73" } ] }

Not sure if it can help. I am sure of my firewall, so the only question remaining is a possible SELinux issue (it is enforced on my server).

Looks like this

isn’t the correct root.

Again - there is a http status 200 - not 404, checking /.well-known/acme-challenge/random-filename

Domainname Http-Status redirect Sec. G
http://thetradinghall.com/
83.166.144.177 200 0.053 H
http://thetradinghall.com/
2001:1600:4:8:f816:3eff:fe2e:4f73 200 0.060 H
https://thetradinghall.com/
83.166.144.177 -2 1.070 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it 83.166.144.177:443
https://thetradinghall.com/
2001:1600:4:8:f816:3eff:fe2e:4f73 -2 1.084 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2001:1600:4:8:f816:3eff:fe2e:4f73]:443
http://thetradinghall.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
83.166.144.177 200 0.053
Visible Content: Welcome to nginx on TheTradingHall.com This page is used to test the proper operation of the nginx HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly. Website Administrator This is the default index.html page that is distributed with nginx on Fedora. It is located in /usr/share/nginx/html . You should now put your content in a location of your choice and edit the root configuration directive in the nginx configuration file /etc/nginx/nginx.conf .
http://thetradinghall.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2001:1600:4:8:f816:3eff:fe2e:4f73 200 0.060
Visible Content: Welcome to nginx on TheTradingHall.com This page is used to test the proper operation of the nginx HTTP server after it has been installed. If you can read this page, it means that the web server installed at this site is working properly. Website Administrator This is the default index.html page that is distributed with nginx on Fedora. It is located in /usr/share/nginx/html . You should now put your content in a location of your choice and edit the root configuration directive in the nginx configuration file /etc/nginx/nginx.conf .

Why is there the standard nginx page? Why not a http status 404 - Not Found?

It’s a problem of your nginx vHost configuration.

Here is my very basic configuration Nginx

root@thetradinghall➤➤ ~ # cat /etc/nginx/conf.d/10-thetradinghall.com.conf 
# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/



    

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  thetradinghall.com www.thetradinghall.com;
        root         /var/lib/nginx/html;
		index index.html;
		try_files $uri /index.html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location ~ /.well-known/acme_challenge {
			allow all;
			root /var/libg/nginx/html;  ## NOTE a typo here: libg instead of lib !!
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

I found a typo above. I corrected it, but the issue remains.

total 0
drwxr-xr-x. 2 nginx root system_u:object_r:httpd_var_lib_t:s0  6 Aug 18 13:55 ./
drwxr-xr-x. 3 nginx root system_u:object_r:httpd_var_lib_t:s0 28 Aug 16 17:34 ../

Again, following free ssl process, I am now able to curl the random characters, when it didn’t work a few hours before (probably to the typo in my nginx conf file).

 # ls -al /var/lib/nginx/html/.well-known/acme_challenge 
total 8.0K
drwxr-xr-x. 2 nginx root 108 Aug 18 14:00 ./
drwxr-xr-x. 3 nginx root  28 Aug 16 17:34 ../
-rw-r--r--. 1 nginx root  87 Aug 18 13:59 GNkQjx_Fro2YtWbmy_vDYWyB8BJLnpwEfmKuDCpqs7w
-rw-r--r--. 1 nginx root  87 Aug 18 13:59 K9CfGEmSh9jd6gBDU6hDNkQ-0fSIU8vDvvFfPkf6RnI
 # curl http://thetradinghall.com/.well-known/acme_challenge/GNkQjx_Fro2YtWbmy_vDYWyB8BJLnpwEfmKuDCpqs7w
GNkQjx_Fro2YtWbmy_vDYWyB8BJLnpwEfmKuDCpqs7w.qwdrbx3eZm37j8xTwXhZB0PNaTCwsyatK14F0c-wOO0#   
# curl http://thetradinghall.com/.well-known/acme_challenge/K9CfGEmSh9jd6gBDU6hDNkQ-0fSIU8vDvvFfPkf6RnI
K9CfGEmSh9jd6gBDU6hDNkQ-0fSIU8vDvvFfPkf6RnI.qwdrbx3eZm37j8xTwXhZB0PNaTCwsyatK14F0c-wOO0#  

Not sure if it can help.

That’s your normal root.

So your location definition

doesn’t work, perhaps there is a missing ., it’s RegEx, so you have to mask the dot.

PS: But rechecked your first output, there is a standalone used. So now use your running webserver with your normal webroot /var/lib/nginx/html/.

Apart the typo, which didn’t help at all, I found SELinux issues running this command:

# sealert -a /var/log/audit/audit.log
....
SELinux is preventing certbot from write access on the directory letsencrypt.

That was my first alert. So I need now to read doc on how to fix this issue.
NOTE: I tried to run a cerbot container before, so maybe this message was due to my test.

1 Like

Back to basic: I installed the certbot packages for Fedora and ran it successfully. I will decide if I still give a try to container (with all these access right issues) or write a systemd timer to run certbot.

Thank you for your help

The package you installed probably already includes a timer. (It’s named certbot-renew, I think.)

If you want to customize its behavior – like to reload a server, or something – you may want to set up a deploy hook.

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