To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
you have an up-to-date TLS configuration that allows the server to
communicate with the Certbot client.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
you have an up-to-date TLS configuration that allows the server to
communicate with the Certbot client.
Are you sure that both of these hosts are running a web server (the same web server that they were running when you first obtained the certificate) that can speak HTTPS on port 443? Or, if you weren’t running a web server when you first obtained the certificate and you used --standalone, are you still not running a web server?
I’m having the same issue. I’m using Cloudflare and I found a temporary fix is to pause the DNS and HTTP Proxy (CDN) (look at screenshot), run the certbot, and then turn it back on. I was hoping I could find a more permanent solution however.
Hi @murfasa, I’m also using cloudflare. I had to disable it during initial cert generation but I think read in another thread at the time that it wasn’t necessary to disable for renewals.
Same problem here. Renewal behind Cloudflare was not working. Both webroot and nginx methods were not working. I disabled CDN and it worked. My domain is 💩.brashear.me (💩.brashear.me).
I was getting a tls handshake error from certbot with CF proxy enabled.
I’m not sure if this information can solve everyone’s problems in this thread, but:
Using the --apache or --nginx methods (which use an authentication method called TLS-SNI-01) is completely incompatible with using Cloudflare or any other CDN or remote reverse proxy. That is true for both initial issuance and renewal. If you use these methods, you will always have to disable the CDN temporarily for renewals.
You can also be using --apache if you just ran certbot without telling it what method to use, because it is the default method if you have an Apache server.
If you used --apache, it will also be used automatically for renewals. Some people have had renewal failures because they weren’t behind a CDN when they first issued the certificate, but subsequently added a CDN after HTTPS was already working.
(If you plan to be behind Cloudflare permanently, you don’t necessarily need a Let’s Encrypt certificate at all; Cloudflare has its own CA partnership and can issue publicly trusted certificates for your site automatically. In this case, you can also use Cloudflare’s own free “origin certificates”, which are only trusted by Cloudflare but don’t require using a Let’s Encrypt client. The origin certificate protects the connection between Cloudflare and your origin server. As far as I know, there is no loss of security by using a Cloudflare origin certificate.)
Using the --webroot method (which uses an authentication method called HTTP-01) is compatible with CDNs, but you must have HTTP enabled on the CDN and it must actually be able to serve content from your origin server. (Redirections from HTTP to HTTPS either on the origin server or on the CDN, or both, are OK as long as a visitor ultimately gets the content when requesting a specific HTTP URI. Blanket redirections from specific HTTP URIs to the top level of the HTTPS site are not OK because the content the visitor gets doesn’t match.)
Finally, if you’re using --standalone, the default behavior is to use TLS-SNI-01. However, --standalone can also use HTTP-01 if you specific --preferred-challenges http-01.
I’m happy to deal with further questions, but I hope this summary is helpful to at least some people in this thread.
Can you elaborate on why is it incompatible? I’ve used LE behind cloudflare for a long time and never had issues until now. Is there something that may have changed?
Regarding not needing LE for Cloudflare, in my org users on our LAN go to the servers directly (no cloudflare), while external nets go through cloudflare. Being able to get a publicly-valid certificate enables this use case.
[quote="KeenRivals, post:10, topic:36738, full:true"]
Can you elaborate on why is it incompatible? I've used LE behind cloudflare for a long time and never had issues until now. Is there something that may have changed?[/quote]
Sure, the TLS-SNI-01 method makes a TLS connection to the host pointed to by the DNS record and sends an SNI extension in its ClientHello requesting to connect to a particular long random string plus .acme.invalid. It expects the TLS server to respond by serving a particular certificate. If the server does not do this, the TLS-SNI-01 challenge fails.
When you're behind Cloudflare, Cloudflare is terminating your TLS sessions for you and hence it doesn't know to respond to the .acme.invalid request with any particular certificate.
This is how TLS-SNI-01 has always worked, since the first day of Let's Encrypt's operation. If you were passing a challenge from behind a CDN, that CDN had special Let's Encrypt support of some kind, or it wasn't terminating TLS, or you were passing some other challenge (HTTP-01 or DNS-01). The HTTP-01 challenge generally works fine behind a CDN because it's about returning particular content at the HTTP level, and the CDN is willing to forward the HTTP request to the origin, which returns the appropriate content in response to a particular URI.
Thank you for the great explanation! I think it my case I was passing the HTTP-01 challenge, but after configuring the server to redirect HTTP to HTTPS, that somehow broke renews since they had to go through Cloudflare.
The authenticator plugin that you selected when you first ran Certbot to obtain the certificate (or ran certonly a subsequent time to renew it) gets saved in the authenticator property in the file in /etc/letsencrypt/renewal corresponding to that particular certificate.
Different authenticator plugins use different challenge types. The apache plugin, which is suggested by default if you are running Apache and didn't specify any plugin, uses the TLS-SNI-01 challenge type, which requires a direct (not proxied or intermediated) TLS connection to your server on port 443, and hence doesn't work behind a CDN or reverse proxy or similar other device.
The webroot plugin, which is used if you specified --webroot or chose it from a menu, uses the HTTP-01 challenge type which involves creating those files in /.well-known/acme-challenge and accessing them with HTTP over port 80. This method does work behind a CDN or reverse proxy.
I was able to renew the cert using the command, the renewal config got updated to authenticator = webroot, and certbot renew --dry-run now succeeds for both certs.