We use Caddy on a Windows server for SSL offloading.
We want to move the Caddy installation to a different windows server and I’m wondering if copying the certs folders to the new server won’t cause any issues.
We have ~1200 certificates issued by LetsEncrypt in the current folder.
I’m not sure if the certificates are unique per server or not, and whether copying them to a new server won’t cause any renewal issues or problems with creating other certificates on the new server.
Our current configuration is ‘catch all’.
Is it possible to edit the Caddy file in such way that one additional domain will redirect AS IS to a different IP without any SSL generated for it?
We want to keep it http and not https.
If you copy the entire .caddy folder, that will include the ACME account and all the TLS assets. Caddy on the new server will be functionally identical to the one on the old server in terms of renewals, notification emails, etc.
Yes - Caddy picks which site to use for a given request by selecting the longest matching address.
A catch-all like http:// etc. can be overridden by providing a longer, more specific site address, like http://example.com.
We’ve tried to install caddy as a service instead of the executable file.
It resulted many locks in a totally different folder, probably different version of Caddy resulted many new SSL requests instead of using the old SSL files.
There was a delay of a few hours in which new certificates were not created and now it’s working properly.
Is there a step by step guide that can help us accomplish this procedure in a safer way?
There is no step-by-step guide I am aware of. But the crux of it is that the ACME assets folder must be correctly defined.
You can infer the assets folder locations by knowing what $HOME/.caddy will expand to in the environment you run Caddy in.
OR, you can define the location manually by setting the CADDYPATH environmental variable.
You did not specify how you decided to install Caddy as a service, but I assume you went with systemd, which is probably the most common. Caddy’s own examples repo has a systemd unit file that does the latter - it sets CADDYPATH=/etc/ssl/caddy. If you were using $HOME/.caddy previously, and swapped to this unit file, you’d need to copy from $HOME/.caddy over to /etc/ssl/caddy before starting the service, OR you’d need to change the path in the unit file.
We are using windows not unix.
We used the plugin hook.service and installed it as described here: caddy -service install [caddyOptions]
While the problem occurred we tried to create a new server (new IP + new Caddy installation + new domain pointing to it) but no SSL certificate was created on that server too. I’m wondering if there’s any connection between the incidents.
After a few hours we’ve succeeded to create an SSL certificate on the new server by writing an explicit website URL, but when we’ve changed the Caddyfile back to the ‘catch all’ configuration, it didn’t create new SSLs and the proxy traffic was blocked.
After a few hours the new server started to generate SSLs and the original production server started to generate them too.
I’m trying to figure out how should we deal with Caddy in the production environment. If let’s say we will need to migrate Caddy to a new server. Does the new IP might create all kind of issues?
We have many visits every second so we need to consider how to not get blocked after a migrating to a new server.
Whoops! My bad. So, the -service install uses the same [caddy options] every time, but it doesn’t set environmental variables. That means it’s still in $HOME/.caddy, so… Actually, off the top of my head, I don’t know where it is. C:\ProgramData, possibly.
We’d need to see the output from that server’s logs to make a determination as to this issue. I’d be inclined to assume it was separate.
You’re going to need to elaborate further on the “proxy traffic was blocked” statement.
Specifically - exactly what your Caddyfile was at this point, and the details of the exact requests you made and the response received from Caddy. The output of curl -IL https://example.com would be great, the equivalent on Windows being Invoke-WebRequest -Method HEAD -Uri https://example.com.
With no changes to the Caddy server or the network configuration?
This kind of thing I might expect from slow DNS propagation, for example.
The new IP won’t create any issues as long as you handle it correctly. One way of handling it would be properly migrating the TLS assets folder. Another way of handling it would be setting the new server up with tls ask, like your Caddyfile in the original post. Either way, with any software in a production environment, you need to have someone with confidence in their ability to come up with solutions for these kinds of questions.
If you need, Light Code Labs is there to help. They offer professional support for Caddy in production environments - talk to them a bit about your requirements and they will be able to advise you and assist specifically to achieve your desired outcome.