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.
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)
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)
Success
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?
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.
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.)
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?
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.
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.
