Error renewing certificate


#1

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: dlmw.dedyn.io

I ran this command: sudo certbot renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/dlmw.dedyn.io.conf

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for dlmw.dedyn.io
Cleaning up challenges
Attempting to renew cert (dlmw.dedyn.io) from /etc/letsencrypt/renewal/dlmw.dedy n.io.conf produced an unexpected error: Problem binding to port 443: Could not b ind to IPv4 or IPv6… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dlmw.dedyn.io/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dlmw.dedyn.io/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

My web server is (include version): I don’t know how to check this. I am running nextcloud appliance (from tech and me) and am novice at linux

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

My hosting provider, if applicable, is: NA

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

My issue is lack of knowledge. Couple of months back I ran the sudo bash /var/scripts/activate-ssl.sh command and followed the instructions to create a letsencrypt domain and certificate. Now I get a reminder it will expire and needs to be renewed, but the renew command fails.
I tried reading some of the other similar questions and gather that the tls-sni-01 might be obsolete. But I have not idea where to begin to fix it. (if it was windows I could look in services at least and try stop the web service)


#2

ah ha…
I found out nextcloud is apache

So I followed these instructions to stop it. https://www.cyberciti.biz/faq/star-stop-restart-apache2-webserver/

I did:
sudo /etc/init.d/apache2 stop
[ ok ] Stopping apache2 (via systemctl): apache2.service.

sudo certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/dlmw.dedyn.io.conf

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for dlmw.dedyn.io
Waiting for verification…
Cleaning up challenges


new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/dlmw.dedyn.io/fullchain.pem


Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/dlmw.dedyn.io/fullchain.pem (success)

sudo /etc/init.d/apache2 start
[ ok ] Starting apache2 (via systemctl): apache2.service.

Success :smiley:
So it looks like it was because 443 is in use the renew fails - one of the other threads has mentioned something about the ‘standalone’ thing creating a temp web server.

So, do I need to worry about the tls-sni-01 thing, and if so, what do I do?


#3

Hi @Disorganise

you can use tls-sni-01. But you see the problem:

The tls-sni-01 - challenge needs the 443-port, so an existing webserver has to stop and start again. So your website is down. And tls-sni-01 is deprecated.

Perhaps you may use the http-01 - challenge instead. There you can use an existing webserver without interrupt, certbot creates a special file under /.well-known/acme-challenge/file-with-a-long-token.

Check

the webroot-plugin, there you can set the path of your webroot. And you may first use the test-system or the dry-run - option.


#4

TLS-SNI can work well without stopping the web server, you just need a minor adjustment to your renewal:

certbot renew --cert-name dlmw.dedyn.io -a apache --dry-run

(and don’t stop your webserver).


#5

I tried this. Obviously since the cert was already renewed it would be expected to abandon, but it did give an error actually:

sudo certbot renew --cert-name dlmw.dedyn.io -a apache --dry-run
[sudo] password for ncadmin:
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/dlmw.dedyn.io.conf

Cert not due for renewal, but simulating renewal for dry run
Could not choose appropriate plugin: The requested apache plugin does not appear to be installed
Attempting to renew cert (dlmw.dedyn.io) from /etc/letsencrypt/renewal/dlmw.dedyn.io.conf produced an unexpected error: The requested apache plugin does not appear to be installed. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dlmw.dedyn.io/fullchain.pem (failure)


** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dlmw.dedyn.io/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)

1 renew failure(s), 0 parse failure(s)


#6

For my situation, the nextcloud is solely for me to upload photo’s etc from my phone, so not having the server available for short-time is no bother.

This worries me a bit, depending on why it is deprecated. If there’s some vulnerability then I shouldn’t use it. But I’m a bit confused by the option to go with unencrypted http - isn’t that a bigger risk? Or is it still creating a temp webserver for the few seconds it takes to renew the cert and then shuts it down?


#7

Look there:

Port 80 is a standard-port. If someone controls port 80, he controls the domain. An exotic port wouldn’t do the same.

If you use your webserver alone, the downtime isn’t relevant. But if the webserver is public, such a solution isn’t good. The http-01-challenge works without restarting the webserver (and without a dns-api), so it’s wonderful.


#8

It doesn’t make your resulting certificate worse or anything.

The problem with TLS-SNI-01 is that there are some unusual circumstances in which a shared hosting provider might accidentally allow one customer to (intentionally) complete it on behalf of another customer, which would then allow the first customer to inappropriately obtain a certificate for the second customer’s domain. This problem doesn’t exist in other circumstances. So if the CA offers you TLS-SNI-01 validation, there’s nothing bad about your using it (the CA has determined that the risk is acceptable under Let’s Encrypt policies, and in any case the risk is that the user to whom the TLS-SNI-01 validation was offered could obtain a fraudulent certificate, so if it’s offered to you and you don’t have any fraudulent intentions, you’re not creating any new risk by taking advantage of it).

Since TLS-SNI-01 doesn’t ever validate or otherwise rely on any preexisting certificates, there’s no reason that doing validation on port 80 will be less secure than port 443.

More broadly, the threat to you in the certificate ecosystem is normally about what other people do in their interactions with CAs (trying to impersonate you), not what you do. If you initiated a particular certificate request, the “worst case” from a security perspective is that you successfully obtain the certificate that you asked for (but if your request isn’t fraudulent, that’s totally fine!); the “best case” is that you fail to obtain a certificate at all. Scenarios in which your certificate request ultimately leads to someone else’s getting the certificate instead (with a different encryption key mentioned in it!) would rely on very exotic attacks that we currently have no reason to think are possible.


#9

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