Problem in renewing certificate

jori · July 14, 2021, 10:45am

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.

My domain is:
servmin.duckdns.org

I ran this command:
certbot renew --cert-name servmin.duckdns.org --dry-run

It produced this output: Simulating renewal of an existing certificate for servmin.duckdns.org

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: servmin.duckdns.org
Type: connection
Detail: Fetching http://servmin.duckdns.org/.well-known/acme-challenge/DafWAZIdHFa7zZGDfBwxM-rsghnCERVLH5V3ik0XOEs: Timeout during connect (likely firewall problem)

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

Failed to renew certificate servmin.duckdns.org with error: Some challenges have failed.

My web server is (include version):
Server version: Apache/2.4.38 (Debian)
Server built: 2021-06-10T10:13:06

The operating system my web server runs on is (include version):
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster

My hosting provider, if applicable, is:
own server

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): no

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

What can I do about it and what is to be done to make an automatic renewing possible?

thanks for Your attention
jori

_az · July 14, 2021, 10:53am

Is 91.97.112.22 definitely the right IP address of your server?

As the timeout error suggests, it's not currently possible to connect to your webserver from the internet.

You need to have ports 80 and 443 open to the internet.

Rip · July 14, 2021, 2:17pm

This is what I am seeing @_az

servmin.duckdns.org => 85.16.203.19
2002:5b61:711f:8000:3631:c4ff:fe65:b8e3

PORT    STATE    SERVICE
22/tcp  filtered ssh
80/tcp  filtered http
443/tcp filtered https

Am I missing something?

jori · July 14, 2021, 5:35pm

hi folks,
yes, thank You, this was the first hint. There are problems with ip-forwarding on my router obviously. All over sudden, because that already worked . . .

Is this the place to keep on going with this problem? Under that public ip (http://ip:80) the running apache-webserver (debian linux testing without local firewall) should reply with its standart page. But nothing happens. Can't find anything in the logs. Apache works from/in the local network.

Where to look for the reason?
thanX
jori

griffin · July 14, 2021, 5:48pm

Welcome to the Let's Encrypt Community

This is usually not a good way to access content. It's like someone knocking on your front door and asking for "anyone" rather than a specific person (fully-qualified domain name).

What is the output of:

sudo apachectl -S

jori · July 14, 2021, 6:51pm

@griffin
VirtualHost configuration:
*:443 servmin.duckdns.org (/etc/apache2/sites-enabled/000-default-le-ssl.conf:2)
*:80 nuc.medianet (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

this whole thing is a test! The problem is, it seems that the call of the web-page via the public address (presently http://85.16.203.19) doesn't reach the server. I think momentary there is some problem with the port-forwarding on the router not with the apache configuration on the server, because locally any calls work.

regards
jori

griffin · July 14, 2021, 7:10pm

We should still get things straightened out though.

What are the outputs of:

sudo ls -lRa /etc/apache2/sites-available
sudo ls -lRa /etc/apache2/sites-enabled
sudo cat /etc/apache2/sites-enabled/000-default.conf
sudo cat /etc/apache2/sites-enabled/000-default-le-ssl.conf

Please put 3 backticks above and below each output, like this:

```
output
```

jori · July 14, 2021, 7:31pm

voila:

ls -lRa /etc/apache2/sites-available
/etc/apache2/sites-available:
insgesamt 24
drwxr-xr-x 2 root root 4096 Jul 14 12:04 .
drwxr-xr-x 8 root root 4096 Jul 14 12:04 ..
-rw-r--r-- 1 root root 1332 Apr  2  2019 000-default.conf
-rw-r--r-- 1 root root 1553 Aug 23  2020 000-default-le-ssl.conf
-rw-r--r-- 1 root root 6338 Apr  2  2019 default-ssl.conf

ls -lRa /etc/apache2/sites-enabled
/etc/apache2/sites-enabled:
insgesamt 8
drwxr-xr-x 2 root root 4096 Okt 14  2020 .
drwxr-xr-x 8 root root 4096 Jul 14 12:04 ..
lrwxrwxrwx 1 root root   35 Sep 27  2019 000-default.conf -> ../sites-available/000-default.conf
lrwxrwxrwx 1 root root   52 Aug 23  2020 000-default-le-ssl.conf -> /etc/apache2/sites-available/000-default-le-ssl.conf

cat /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

cat /etc/apache2/sites-enabled/000-default-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf


ServerName servmin.duckdns.org
SSLCertificateFile /etc/letsencrypt/live/servmin.duckdns.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/servmin.duckdns.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

regards
jori

griffin · July 14, 2021, 8:41pm

Disable your old configuration files.

sudo a2dissite 000-default.conf
sudo a2dissite 000-default-le-ssl.conf

Install your clean configuration file.

Download this:

servmin.duckdns.org.conf.txt (231 Bytes)

Put it here:

/etc/apache2/sites-available

Run these:

sudo mv /etc/apache2/sites-available/servmin.duckdns.org.conf.txt /etc/apache2/sites-available/servmin.duckdns.org.conf
sudo a2ensite servmin.duckdns.org.conf

Reload Apache.

sudo apachectl -k graceful

Acquire and install your certificate.

sudo certbot --apache -d "servmin.duckdns.org"

jori · July 15, 2021, 3:37pm

certbot --apache -d "servmin.duckdns.org"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate for servmin.duckdns.org

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: servmin.duckdns.org
  Type:   connection
  Detail: Fetching http://servmin.duckdns.org/.well-known/acme-challenge/ZmVJg8URldp0wJYPHobaw_ozr8AQ9V7lXrZdq-Ums0A: Timeout during connect (likely firewall problem)

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

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Thanks for now, everything worked out fine but renewing the certificate.
jori

jori · July 19, 2021, 1:52pm

Unfortunately the error persists as to be seen by the upper reply of the program.

Anybody an idea what to do about it to make it work?
Jori

griffin · July 19, 2021, 5:43pm

Which specific error are you seeing currently?

jori · July 22, 2021, 12:29pm

Hi,
the error on screen is shown in my last post. The last two errors in the log are here:

2021-07-22 10:46:07,658:DEBUG:certbot.display.util:Notifying user: 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2021-07-22 10:46:07,658:ERROR:certbot._internal.renewal:All renewals failed. The following certificates could not be renewed:
2021-07-22 10:46:07,658:ERROR:certbot._internal.renewal:  /etc/letsencrypt/live/servmin.duckdns.org/fullchain.pem (failure)
2021-07-22 10:46:07,658:DEBUG:certbot.display.util:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2021-07-22 10:46:07,659:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/snap/certbot/1280/bin/certbot", line 8, in <module>
    sys.exit(main())
  File "/snap/certbot/1280/lib/python3.8/site-packages/certbot/main.py", line 15, in main
    return internal_main.main(cli_args)
  File "/snap/certbot/1280/lib/python3.8/site-packages/certbot/_internal/main.py", line 1574, in main
    return config.func(config, plugins)
  File "/snap/certbot/1280/lib/python3.8/site-packages/certbot/_internal/main.py", line 1461, in renew
    renewal.handle_renewal_request(config)
  File "/snap/certbot/1280/lib/python3.8/site-packages/certbot/_internal/renewal.py", line 499, in handle_renewal_request
    raise errors.Error("{0} renew failure(s), {1} parse failure(s)".format(
certbot.errors.Error: 1 renew failure(s), 0 parse failure(s)
2021-07-22 10:46:07,659:ERROR:certbot._internal.log:1 renew failure(s), 0 parse failure(s)

griffin · July 22, 2021, 1:07pm

The DNS AAAA record (IPv6 address) for servmin.duckdns.org is 2002:5b61:711f:8000:3631:c4ff:fe65:b8e3, which is a private IP address and thus unreachable from the internet. You will need to remove that record if you want to use http-01 authentication.

Additionally, I suspect that the DNS A record (IPv4 address) for servmin.duckdns.org is changing due to your ISP. You might want to look into either using some form of dynamic DNS (DDNS) (e.g. https://www.noip.com/) or using dns-01 authentication via the certbot duckdns plugin. Using the latter solution will make authentication easy by avoiding the IP address issues, but your website will still be difficult/impossible to reach from the internet regardless if you don't resolve the IP address issues.

jori · July 22, 2021, 1:58pm

Hi griffin,
sorry, for a questions like this, but I don't understand what made this thing so complicated all over sudden. In fact, I don't understand a word of what You are trying to tell me. What I was doing a couple of Years and what I'm trying to "repair" is having an apache webpage running on my server via dyndns servmin.duckdns.org pointing to my momentary ipv4 address and it should be reachable this way from the internet.

This has been rather simple and straight in the past and I don't see the reason, why this suddenly doesn't work anymore. Has anything changed basically meanwhile that I missed, so that this isn't possible anymore?

Thank You for Your patience
jori

griffin · July 22, 2021, 2:39pm

The AAAA record in your DNS being a private IPv6 address will make --apache fail every time. You need to remove it.

If the A record in your DNS doesn't point to the correct IPv4 address for your webserver, your webserver won't even be reachable, so it would be impossible for Let's Encrypt to reach it for authentication.

See for yourself by putting servmin.duckdns.org in the box for ports 80 (http) and 443 (https):

https://www.yougetsignal.com/tools/open-ports/

An http-01 challenge starts from a domain name on port 80 (http) then follows up to 10 redirects to domain names on either port 80 (http) or port 443 (https). IPv6 addresses (DNS AAAA records) are given priority over IPv4 addresses (DNS A records) for challenge requests.

jori · July 22, 2021, 4:02pm

Hi,
well, does that mean that duckdns.org changed their handling lately now including the AAAA record using the ipv6 address in there preferring it over the ipv4 address?

The update of the ipv4 seems to be correct, because a ping on the ipv4 as well as the servmin address is successful.

But after I now don't update the ipv6 address anymore (its empty on the duckdns page for my subdomain) hoping that "deletes the AAAA record"? Why is it still not working? Your link tells me port 80 still closed.

thanks
jori

griffin · July 22, 2021, 4:49pm

IPv6 address is gone now, but IPv4 is still not responding.

What's the output of:

sudo apachectl -S

jori · July 22, 2021, 5:05pm

apachectl -S
VirtualHost configuration:
*:80                   servmin.duckdns.org (/etc/apache2/sites-enabled/servmin.duckdns.org.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex mpm-accept: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

griffin · July 22, 2021, 5:12pm

Are your able to browse your own website? Ping responds for me, but http over port 80 does not.

Topic		Replies	Views
Certbot will not renew Help	26	1632	November 9, 2022
Cannot Renew Cert Help	15	1292	June 5, 2022
Renewal problem Help	4	1030	September 16, 2020
Cert renew issue Help	20	3738	November 13, 2018
Certificate renewal issues Help	4	1043	December 15, 2022

Problem in renewing certificate

Related topics