Is there a simple solution as to why my server can get a letsencrypt cert for a domain but then I cannot connect to it over https from another server?
I had thought about the obvious such as a fire wall blocking https but I would assume that if the cert can be issued then the firewall is open?
I can connect over http
Any ideas.
It’s only from one particular (client) machine that you can’t connect? What errors do you get? And do you get any errors on the server when a connection is attempted?
tests.bcs.cookingisfun.ie took too long to respond.
Try:
ERR_CONNECTION_TIMED_OUT
It looks to me like a firewall issue, but I cant understand how the letsencrypt cert was issued in the first place ( I dont use the DNS challenge).
Nothing in System log
This is what I get:
Yes, should have thought of that–I’m getting a timeout on HTTPS too. But it doesn’t look like your Caddyfile’s set up properly for this FQDN in any event–wouldn’t it ordinarily try to redirect HTTP → HTTPS, rather than just give 404?
Edit: if you’re doing HTTP validation, port 443 inbound doesn’t necessarily need to be open. I’m not sure how Caddy’s implementation works, but Let’s Encrypt tries to connect on port 80, and if it gets the expected answer there, you’re good. Port 443 outbound definitely needs to be open, but not inbound.
Are there any files in your $CADDYPATH/locks folder?
It turns out I suppose unsurprisingly that inbound 443 is blocked. However that confuses me as a cert was issued.
The dns it resolves to is a wildcard
*.bcs.cookingisfun.ie -> myip
Is it possible LetsEncrypt has a cache from a previous issue to the same dns entry?
It doesnt really matter, but it is interesting.
As I said above, at least as far as Let’s Encrypt is concerned, port 443 doesn’t need to be open in order for a cert to be issued–just port 80.
They store authorizations for, IIRC, 7 days for a given ACME account and domain. Thus, if you’ve successfully validated the same domain using the same ACME account within the past week, you won’t need to validate again.
Just a slight clarification on this one. Somewhat to most of our surprise, we learned not too long ago that our ACME provider (acme-go/lego) was changed to prioritize TLS-ALPN to the exclusion of other challenge methods unless overridden. Without additional configuration, it will always try 443. It doesn’t fall back to other methods and it doesn’t randomize methods, so I’d have expected this to fail with that port blocked unless they use -disable-tls-alpn-challenge.
Ah, I hadn’t considered that, as TLS-ALPN isn’t used very much in other clients. In that case, @tobya’s results really are unexpected.