Unable to auto renew certificates


#1

After ~12 months of renewing certificates, all of my systems are failing to renew with the following error:

auto-renewing…

Plugins selected: Authenticator apache, Installer apache Renewing an existing certificate Performing the following challenges:

http-01 challenge for X.X.X.X Cleaning up challenges Attempting to renew cert (X.X.X.X) from /etc/letsencrypt/renewal/X.X.X.X.conf produced an unexpected error: Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80… Skipping.

All renewal attempts failed. The following certs could not be renewed:

/etc/letsencrypt/live/X.X.X.X/fullchain.pem (failure)

There has been no infrastructure change - no firewall, system change - this all used to work flawlessly.

It appears that certbot-auto was auto updated on the 6th of December:

-rwxr-xr-x 1 root root 63562 Dec 6 16:37 /usr/bin/certbot-auto

Port 80 is explicitly disabled on the system by network policies and this used to work flawlessly over the last 12 months not needing port 80 to perform the renewal process.

I have ~10 systems now that are within 15 days of certificate expiry.

Please can someone advise on how to resolve.


#2

Hi @abraunegg

then you have used tls-sni-01 - validation. But this is deprecated, support ends 2019-02-13:

So you have to use another validation method: http-01 or dns-01.

http-01 requires an open port 80. If you can’t open port 80, you have to use dns-01 - validation.

There is another - rare supported and used - TLS-ALPN-01.


#3

Thanks for the response, however dns-01 method means updating the DNS TXT record every renew which is not possible as there is not API for this. Moving to open port 80 also presents a challenge.

What is the correct mechanism to test TLS-ALPN-01 ?

sudo /usr/bin/certbot-auto renew --preferred-challenges tls-alpn-01

generates this error:

produced an unexpected error: None of the preferred challenges are supported by the selected plugin. Skipping.

#4

Certbot doesn’t support TLS-ALPN-01.


#5

There’s a discussion about clients that do support TLS-ALPN-01 here.

If you can alias _acme-challenge to another DNS service that does have an API using a CNAME record, you can use this to complete the DNS-01 challenge. acme.sh has a DNS alias mode specifically for this use case. So that might be another possible alternative.


#6

Whilst I understand the importance of fixing security exposure’s - it has to be highlighted that in general principal you should not remove functionality without having something which can be reliably used in it’s place. Having an alternative like http / dns may work for some use cases - but totally removing https renewal without a replacement is not good. It cant be expected for everyone to work around compliance policies to change to use http / dns just because the https renewal functionality has been deprecated.

When will certbot support certificate renewal via HTTPS?

Is there anyway to continue to provide support for tls-sni-01 (beyond Feb 2019 for renewals) until certbot can support renewal via HTTPS using an updated mechanism?


#7

You should probably better understand the reason https was deprecated to get why things are as they are: February 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support

We would all like that answer. I can only guess that NOT until it can be done 100% securely.

I believe TLS-ALPN will continue to be supported thereafter; But the requirements for TLS-ALPN are near to “impossible” to implement easily for the average user.

If you have security concerns about allowing http traffic to your “sensitive” systems, then don’t use those systems to handle the http connections.
I would use two separate systems:
One for HTTP and one for HTTPS.
You could proxy (only challenges) to the HTTPS system.
Or handle them entirely on the HTTP system; then share the certs to the other internal systems that actual use them.


#8

No one’s happy about the situation. No one wanted there to be a security issue with the TLS-SNI challenge type that necessitated phasing it out and causing compatibility issues for people.

The 13 month renewal phase out period Let’s Encrypt is providing is, if anything, a very long time from many perspectives (while, from some, five years wouldn’t be long enough).

If I remember correctly, the Certbot team found TLS-ALPN validation difficult or impossible to implement safely with current software, and they don’t plan to add support for it soon.

You have two months and one day to revise your security policies, make DNS or HTTP validation feasible, switch to an ACME client that implements TLS-ALPN-01 validation, develop a TLS-ALPN-01 implementation for Certbot, or switch to a CA that still supports some sort of port 443 validation.

(For what it’s worth, TLS-SNI and TLS-ALPN don’t use HTTPS. They only use TLS on port 443. They don’t make an HTTP request. Your server doesn’t need an HTTP implementation, just barebones TLS handshake support.)


#9

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