Problem with LetsEncrypt - Renew

Troubleshooting
1

Hello!
I just got an email that my LetsEncrypt is about to run out. Seeing what went wrong with the autorenewal:

root@DietPi:~# certbot renew 
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/my_domain.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for my_domain
Cleaning up challenges
Attempting to renew cert (my_domain) from /etc/letsencrypt/renewal/my_domain.conf produced an unexpected error: Missing command line flag or config entry for this setting:
Input the webroot for my_domain:. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/my_domain/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/my_domain/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)




root@DietPi:~# cat /etc/letsencrypt/renewal/my_domain.conf
# renew_before_expiry = 30 days
version = 0.31.0
archive_dir = /etc/letsencrypt/archive/my_domain
cert = /etc/letsencrypt/live/my_domain/cert.pem
privkey = /etc/letsencrypt/live/my_domain/privkey.pem
chain = /etc/letsencrypt/live/my_domain/chain.pem
fullchain = /etc/letsencrypt/live/my_domain/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = somelongnumber
rsa_key_size = 4096
authenticator = webroot
webroot_path = /var/www,
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]

Any ideas how to fix this? :slight_smile:

2

Hi,

did you had a look into log file /var/log/letsencrypt/letsencrypt.log? Maybe this will give some more detailed information.

3

Does the log file contain any more info?

cat /var/log/letsencrypt/letsencrypt.log

When the hourly cron cleared the RAMlog already, you need to rerun certbot renew to generate a fresh log.

4

The log’s pretty long, this should cover the relevant parts:

2021-05-17 00:57:22,516:DEBUG:certbot.main:certbot version: 0.31.0
2021-05-17 00:57:22,520:DEBUG:certbot.main:Arguments: []
2021-05-17 00:57:22,521:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2021-05-17 00:57:22,547:DEBUG:certbot.log:Root logging level set at 20
2021-05-17 00:57:22,548:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2021-05-17 00:57:22,573:DEBUG:certbot.plugins.selection:Requested authenticator <certbot.cli._Default object at 0x7fa2eae6a0> and installer <certbot.cli._Default object at 0x7fa2eae6a0>
2021-05-17 00:57:22,594:DEBUG:certbot.storage:Should renew, less than 30 days before certificate expiry 2021-06-05 15:18:05 UTC.
2021-05-17 00:57:22,595:INFO:certbot.renewal:Cert is due for renewal, auto-renewing...
2021-05-17 00:57:22,595:DEBUG:certbot.plugins.selection:Requested authenticator webroot and installer None
2021-05-17 00:57:22,596:DEBUG:certbot.plugins.selection:Single candidate plugin: * webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator
Initialized: <certbot.plugins.webroot.Authenticator object at 0x7fa2f03940>
Prep: True
2021-05-17 00:57:22,597:DEBUG:certbot.plugins.selection:Selected authenticator <certbot.plugins.webroot.Authenticator object at 0x7fa2f03940> and installer None
2021-05-17 00:57:22,597:INFO:certbot.plugins.selection:Plugins selected: Authenticator webroot, Installer None
2021-05-17 00:57:22,613:DEBUG:certbot.main:Picked account: <Account(RegistrationResource(body=Registration(key=None, contact=(), agreement=None, status=None, terms_of_service_agreed=None, only_return_existing=None, external_account_binding=None), uri='https://acme-v02.api.letsencrypt.org/acme/acct/100723154', new_authzr_uri=None, terms_of_service=None), 4855c380d778627e077c783b6eb342a9, Meta(creation_dt=datetime.datetime(2020, 10, 29, 17, 50, 25, tzinfo=<UTC>), creation_host='DietPi'))>
2021-05-17 00:57:22,615:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2021-05-17 00:57:22,620:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org:443
2021-05-17 00:57:23,332:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /directory HTTP/1.1" 200 658
2021-05-17 00:57:23,335:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Sun, 16 May 2021 22:57:21 GMT
Content-Type: application/json
Content-Length: 658
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "Esra89FoRrA": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}
2021-05-17 00:57:23,336:INFO:certbot.main:Renewing an existing certificate
2021-05-17 00:57:24,040:DEBUG:certbot.crypto_util:Generating key (4096 bits): /etc/letsencrypt/keys/0074_key-certbot.pem
2021-05-17 00:57:24,093:DEBUG:certbot.crypto_util:Creating CSR: /etc/letsencrypt/csr/0074_csr-certbot.pem
2021-05-17 00:57:24,095:DEBUG:acme.client:Requesting fresh nonce
2021-05-17 00:57:24,095:DEBUG:acme.client:Sending HEAD request to https://acme-v02.api.letsencrypt.org/acme/new-nonce.
2021-05-17 00:57:24,266:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "HEAD /acme/new-nonce HTTP/1.1" 200 0
2021-05-17 00:57:24,267:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Sun, 16 May 2021 22:57:22 GMT
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 00047_v-eLYns4u1tlCoYk9qq4nanBC6UrytqAdUvHNgxKM
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800


2021-05-17 00:57:24,267:DEBUG:acme.client:Storing nonce: 00047_v-eLYns4u1tlCoYk9qq4nanBC6UrytqAdUvHNgxKM
2021-05-17 00:57:24,268:DEBUG:acme.client:JWS payload:
b'{\n  "identifiers": [\n    {\n      "type": "dns",\n      "value": "my_domain"\n    }\n  ]\n}'
2021-05-17 00:57:24,312:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/new-order:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTAwNzIzMTU0IiwgIm5vbmNlIjogIjAwMDQ3X3YtZUxZbnM0dTF0bENvWWs5cXE0bmFuQkM2VXJ5dHFBZFV2SE5neEtNIiwgInVybCI6ICJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9uZXctb3JkZXIifQ",
  "signature": "aVM1MQZHA2j-vtX3aaKyWEpaBDelwpn9POdwjtNpvwZCCw4tztXqxEwnX7SKGFS7zcLKvWvs1jMdwB8aOZlla1pYJdbfZpwLf8ObMF9jbpS_7JHlHzf3pZ2_cWIlvV6eeUn4uV-m3u1PGaqlqvTcjLdEI5nlfAWe3zz-WkZ7Qh6lL0U83VHMZSOpOYe4Fy4c_ngFuchtIUFsx0hb_Ec6VG6OkKy4z-_yhQ_NczuEpTLLGLUw-87FerhmAIsS2jf195W7_K7CyW5ceFckRtq8wtcHOGvN3Qi7WcoVnyS_zFV0sNF0wgz7r9p4AKwj4hjrO-JWDxJv38w7pq_VS0nZSg5TinMEJxqrRQVWYPexwaCJtIgHBOziy_ETLAzO2V6hrLuLX0M2LuLhdn30j8CMSsh1oq-HOssh5fWPkra0fcjzI9gDnkY2YmqVoiHY-xO-UPqAjb4LnsO-yHZ7ai-8Xc6mR893xc_KpnQTRhm1o6Vjp0X-R_FkTnCwWKU-ir_YNZwh_YAeeQdfwXwzb6niKnlwnNlO7YjjYODtlN8WXy2VKpQIbKSQkthdoiELyUHtoVi82czILGRZ9tmFuuu7T3dwLW7lcM_AFmbVGvlUVqhXJzlA0YsZ-3dJah_ktSKn4Ypgt-tUSojMPseVAMxhKfedmExNfQEnyZXD73KKXYA",
  "payload": "ewogICJpZGVudGlmaWVycyI6IFsKICAgIHsKICAgICAgInR5cGUiOiAiZG5zIiwKICAgICAgInZhbHVlIjogInhlcm9uby5zdHJhbmdsZWQubmV0IgogICAgfQogIF0KfQ"
}
2021-05-17 00:57:24,512:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/new-order HTTP/1.1" 201 342
2021-05-17 00:57:24,513:DEBUG:acme.client:Received response:
HTTP 201
Server: nginx
Date: Sun, 16 May 2021 22:57:22 GMT
Content-Type: application/json
Content-Length: 342
Connection: keep-alive
Boulder-Requester: 100723154
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Location: https://acme-v02.api.letsencrypt.org/acme/order/100723154/9687398056
Replay-Nonce: 0004s5SJSTFU9Hocgr9f4R1bXd8gVSKtK1fnory4LnN0HSs
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "status": "pending",
  "expires": "2021-05-21T07:38:10Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "my_domain"
    }
  ],
  "authorizations": [
    "https://acme-v02.api.letsencrypt.org/acme/authz-v3/13104787816"
  ],
  "finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/100723154/9687398056"
}
2021-05-17 00:57:24,514:DEBUG:acme.client:Storing nonce: 0004s5SJSTFU9Hocgr9f4R1bXd8gVSKtK1fnory4LnN0HSs
2021-05-17 00:57:24,514:DEBUG:acme.client:JWS payload:
b''
2021-05-17 00:57:24,558:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/13104787816:
{
  "protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTAwNzIzMTU0IiwgIm5vbmNlIjogIjAwMDRzNVNKU1RGVTlIb2NncjlmNFIxYlhkOGdWU0t0SzFmbm9yeTRMbk4wSFNzIiwgInVybCI6ICJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9hdXRoei12My8xMzEwNDc4NzgxNiJ9",
  "signature": "qWlBxgtAhTDxD0FZJWkRol08SOU1mjOGqIGxQcEP2AJuKeHMLIJ1xwNxK-TpMdhFsH4SkmdymW5lc1OcoZwCQVH6qe43dvRZl47CVSqO1IvrkPH8bsiSDBxClj2_FNdDrQRf63wjiP5BhsL2pf7Dpxi-Y3XjlxXEZBdZ8MNDArEKKbOYBgVj4BPFh0Elg7NqiQNjDVkvW1XwWsMJ0WKvOUmo_dorT5tUrPgPBaVkVTkSr3UodjfLAxp4Jq5Zkw6LMXdESbZCWvagdtvSfLLEcCmDiukWfobMrOqWfIq6wbk0lGh2tqejJpENPhjbv3VKPg6DCfq5uo6FhU8wpZ_QfLXZ5YwOpkziu5Ve5ef3Y1zkbm1wVZp8T9o-lUchEWDq84GhBuVw3srgWthmJF-T48_wmqQDRy1ph5hf9lcO040G_LpQPr19S6mrnqjbPac-_ZlioBoANzzRpE3-BAjpuA3ts-Sw2hxMtkxoBDhE9_cQbmZkQ5ygS3n_POR2ddaAcMG_FLrTNFTdl0qrBjTBh3YyIdoR6Fcaim2HRw2U3Pg7j_4DiaH9ySQ2Nsa4HsL3aqGJDQ9IgENT7tQtxlH6_-wDj1zHfv6j8bY2knNXCoLCI9MJE29CSaU3EKYf6VlCN5LMhcOcEh9aL-6kN8atrrqiB4OpekS44tXasQq4-Ts",
  "payload": ""
}
2021-05-17 00:57:24,758:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/13104787816 HTTP/1.1" 200 801
2021-05-17 00:57:24,760:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Sun, 16 May 2021 22:57:23 GMT
Content-Type: application/json
Content-Length: 801
Connection: keep-alive
Boulder-Requester: 100723154
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 0004DGXYRiqQp7lSMQVhjfwJElJCTF8_lh_KJXbtvlo0gRQ
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "my_domain"
  },
  "status": "pending",
  "expires": "2021-05-21T07:38:10Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/13104787816/tK3iyA",
      "token": "XYHXtRrzEkwEahLFRqKGe1rnCeBQmIX0MKZ_AHaZpuk"
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/13104787816/6p0xFw",
      "token": "XYHXtRrzEkwEahLFRqKGe1rnCeBQmIX0MKZ_AHaZpuk"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/13104787816/s77amQ",
      "token": "XYHXtRrzEkwEahLFRqKGe1rnCeBQmIX0MKZ_AHaZpuk"
    }
  ]
}
2021-05-17 00:57:24,760:DEBUG:acme.client:Storing nonce: 0004DGXYRiqQp7lSMQVhjfwJElJCTF8_lh_KJXbtvlo0gRQ
2021-05-17 00:57:24,762:INFO:certbot.auth_handler:Performing the following challenges:
2021-05-17 00:57:24,762:INFO:certbot.auth_handler:http-01 challenge for my_domain
2021-05-17 00:57:24,765:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 75, in handle_authorizations
    resp = self._solve_challenges(aauthzrs)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 139, in _solve_challenges
    resp = self.auth.perform(all_achalls)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 81, in perform
    self._set_webroots(achalls)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 99, in _set_webroots
    known_webroots)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 120, in _prompt_for_webroot
    webroot = self._prompt_for_new_webroot(domain, True)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 144, in _prompt_for_new_webroot
    force_interactive=True)
  File "/usr/lib/python3/dist-packages/certbot/display/ops.py", line 372, in validated_directory
    validator, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/certbot/display/ops.py", line 329, in _get_validated
    code, raw = method(message, default=default, **kwargs)
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 583, in directory_select
    return self.input(message, default, cli_flag)
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 524, in input
    self._interaction_fail(message, cli_flag)
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 469, in _interaction_fail
    raise errors.MissingCommandlineFlag(msg)
certbot.errors.MissingCommandlineFlag: Missing command line flag or config entry for this setting:
Input the webroot for my_domain:

2021-05-17 00:57:24,765:DEBUG:certbot.error_handler:Calling registered functions
2021-05-17 00:57:24,766:INFO:certbot.auth_handler:Cleaning up challenges
2021-05-17 00:57:24,766:DEBUG:certbot.plugins.webroot:All challenges cleaned up
2021-05-17 00:57:24,767:WARNING:certbot.renewal:Attempting to renew cert (my_domain) from /etc/letsencrypt/renewal/my_domain.conf produced an unexpected error: Missing command line flag or config entry for this setting:
Input the webroot for my_domain:. Skipping.
2021-05-17 00:57:24,769:DEBUG:certbot.renewal:Traceback was:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 465, in handle_renewal_request
    main.renew_cert(lineage_config, plugins, renewal_candidate)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1193, in renew_cert
    renewed_lineage = _get_and_save_cert(le_client, config, lineage=lineage)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 116, in _get_and_save_cert
    renewal.renew_cert(config, domains, le_client, lineage)
  File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 323, in renew_cert
    new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 353, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 389, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 75, in handle_authorizations
    resp = self._solve_challenges(aauthzrs)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 139, in _solve_challenges
    resp = self.auth.perform(all_achalls)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 81, in perform
    self._set_webroots(achalls)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 99, in _set_webroots
    known_webroots)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 120, in _prompt_for_webroot
    webroot = self._prompt_for_new_webroot(domain, True)
  File "/usr/lib/python3/dist-packages/certbot/plugins/webroot.py", line 144, in _prompt_for_new_webroot
    force_interactive=True)
  File "/usr/lib/python3/dist-packages/certbot/display/ops.py", line 372, in validated_directory
    validator, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/certbot/display/ops.py", line 329, in _get_validated
    code, raw = method(message, default=default, **kwargs)
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 583, in directory_select
    return self.input(message, default, cli_flag)
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 524, in input
    self._interaction_fail(message, cli_flag)
  File "/usr/lib/python3/dist-packages/certbot/display/util.py", line 469, in _interaction_fail
    raise errors.MissingCommandlineFlag(msg)
certbot.errors.MissingCommandlineFlag: Missing command line flag or config entry for this setting:
Input the webroot for my_domain:

2021-05-17 00:57:24,770:ERROR:certbot.renewal:All renewal attempts failed. The following certs could not be renewed:
2021-05-17 00:57:24,770:ERROR:certbot.renewal:  /etc/letsencrypt/live/my_domain/fullchain.pem (failure)
2021-05-17 00:57:24,771:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.31.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1365, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1272, in renew
    renewal.handle_renewal_request(config)
  File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 490, in handle_renewal_request
    len(renew_failures), len(parse_failures)))
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
root@DietPi:~#

Since the webroot is in the .conf file, I’m not sure how to proceed.

5

not sure if this is related but I see all status values in state pending

{
  "status": "pending",
  "expires": "2021-05-21T07:38:10Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "my_domain"
    }

But it should be “status”: “valid”. At least this is how my log file looks after a short test

{
  "status": "valid",
  "expires": "2021-05-23T23:23:13Z",
  "identifiers": [
    {
      "type": "dns",
      "value": "example.com"
    }

are you sure your DDNS could be resolved correctly?

6

The only thing that could stop it would be the pihole, but there’s no success either if I disable it.

I found this post which has the same problem as me, stating it’s a bug with Certbot 0.31.0 (which is the version I use). Since I can’t apt update it, can I safely (so, without screwing up my certs) uninstall cerbot via dietpi-software and reinstall it again to get the newest version?

7

you are already running latest version. There is no newer one available. dietpi-software is doing nothing else than installing the Debian package using apt

8

Oh well. It seems to be an error with my ports, after all - I added

my_domain = /var/www/

to the .conf file, and now the error says

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: my_domain
   Type:   connection
   Detail: Fetching
   http://my_domain/.well-known/acme-challenge/_2-3Te4UJhbDYLmMcTgCuBjZBJ1rtcUKf-NYQDPpHD4:
   Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Checking my ip with canyouseeme.org, it seems like port 80 is closed, and port 443 is open.
The problem is that both ports are opened in the router settings, pointing to my RasPi. I’ll get the error even if I activate the “Exposed Host” function in my router, which opens all ports.

Local IP                   	Protocol                   	Local Port                     	Public Port
My_RasPi_IP            	TCP				443					443
My_RasPi_IP		TCP				80					80

If I acess my_domain via http, I get redirected to the https version (as expected).

9

usually there is no need to add anything manually to the config files. Probably you could try to clean all available files/configs pointing to your DDNS. Just have a look to /etc/letsencrypt/ and remove everything in relation to your domain. You would need to have a look into the sub folder like

ls -la /etc/letsencrypt/*
10

If I remove the newly added line, I get the error

root@DietPi:~# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/my_domain.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for my_domain
Cleaning up challenges
Attempting to renew cert (my_domain) from /etc/letsencrypt/renewal/my_domain.conf produced an unexpected error: Missing command line flag or config entry for this setting:
Input the webroot for my_domain:. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/my_domain.net/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/my_domain/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)




root@DietPi:~# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/my_domain.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for my_domain
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (my_domain) from /etc/letsencrypt/renewal/my_domain.conf produced an unexpected error: Failed authorization procedure. my_domain (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://my_domain/.well-known/acme-challenge/mz8cfTp8KVMksHtDVvyAiOiyZPUrihYD05eRG1aFWBU: Error getting validation data. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/my_domain/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/my_domain/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: my_domain
   Type:   connection
   Detail: Fetching
   http://my_domain/.well-known/acme-challenge/mz8cfTp8KVMksHtDVvyAiOiyZPUrihYD05eRG1aFWBU:
   Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Deleting all files related to my domain should make https access impossible, right? So if I delete them, I can’t access my domain anymore, which is something I’d like to avoid, if possible, as long as the “Error getting validation data” error exists - it sounds like I can’t get a new certificate in that case.

11

hmm quite strange. What web server you are using?

as well can you post following

ss -tulpn | grep LISTEN
12 
root@DietPi:~# ss -tulpn | grep LISTEN
tcp     LISTEN   0        1024             0.0.0.0:443           0.0.0.0:*       users:(("lighttpd",pid=1110,fd=6))
tcp     LISTEN   0        5              127.0.0.1:4711          0.0.0.0:*       users:(("pihole-FTL",pid=465,fd=14))
tcp     LISTEN   0        80             127.0.0.1:3306          0.0.0.0:*       users:(("mysqld",pid=606,fd=23))
tcp     LISTEN   0        511            127.0.0.1:6379          0.0.0.0:*       users:(("redis-server",pid=539,fd=7))
tcp     LISTEN   0        1024             0.0.0.0:80            0.0.0.0:*       users:(("lighttpd",pid=1110,fd=4))
tcp     LISTEN   0        32               0.0.0.0:53            0.0.0.0:*       users:(("pihole-FTL",pid=465,fd=9))
tcp     LISTEN   0        1000             0.0.0.0:22            0.0.0.0:*       users:(("dropbear",pid=520,fd=3))
tcp     LISTEN   0        5                  [::1]:4711             [::]:*       users:(("pihole-FTL",pid=465,fd=16))
tcp     LISTEN   0        511                [::1]:6379             [::]:*       users:(("redis-server",pid=539,fd=8))
tcp     LISTEN   0        1024                [::]:80               [::]:*       users:(("lighttpd",pid=1110,fd=5))
tcp     LISTEN   0        32                  [::]:53               [::]:*       users:(("pihole-FTL",pid=465,fd=11))
tcp     LISTEN   0        1000                [::]:22               [::]:*       users:(("dropbear",pid=520,fd=4))

I’m running the basic owncloud + pihole installed via dietpi-software. Server is (as you can see) lighttpd.

Could the problem be that http requests get redirected to https by lighttpd?

13

Still I can’t replicate your issue.

even if it is not related, let’s clean your system and disable https + redirect

lighty-disable-mod dietpi-https
lighty-disable-mod dietpi-https_redirect
service lighttpd force-reload
systemctl restart lighttpd.service

let’s clear certificates

rm -r /etc/letsencrypt/*

ok try to create new cert

dietpi-letsencrypt

pls if possible post the output of dietpi-letsencrypt once done

14 
root@DietPi:~# lighty-disable-mod dietpi-https
Disabling dietpi-https
Run "service lighttpd force-reload" to enable changes
root@DietPi:~# lighty-disable-mod dietpi-https_redirect
Disabling dietpi-https_redirect
Run "service lighttpd force-reload" to enable changes
root@DietPi:~# service lighttpd force-reload
root@DietPi:~# systemctl restart lighttpd.service
root@DietPi:~# rm -r /etc/letsencrypt/*
root@DietPi:~# dietpi-letsencrypt

 DietPi-LetsEncrypt
─────────────────────────────────────────────────────
 Mode: Running Certbot

[  OK  ] DietPi-LetsEncrypt | Lighttpd webserver detected
[  OK  ] DietPi-LetsEncrypt | systemctl start lighttpd
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for my_domain
Using the webroot path /var/www for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. my_domain (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://my_domain/.well-known/acme-challenge/_ZjLIczfWAqngGccJRNRvY-3UtoByEfE8j2CFrGT2os: Error getting validation data

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: my_domain
   Type:   connection
   Detail: Fetching
   http://my_domain/.well-known/acme-challenge/_ZjLIczfWAqngGccJRNRvY-3UtoByEfE8j2CFrGT2os:
   Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
[FAILED] DietPi-LetsEncrypt | Certbot failed, please check its above terminal output. Aborting...

Press any key to return to the DietPi-LetsEncrypt menu ...

I also noticed that I still get redirected to the https version if I open http://my_domain, so I can’t access my owncloud for now. Maybe that’s the reason why certbot still doesn’t work?

15

usually we disabled https before recreating the cert.

probably it got reactivated by dietpi-letsencrypt even if the certificate could not be created.

Can you try to disable it again and check if you are able to reach your system on http? Because you still have issues to resolve the domain correctly. Are you sure your DDNS is set correctly?

lighty-disable-mod dietpi-https
lighty-disable-mod dietpi-https_redirect
service lighttpd force-reload
systemctl restart lighttpd.service
16

Looks like it was already disabled.

root@DietPi:~# lighty-disable-mod dietpi-https
Already disabled dietpi-https
Run "service lighttpd force-reload" to enable changes
root@DietPi:~# lighty-disable-mod dietpi-https_redirect
Already disabled dietpi-https_redirect
Run "service lighttpd force-reload" to enable changes
root@DietPi:~# service lighttpd force-reload
root@DietPi:~# systemctl restart lighttpd.service
root@DietPi:~#

Accessing http://my_domain still leads me to the https version (with no connection possible, because there’s not valid certificate currently). Could there be another setting that forces that redirect?

Are you sure your DDNS is set correctly?

I had no problems accessing the domain from the outside before (for about half a year, until now with the certificate problems), so I assume everything in those settings should be fine. The DDNS status is currently “updated”, too.

17

let’s check used ports

ss -tulpn | grep LISTEN

and active configs

ls -la /etc/lighttpd/conf-enabled/
18 
root@DietPi:~# ss -tulpn | grep LISTEN
tcp     LISTEN   0        5              127.0.0.1:4711          0.0.0.0:*       users:(("pihole-FTL",pid=468,fd=14))   
tcp     LISTEN   0        80             127.0.0.1:3306          0.0.0.0:*       users:(("mysqld",pid=608,fd=20))       
tcp     LISTEN   0        511            127.0.0.1:6379          0.0.0.0:*       users:(("redis-server",pid=541,fd=7))  
tcp     LISTEN   0        1024             0.0.0.0:80            0.0.0.0:*       users:(("lighttpd",pid=3040,fd=4))     
tcp     LISTEN   0        32               0.0.0.0:53            0.0.0.0:*       users:(("pihole-FTL",pid=468,fd=9))    
tcp     LISTEN   0        1000             0.0.0.0:22            0.0.0.0:*       users:(("dropbear",pid=522,fd=3))      
tcp     LISTEN   0        5                  [::1]:4711             [::]:*       users:(("pihole-FTL",pid=468,fd=18))   
tcp     LISTEN   0        511                [::1]:6379             [::]:*       users:(("redis-server",pid=541,fd=8))  
tcp     LISTEN   0        1024                [::]:80               [::]:*       users:(("lighttpd",pid=3040,fd=5))     
tcp     LISTEN   0        32                  [::]:53               [::]:*       users:(("pihole-FTL",pid=468,fd=11))   
tcp     LISTEN   0        1000                [::]:22               [::]:*       users:(("dropbear",pid=522,fd=4))      
root@DietPi:~# ls -la /etc/lighttpd/conf-enabled/
total 8
drwxr-xr-x 2 root root 4096 May 18 14:44 .
drwxr-xr-x 4 root root 4096 Feb 28 13:28 ..
lrwxrwxrwx 1 root root   33 Oct 29  2020 10-fastcgi.conf -> ../conf-available/10-fastcgi.conf
lrwxrwxrwx 1 root root   33 Oct 29  2020 10-rewrite.conf -> ../conf-available/10-rewrite.conf
lrwxrwxrwx 1 root root   37 Oct 29  2020 15-fastcgi-php.conf -> ../conf-available/15-fastcgi-php.conf
lrwxrwxrwx 1 root root   37 Oct 29  2020 98-dietpi-hsts.conf -> ../conf-available/98-dietpi-hsts.conf
lrwxrwxrwx 1 root root   45 Oct 29  2020 99-dietpi-dav_redirect.conf -> ../conf-available/99-dietpi-dav_redirect.conf
lrwxrwxrwx 1 root root   41 Oct 29  2020 99-dietpi-owncloud.conf -> ../conf-available/99-dietpi-owncloud.conf
lrwxrwxrwx 1 root root   58 Oct 29  2020 99-dietpi-pihole-block_public_admin.conf -> ../conf-available/99-dietpi-pihole-block_public_admin.conf
lrwxrwxrwx 1 root root   39 Oct 29  2020 99-dietpi-pihole.conf -> ../conf-available/99-dietpi-pihole.conf
lrwxrwxrwx 1 root root   38 Oct 29  2020 99-unconfigured.conf -> ../conf-available/99-unconfigured.conf
19

https is not active anymore. As you can see, only port 80 is used by lighttpd. As well https redirect configuration is not present. Means you system should be reachable on http. Did you tried to access the system using local IP instead of DDNS?

20

Could /conf-available/98-dietpi-hsts.conf be a problem?


Did you tried to access the system using local IP instead of DDNS?

Accessing the domain via local IP works, via public IP I get a timeout. Via URL I get “Connection failed”.