same problem via via command line or systemd unit file
#!/bin/bash
(r53) {
tls {
dns lego_deprecated route53
}
}
# Main http/https redirect for anything arriving on port 80/http
*.kebler.net:80 {
redir https://{label1}.xxx.net{uri}
}
# Dev Lights Frontend Server
https://dev2.lights.xxx.net, https://dev.lights.xxx.net {
import r53
reverse_proxy http://lights.net:8080
}
3. The problem I’m having:
caddy (via dns challenge) issued a cert for dev.lights.xxx.net but using the url gave Secure Connection Failed error. So I added dev2.lights.xxx.net and it issued a cert for that and that url loads fine. Apparently the original cert is corrupt but I don’t know how to force acme/caddy to invalidate that one so another will be issued/pulled via dns challenge.
Pretty sure you can just go to the data directory and delete the cert for that domain, then reload Caddy. Caddy will notice it doesn’t have a cert for that domain and it’ll fetch a new one.
By the way, there’s now a route53 plugin so you don’t need to use lego-deprecated anymore
log looked ok, cert was issued. Then tried the url in browser and got that error. Added that other url. It generated a cert for it. I tried that url all was fine. Not amount of stopping and starting illicit a new cert for that bad url and yet it doesn’t work even though the other in the same stanza is fine. Thus my conclusion cert is corrupted although I have no idea what that error may imply
Ah, well, unfortunately these browser error pages aren’t very useful – in fact, your server logs probably have more/better details than this browser page.
You could also try with curl -v or openssl s_client to get details. I want to make sure it’s not a bug in Caddy or something. (It’s probably not, but still, it’d be good to check.)
@francislavoie, where would that “data” directory be? When I run from cli no directories are generated when I run from service file directories .config/.step/.local are created in my working directory. Do you mean those? cause I deleted them thinking the certs are in there and restarted and two new ones were issued.
The error persisted. But…nevermind. That url was resolving to my old caddy1 instance instead of this new caddy2 one. The dev2 was pointing correctly thus explains the difference. Rats still looking for my first caddy2 bug.
Note to self. Problems? first check that DNS resolution is pointing to the correct caddy instance!
If you installed Caddy using the apt repo, then it’ll be in /var/lib/caddy/.local/share/caddy, because that’s the $HOME set for the caddy user. If you just downloaded from github or compiled yourself and aren’t running it via a service and are running it as your own user, then it’ll be in your $HOME/.local/share/caddy
