Caddy: Option to save self_signed certs

[OmgImAlexis]

Currently when you run caddy using the tls self_signed directive caddy regens the certs on restart meaning I then have to open each domain one by one in my browser and accept the warning. It'd be nice if Caddy had an option to just dump the certs into the path provided.

Maybe something like so? This way it can just reuse the certs the next time it starts.

tls self_signed /Users/xo/certs

[mholt]

Is this for a localhost domain? In Chrome, you can set this flag: #allow_insecure_localhost

[OmgImAlexis]

I'm using example.com as well as a load of subdomains of it as localhost isn't an actual domain so it doesn't allow subdomains.

[mholt]

(Disregard any comment notifications you may have gotten from a user account that _looked like mine_ earlier today.)

[aaronellington]

Would generating your own certs (and then point to those with the tls directive) work for you as a short term solution?

[OmgImAlexis]

For the short term sure, that's what I ended up doing for now. In the long run this would fix the issue of needing to generate new certs myself every time I need to do testing across multiple sub/domains.

[princemaple]

Could this be implemented, please? This will save a lot of hassle for Firefox users.

(Even better if we can specify how long it's valid for)

[tobya]

We are happy to accept a PR implementing this if someone wants to give it a try. It should be quite straightforward.

Is it possible to explain why LetEncrypt certs are not a possibility here? If you have a simple public domain you can create any number of subdomains on it internally. Is there a specific reason why self_signed certs are required?

[princemaple]

It's for dev only. Firefox only allows you to add exception for certs, no way like in chrome to allow insecure certs on all local connections. And the exception becomes stale as soon as you generate a different cert, which happens every time you restart caddy.

[OmgImAlexis]

@tobya at the time I had hit the rate limit for let's encrypt on all my domains so I had to use self signed ones while testing.

[tobya]

@princemaple you can still use letsencrypt for dev sites. I still don't understand the issue that requires you to use self_signed certs. I'm just trying to understand the real issue here. Perhaps it is ratelimits, firewalls, company policy, but I would like to get to the real issue to see if this is the only way of solving it.

@OmgImAlexis if you use the staging environment for lets encrypt by starting caddy like this

caddy -ca https://acme-staging.api.letsencrypt.org/directory

you essentially end up with the same as self_signed certs (untrusted certs) but they will be stored and reused by caddy. The rate limits for lets encrypt when using their staging environment is much much higher, so I think this is a solution to your problem. Self_signed certs are really for installations that do not allow access in on :443

[princemaple]

Letsencrypt works for local dev? I did not know that. How? The domain practically does not exist.
(I guess you misunderstood when I said for dev. I didn't mean public on premise / on cloud dev server. I meant app server running locally on my own machine, without any public access.)
And, my real issue is already in this comment, that you cannot flip a flag on Firefox to allow all insecure localhost connections. Every time caddy generates a new self signed cert, you have to add that to Firefox cert exception list to allow it. So every time I restart caddy, I have to do that, which is mildly annoying.

[mholt]

"Dev sites" _is_ a bit ambiguous, yes; I do use LE's staging endpoint for "local" development sometimes; it works if the domain's records point to your home machine and you configure your home network to forward ports. But for _purely local_ development, no, it will not work, unless you set up your own Boulder instance internally.

But that's a hassle. What if Caddy persists self-signed certs for 30 days in $CADDYPATH/self_signed?

[twdkeule]

It does fit nicely with the "easy to use" objective of Caddy.
No need to create a self signed certificate yourself. If this feature existed a few months ago I would have used it :smile:

[mholt]

@twdkeule To be clear, it does already exist (tls self_signed), but it's a different cert each time you run Caddy. (The intent was always to make the developer rely on self-signed certificates as seldom as possible.)

[princemaple]

What if Caddy persists self-signed certs for 30 days in $CADDYPATH/self_signed?

It would make my life much easier :) no longer need to click 3 times to add an exception every time I restart caddy. Doing it once a month is totally acceptable.

[francislavoie]

@mholt I'm sure @twdkeule knows that, just that for persistence currently we have to generate the certificate separately and specify it with the tls <cert> <key> format.

Big 👍 from me to add persistence for self signed certs

[unquietwiki]

I was talking with @mholt about this on the forums recently. We came to an agreement that the point of self-signed certs within Caddy, are by design temporary. However, I was able to modify https://github.com/openwisp/django-x509 to generate browser-friendly internal certs for my needs. We postulated if someone that knows Go could come up with a similar module for this.

[mholt]

By way of update: This may become moot if localhost domains become trusted zones. There's a proposal along those lines. Until that is dismissed, I don't think I am interested in a change to Caddy that gives self-signed certs more weight than they're worth...

[OmgImAlexis]

Another issue I've found is if you're using multiple sites with self_signed and you use SIGUSR1 it will recreate all self_signed certs.

[tobya]

@OmgImAlexis This is the intended behaviour. Self Signed certs are meant as a temporary or interim solution rather than a permenant solution.

[tobya]

I think I will close this issue as it is not currently planned for implementation.

[mholt]

Caddy 2 (starting with beta 17) solves this problem.