I took a look at CLI, and tried to run caddy -ca https://acme-staging-v02.api.letsencrypt.org/directory. Is that how I should switch?
Right now it activates privacy features and then just waits after “http://:2015”.
Hi @Howdy,
That is indeed the right way to swap to the staging endpoint.
Doing that tells Caddy to use the different endpoint for Automatic HTTPS, but you’ll still need to have a site configured that is eligible for Caddy to manage the TLS. A site served on port 2015 with no hostname isn’t eligible.
1 Like
Hi,
I have a working Caddyfile, but like I said, nothing happens after it says http://:2015. I guess I should run the command while Caddy isn’t running, but I’ve tried it while running too.
What’s in your Caddyfile?
Is the Caddyfile in the same directory you’re running Caddy from? If not, have you indicated its location with the -conf flag?
My Caddyfile looks like this, and it’s located in /etc/caddy. Forwards me to to the correct sites, so things should be right in that sense.
Where you’re seeing http://:2015, Caddy should instead be printing a list of all the hostnames in your Caddyfile, if it was launched correctly.
Could you elaborate on that? I typically run/restart Caddy with “systemctl start caddy”, and besides the cert problems it redirects pages fine.
Should I be starting it by just “caddy”?
As all that happens when I run “caddy” is “Activating privacy features… done. http://:2015” I assume something is wrong, but “caddy -validate” says that the “Caddyfile is valid”.
It’s been a while and that paste is no longer valid. But, if you are pointing Caddy at the right Caddyfile, it should print the hostname it’s been configured to serve.
For example, a Caddyfile:
www.example.com
root /var/www/html
Should output the following when you launch Caddy and correctly point it at the Caddyfile:
Activating privacy features… done.
http://www.example.com
https://www.example.com
Contrast with what happens when you run caddy with no Caddyfile, which is that it serves files out of the present working directory, over HTTP, on port 2015 (hence the http://:2015 output).
Does it matter that none of my servers run on the same machine as Caddy? I’m only using it to redirect to web UI:s on other machines.
Therefore my Caddyfile currently looks like this.
Based on that, Caddy should output something similar to:
http://domain.com
https://domain.com
http://www.domain.com
https://www.domain.com
http://site2.domain.com
https://site2.domain.com
because you have configured it with Automatic HTTPS and DNS validation, these are the schemes and hostnames you have told Caddy to serve.
So it took me a while, but from this I gather that the Caddyfile itself looks ok? It hadn’t occured to me that I had to specify the DNS challenge for each sub domain, otherwise it defaults back to regular HTTP?
So if the Caddyfile is correct, there seems to be some kind of disconnect between Caddy and the service.
- I assume that Caddy should only display just “http://:2015” if the Caddyfile is empty/wrong?
- I can only find one Caddyfile on the server, and running “caddy -validate” says it’s valid, yet I only see “http://:2015”.
- I’ve seen error messages when running “caddy” based on the changes I’ve made in the Caddyfile.
- systemctl seems to access environmental variables, while “caddy” doesn’t.
I’m considering a full reinstall. Should it be enough to reinstall, add the above Caddyfile, and set Cloudflare environmental variables like this?
Ok, think I actually figured out the original question, how to change to the staging server.
I used this guide to install Caddy, and you should put:
-ca "staging URL"
on the ExecStart line.
Now on to the next problem, changing Caddy’s timeouts so Cloudflare has time to complete, but I’ll make a separate post for that.
I find myself wondering if the service is configured with a -conf flag and you don’t supply the same flag when you run it from the command line?
If you don’t configure it with a Caddyfile, yes, it will output this - Caddy is programmed to serve this interface by default, for convenience of local development (just cd to the web root, run caddy, browse to localhost:2015)
The only reason I can think that this would happen is that you’re not running Caddy in the same PWD as a file named Caddyfile or you haven’t supplied the correct -conf flag.
How are those variables set, exactly?
Ok, not sure why it didn’t work before, but now when I run “caddy -conf=/etc/caddy/Caddyfile” I see:
Activating privacy features... done.
Main domain and all sub domains.
Why would you want to run it like that instead of having it run in the background? Will that show everything it does in real time?
The environment variables are set under the [Service] tag in /etc/systemd/system/caddy.service, but it doesn’t complain now when I run “caddy -conf=/etc/caddy/Caddyfile”. If it does I suspect I have to add the -env flag? Does the file it points to need to only contain environmental variables, or can I point it to /etc/systemd/system/caddy.service?
Maybe the fact that I’ve run Caddy with systemctl is why I have problems with Cloudflare timing out too?
Running it as “caddy -conf=/etc/caddy/Caddyfile” and will see if Cloudflare + Let’s Encrypt can communicate.
(I guess it keeps running anyway if I close my ssh connection? EDIT: tested that a few times, and it seems to keep running, but do I then have to manually kill the process if I want to restart it?)
Thanks for the help!
You probably don’t, but you were wondering why when you ran it manually, it didn’t show your subdomains - this was why.
The file needs to be a newline-delimited list of VARIABLE=value assignments, if I’m not mistaken. Pointing at the systemd unit file will probably not work as expected.
I’m guessing you’ve got Cloudflare API keys in your systemd environment. Caddy won’t complain about missing those until it actually goes to use them to renew your certificates. It only needs to renew them once every 90 days at the outside, although Caddy does it sooner than that so it’s got time to spare in case of network outages.
I don’t believe that this would have any impact on a Cloudflare timeout.
Anything you run in your secure shell will exit when you logout and close the connection.
If your SSH session is configured to remain open for a period of time after you disconnect from it, the program you ran may continue to run for that duration.
If you run the program in screen or mosh or some other session manager, the program will continue to run for the duration of the session, which usually persists through disconnect indefinitely. With a session manager, you can reattach to the session to manipulate the program if needed.
Alright, I think I got a hang of things now. Just need to figure out those Cloudflare timeouts.
Do you know if it’s possible to change how long Caddy waits for a LE challenge to complete?
I don’t think you can change how long it waits for the Cloudflare DNS propagation.
The closest function would be the -catimeout flag, which configures how long Caddy waits for a HTTP request to LetsEncrypt, but that won’t help you with Cloudflare.
I understand that Caddy should keep waiting and rechecking until it confirms the DNS record is present on Cloudflare before proceeding to indicate to LetsEncrypt that the challenge is complete. Is that not happening? Or is Caddy giving up while waiting to confirm DNS propagation?
This is what happens:
Activating privacy features… [INFO][sub.domain.com] acme: Obtaining bundled SAN certificate
[INFO][sub.domain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/…
[INFO][sub.domain.com] acme: Could not find solver for: tls-alpn-01
[INFO][sub.domain.com] acme: Could not find solver for: http-01
[INFO][sub.domain.com] acme: Trying to solve DNS-01
[INFO][sub.domain.com] Checking DNS record propagation using [DNS]
Then it stays like this for two minutes trying to check the DNS record. After two minutes the Caddy process restarts and begins checking again. Again restarting after another two minutes.
It succeeds in writing the ACME TXT challenge to Cloudflare, but Cloudflare requires five minutes to complete the process. Since the process fails, the TXT record stays at Cloudflare until I remove it.
Is Caddy just rechecking the same record every two minutes, or is it exiting every two minutes and you’re restarting the process?
If I run Caddy with old sub domains, that I’ve used the HTTP solver to get valid certificates for, everything runs normally. Doesn’t matter if the Caddyfile has Cloudflare or not in it.
If I add a new sub domain with Cloudflare, I see the above log events.
So Caddy tries to get a certificate for something new, and what seems to happen is that Caddy gives up after two minutes, before Cloudflare has had time to finish the request. Caddy restarts and does the same thing again.
Caddy restarts automatically.