[Julia]

This is an ongoing problem we are having in the SlickStack ss-install on brand new servers where Certbot fails to install the Let’s Encrypt cert on the first attempt and then a 2nd attempt is required, which then always works fine.

When did this start happening? It was around 1.5 years ago I think when SlickStack started using HSTS by default along with a few other “optimized” config settings.

https://community.letsencrypt.org/t/must-run-slickstack-install-twice-to-generate-lets-encrypt-certs/183023

[Ruth]

According to the very smart devs at Let’s Encrypt, HSTS is no problem. Also, there is a lot of outdated documentation and StackOverflow threads etc about how Certbot prefers port 80 and how port 443 can’t be used to generate certs, but apparently this is now incorrect.

At least for a while now, Certbot follows “up to 10 redirects” to the ultimate URL where your server is responding.

In that case SlickStack has a catch-all Nginx block that redirects all random requests on port 80 and port 443 and non-matching domains to canonical:

https://github.com/littlebizzy/slickstack/blob/master/modules/nginx/sites/production.txt

[Donald]

However for the matching domain, it only responds on port 443:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name @SITE_DOMAIN;

In the linked forum thread from letsencrypt.org you will see the discussion and confusion surrounding why Certbot errors are using http instead of https

Could this be related? And if so, why does it work on subsequent attempts? We haven’t been able to find answers to these questions yet….

[Natalie]

We aren’t the only ones confused, there are several recent threats on Server Fault with similar issues which makes me think we aren’t alone.

https://serverfault.com/questions/1061262/nginx-lets-encrypt-https-redirect

https://serverfault.com/questions/1017545/unable-to-use-letsencrypt-certbot-when-http-to-https-redirect-is-setup

https://serverfault.com/questions/1015642/let-s-encrypt-certbot-how-to-use-https-for-the-server-validation

[Laura]

And here is the related GitHub issue on our SlickStack repo

https://github.com/littlebizzy/slickstack/issues/173

[Stephen]

At least for a while now, Certbot follows “up to 10 redirects” to the ultimate URL where your server is responding.

Maybe Certbot follows redirects, but if SlickStack is not redirecting http://example.com to https://example.com via port 80, then maybe it’s causing it to hang. But why it works fine on subsequent attempts is rather perplexing.

One feature that many users have asked for is to force Certbot to prioritize port 443 and HTTPS in the verification request, but seems like they have refused to offer it so far.

[Helen]

yah hopefully SlickStack doesn’t need to add a whole new port 80 server block in Nginx config just for redirecting to HTTPS… seems really silly.

[Alan]

Certbot prefers port 80 and how port 443 can’t be used to generate certs, but apparently this is now incorrect.

The confusion is maybe that Certbot is different from Let’s Encrypt. And Certbot still doesn’t support non-80 ports…

Can I issue a certificate if my webserver doesn’t listen on port 80?
Yes, using the DNS-01 or TLS-ALPN-01 challenge. However, Certbot does not include support for TLS-ALPN-01 yet. If you’re using any Certbot with any method other than DNS authentication, your web server must listen on port 80, or at least be capable of doing so temporarily during certificate validation.

source: https://certbot.eff.org/faq

[Ann]

It sounds like TLS-ALPN-01 support is still a long way off, esp. because Nginx and Apache don’t support the protocol natively.

https://github.com/certbot/certbot/issues/6724

Also:

https://letsencrypt.org/docs/allow-port-80/

“We occasionally get reports from people who have trouble using the HTTP-01 challenge type because they’ve firewalled off port 80 to their web server. Our recommendation is that all servers meant for general web use should offer both HTTP on port 80 and HTTPS on port 443. They should also send redirects for all port 80 requests, and possibly an HSTS header (on port 443 requests).

Allowing port 80 doesn’t introduce a larger attack surface on your server, because requests on port 80 are generally served by the same software that runs on port 443.”

[Diana]

Well, Caddy and Lighttpd both support TLS-ALPN-01 for few years already. But right now for Nginx you probably gotta use a different ACME client like Dehydrated:

https://samdecrock.medium.com/deploying-lets-encrypt-certificates-using-tls-alpn-01-https-18b9b1e05edf

https://github.com/dehydrated-io/dehydrated

[Brittany]

yah hopefully SlickStack doesn’t need to add a whole new port 80 server block in Nginx config just for redirecting to HTTPS… seems really silly.

This is now patched:

https://github.com/littlebizzy/slickstack/blob/master/modules/nginx/sites/production.txt

No practical alternative currently. Anyway it’s not a big deal.

[Willie]

is this problem still happening?

[Barbara]

Yes still happens:

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: example.com
  Type:   unauthorized
  Detail: 2606:4700:3037::6815:4c68: Invalid response from http://example.com/.well-known/acme-challenge/kakVwkKuIPH9H8uhSWBYCJCPF_4UohSL4AUgc86gUgA: 522

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

[Juan]

From all this it seems like Certbot doesn’t follow it’s own guidelines. Why is it not recognizing the redirect until next attempt?

[Christopher]

any update on this

[Author]

Posts