Upgrade: ACMEz v2, CertMagic, and ZeroSSL issuer #6229
Conversation
|
I tried running this and I'm seeing this error for IP subjects: does this check need to be bypassed for the zerossl issuer? |
|
I might need to update the logic regarding IP certs. I think it's still true for ACME but I need to double check on CA policies these days. I'm headed to bed right now but will check on this in the morning. Ps. Thanks for trying it! |
|
@devsnek Ok, so that error only happens if:
Are you getting that while using the ZeroSSL API? ZeroSSL's ACME endpoint, AFAIK, does not support IP certs still. (I don't have ZeroSSL API implemented into Caddy yet) |
|
ah my bad I should have read the diff more carefully, I was using |
|
Ah no worries, I am still working on that part. Soon!! I will update this issue when that's ready. |
|
@devsnek Ok it should be ready to test now. To use ZeroSSL's ACME endpoint as an implicit default, you have to provide an email address in your config. To use ZeroSSL's API, you need to provide an API key and use the |
mholt
requested review from
mohammed90 and
francislavoie
and removed request for
mohammed90
francislavoie
added
feature ⚙️
|
it does try to issue now, but it hits an issue during validation |
|
@devsnek Thanks -- are you sure that URL is publicly reachable? I get a redirect to HTTPS which is probably not going to work 🤔 Hmm, I got it working for me in testing with CertMagic, I wonder why Caddy is redirecting. It doesn't redirect ACME challenges (but this is not an ACME challenge). Maybe that has something to do with it. But then again, I tested the ZeroSSL API on my computer and worked... hmm. |
|
@mholt the only thing running on the server at that ip is caddy, and during that test it had a config like this: its not currently running with that config though, as i normally use the |
|
I think I know the problem... the HTTP server has to be made aware of ACME challenges, it likely also has to be aware of ZeroSSL API's HTTP validation requests... which are slightly different. |
|
@devsnek Ok, I was able to verify that the HTTP validation from the ZeroSSL API works for me now. Can you give it a shot again? Thank you!! 😊 |
|
@mholt its working! |
|
seems ipv6 does not currently work though i played around on the zerossl site for a bit and it seems like it only accepts the address in the expanded form: |
|
Thanks for trying it out! That's good to know about the IPv6 addresses. That's probably intentional, to avoid ambiguity or mishaps when validating the certificates (just a single form for the IP). I will probably merge this shortly then. |
would it be possible for caddy to support the expanded form? currently no matter how you write the ip in the config, it uses the "canonical" (most compact) form rather than the fully expanded form. could it always pass the expanded form to zerossl? |
|
Hm, actually, I don't know. The Related, sort of: golang/go#30264 |
|
Yeah tbc I think the correct thing would be for zerossl to accept the canonical format, but idk how realistic that is... might just be too much effort to support ipv6 here for the moment :( |
|
@francislavoie @mohammed90 I know this is a huge change, I don't expect a thorough review, but if you want to skim it and look for anything you care about, feel free to approve/request changes and we can get this merged :) |
Certificate automation has permission modules that are designed to
prevent inappropriate issuance of unbounded or wildcard certificates.
When an explicit cert manager is used, no additional permission should
be necessary. For example, this should be a valid caddyfile:
https:// {
tls {
get_certificate tailscale
}
respond OK
}
This is accomplished when provisioning an AutomationPolicy by tracking
whether there were explicit managers configured directly on the policy
(in the ManagersRaw field). Only when a number of potentially unsafe
conditions are present AND no explicit cert managers are configured is
an error returned.
The problem arises from the fact that ctx.LoadModule deletes the raw
bytes after loading in order to save memory. The first time an
AutomationPolicy is provisioned, the ManagersRaw field is populated, and
everything is fine.
An AutomationPolicy with no subjects is treated as a special "catch-all"
policy. App.createAutomationPolicies ensures that this catch-all policy
has an ACME issuer, and then calls its Provision method again because it
may have changed. This second time Provision is called, ManagesRaw is no
longer populated, and the permission check fails because it appears as
though the policy has no explicit managers.
Address this by storing a new boolean on AutomationPolicy recording
whether it had explicit cert managers configured on it.
Also fix an inverted boolean check on this value when setting
failClosed.
Updates caddyserver#6060
Updates caddyserver#6229
Updates caddyserver#6327
Signed-off-by: Will Norris <[email protected]>
Certificate automation has permission modules that are designed to
prevent inappropriate issuance of unbounded or wildcard certificates.
When an explicit cert manager is used, no additional permission should
be necessary. For example, this should be a valid caddyfile:
https:// {
tls {
get_certificate tailscale
}
respond OK
}
This is accomplished when provisioning an AutomationPolicy by tracking
whether there were explicit managers configured directly on the policy
(in the ManagersRaw field). Only when a number of potentially unsafe
conditions are present AND no explicit cert managers are configured is
an error returned.
The problem arises from the fact that ctx.LoadModule deletes the raw
bytes after loading in order to save memory. The first time an
AutomationPolicy is provisioned, the ManagersRaw field is populated, and
everything is fine.
An AutomationPolicy with no subjects is treated as a special "catch-all"
policy. App.createAutomationPolicies ensures that this catch-all policy
has an ACME issuer, and then calls its Provision method again because it
may have changed. This second time Provision is called, ManagesRaw is no
longer populated, and the permission check fails because it appears as
though the policy has no explicit managers.
Address this by storing a new boolean on AutomationPolicy recording
whether it had explicit cert managers configured on it.
Also fix an inverted boolean check on this value when setting
failClosed.
Updates #6060
Updates #6229
Updates #6327
Signed-off-by: Will Norris <[email protected]>
|
in the release notes you say: If you use JSON to configure certificate automation policies, you will need to ensure you use the acme issuer with your email filled out, and the ca field set to ZeroSSL's ACME server URL. Thus, I've updated my JSON config to include: Now, all my certs get generated from Zerossl and that was not the intended behaviour. Am I missing something? Thanks |
|
@andreground Caddy does what you configure it to do, so if you tell it to use ZeroSSL as the issuer it will use ZeroSSL. If you want to use multiple issuers then be sure to add them to your configuration. 👍 |
|
@mholt thanks, I think I was updating the config according to the release notes and this ticket comments. In the first post of this ticket, you wrote:
Probably I've misunderstood something or probably the behaviour using Caddyfile is way different from that of the JSON config 👍 This is how I've updated the config to make Caddy behave like you stated, so using Let's Encrypt as first and Zerossl as fallback. Am I doing right? Thanks! |
Yes, so in the release notes we boil it down:
Hopefully that's clear. EDIT: I see why maybe it's not clear when talking about redundancy (multiple ACME CAs). I've edited the wording of the release notes. So yeah, your updated config looks like what you want. Try ACME with Let's Encrypt first, then ACME with ZeroSSL after. And the ZeroSSL one has an email address. 💯 |
|
This is very confusing to me and I've not quite understood yet how this works. So we were using ZeroSSL before with our free account and our use case is following:
Our configuration has this: Do I understand correctly that I need to provide the email like this: to make sure that the ACME is used instead of the API? We are getting errors like such: Maybe it would be a good idea to add some code to check for "certificate_limit_reached" and use the ACME endpoint in that case? |
|
@simaotwx Specifying the |
Thank you! Your reply couldn't have been more clear. |
|
For anyone interested, this is how it looks like now: The Both variables are passed from outside (Terraform -> Packer -> .env -> docker compose -> docker -> Caddy) If anyone needs a way to generate the EAB credentials in Terraform to then pass it all the way through to Caddy, you can use our provider for this: https://registry.terraform.io/providers/toowoxx/zerossl/latest/docs/resources/eab_credentials I made this provider two years ago and realized I didn't actually need it but now it proved to be useful. The alternative to this is to upgrade the subscription and use the API through Caddy for which EAB credentials are not needed (just the API token). |
|
We were previously using this configuration on |
|
@jorgegonzalez see the release notes for details https://github.com/caddyserver/caddy/releases/tag/v2.8.0 |
This (currently-WIP) branch is the final phase in upgrading the certificate automation stack:
ACMEz v2, which introduces a slightly simpler and improved high-level API, while also exposing the ability to customize ACME orders more from those higher-level APIs. For example, users can now set NotBefore and NotAfter to customize cert lifetime (if CA-supported), and also to use draft-03 ARI by setting the previous cert the new order is replacing.
CertMagic, wherein we use the new v2 of ACMEz, but also have introduced a new
ZeroSSLIssuertype which is capable of obtaining certs using ZeroSSL's proprietary API. This has some advantages over its ACME endpoint if you need even stronger SLAs / higher availability or are a paying customer. I think it also allows you to get IP certificates.Caddy's implementation of
ZeroSSLIssueris changing. Moving the ZeroSSL issuer into CertMagic has some implications, because before this, the ZeroSSLIssuer is only a thin wrapper over the ACMEIssuer that can generate free EAB automatically and then the underlying ACMEIssuer is used after that.Now, ZeroSSL is doing away with the default email address that Caddy was using to generate EAB when users didn't provide their own email address. In other words, now in order to use ZeroSSL you will need to do it one of these ways:
emailCaddyfile option for this and we've always recommended using it. That will do.)This transition might be a little tricky because we already allow you to use your ZeroSSL API key, but it's only for generating the EAB (in lieu of an email address), and nothing else. After this change is done, providing your ZeroSSL API key will actually use the ZeroSSL API to obtain certificates, which is paywalled (for good reason).
After this change is done, here's what I suppose Caddy's behavior will be:
zerosslissuer module is now a thin wrapper over CertMagic'sZeroSSLIssuertype (kind of like how theacmeissuer module is a thin wrapper over CertMagic'sACMEIssuertype). It uses the ZeroSSL API exclusively and thus requires an API key.Breaking changes (out of our control) that will be needed for, I suppose, a very small subset of users:
zerosslissuer module).In summary:
zerosslissuer is now API-only:or, for a particular site using the
tlsdirective:Again, I think breaking changes should only affect a certain subset of users. But I'm told the reliability of ZeroSSL's services will improve with these changes.