Is there a way to set the response/redirect for on-demand secured domains, while waiting for the SSL cert to be issued?

I apologize for removing the template, this is just a general question about a feature.

If I have a reverse proxy route configured for a domain, and TLS on demand turned on, is there any way to configure some kind of default response for when the CA hasn’t issued the SSL cert yet?

The reasoning is that sometimes the CAs are slow or time out, or may need to be retried. We’re in a state where Caddy is configured, the DNS is pointed, but we don’t have a cert yet. I’m not sure if it’s possible, but if we could configure a temporary redirect or something here to let a waiting user know, that would be very helpful.

I can configure things to have default responses for a Caddy config that hasn’t been updated with the route yet, like a wildcard for subdomains, but so far haven’t been able to come up with anything for that in-between time waiting for the cert.

There would need to be a way to establish a connection in the first place so that a response could be sent. Without a certificate I am not sure how to do that.

Ah right, of course. Okay so one last longshot question, is there any way to temporarily allow http connections and return a default response until the cert comes in without just watching and updating the config?

I don’t think so, because the client is expecting a TLS connection, not a plaintext HTTP connection.

What kind of slowness are you seeing? That was something I was worried about early on (like 5+ years ago) but Let’s Encrypt has always been fast, in the sub-5s category.

I’m seeing a lot of context deadline exceeded errors for both lets encrypt and zeroSSL, particularly when clustered (using the redis plugin) in different global regions using an anycast IP address on Fly.io. I’m not sure why, eventually the cert is issued but it does seem to need to retry or take a while fairly often.

Interesting. On demand TLS has a tighter timeout, but extending it would only make the handshake that much slower. If I give you a branch with a lot more debug logs would you be able to deploy it and we can hopefully see what is taking so long, if it’s on our end?

There was a similar ask here where Caddy could serve an untrusted TLS cert (signed by Caddy’s root CA) until a real one is ready:

But this would still not have great UX because the user will see a “this site isn’t trusted” error instead of “failed to connect” which is arguably worse.

1 Like

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