Caddy: multi-issuer error?

[SvenDowideit]

So I just built a new version of my infra, using master, and changed my config a small amount:

.... other bits ...

(dns_api_gandi) {
    session_id testing.loc.alho.st
    tls {
        issuer acme
        issuer internal
        dns gandi {env.GANDIV5_API_KEY}
    }
}

*.loc.alho.st loc.alho.st {
        import dns_api_gandi
        @testing_loc_alho_st {
                host testing.loc.alho.st
        }
        route @testing_loc_alho_st {
                respond Testing
        }
}

and I get the following error:

[ERROR]  Removing invalid block: parsing caddyfile tokens for 'tls': Caddyfile:20 - Error during parsing: cannot mix issuer subdirective (explicit issuers) with other issuer-specific subdirectives (implicit issuers)

note, I'm only doing this, because when I last touched this, wildcard certs would only work when the tls section was inside the host specifier - if that's changed let me know :+1:

[SvenDowideit]

I keep seeing info like

2020/11/17 03:06:11.985 INFO    tls.issuance.acme.acme_client   trying to solve challenge       {"identifier": "township-sl.ona.im", "challenge_type": "http-01", "ca": "https://acme-v02.api.letsencrypt.org/directory"}

why is it doing http-01? I _only_ use dns...

[mholt]

Hey Sven!

Ah yeah, so using the dns subdirective cannot be mixed with the issuer subdirective since dns configures an issuer, so the two configs are in conflict. Instead, you can embed the dns config inside the block for issuer acme: https://caddyserver.com/docs/caddyfile/directives/tls#acme

    tls {
        issuer acme {
            dns gandi {env.GANDIV5_API_KEY}
        }
        issuer internal
    }

why is it doing http-01? I only use dns...

I'm not sure... I don't see that hostname (township-sl.ona.im) in your Caddyfile at all.

[SvenDowideit]

I'm weirded out that it "was" working, and then all i changed was caddy version and added issuer, and now its not, but maybe I'm not actually building what I think I'm building :/

I _suspect_ the main thing is that tls.issuers can't be in a domain section, and needs to be in the top level only?

it'd be nice if the dns gandi <secret> could also be in the top bit, even for *.asdf.com asdf.com sections.

still poking - I moved a few things around, and now its doing acme dns only - but of course, I've been rate limited not 0/

[SvenDowideit]

yeah - wrt the township.sl bit - I forgot to edit what i pasted here - too much magic generation stuff happening on my end

[SvenDowideit]

(zerossl only gives non-wildcard, and only 3 free certs? - worth mentioning, as i was disappointing, given the PR suggests its a full drop in replacement (yes, I'm contemplating paying, but its just more stuff to deal with)

[SvenDowideit]

ok, even weirder, I changed from that invalid config, which talked to lets encrypt using dns-01, but failed with rate-limiting error, to the example you have above, and suddenly it, worked.

so I'd say there are likely some really not-great cfg corner cases :/

[mholt]

I'm weirded out that it "was" working, and then all i changed was caddy version and added issuer, and now its not, but maybe I'm not actually building what I think I'm building :/

Running caddy version (or, if using systemd, looking at the logs will tell you, assuming you use the --environ flag which we recommend in our unit files) will give you the version so you can be sure you're running the right binary.

I suspect the main thing is that tls.issuers can't be in a domain section, and needs to be in the top level only?

The snippet I gave you in my last comment should resolve the problem; what happens when you try it?

(dns_api_gandi) {
    session_id testing.loc.alho.st
    tls {
        issuer acme {
            dns gandi {env.GANDIV5_API_KEY}
        }
        issuer internal
    }
}

it'd be nice if the dns gandi could also be in the top bit, even for *.asdf.com asdf.com sections.

You can use the acme_dns global option. It should become the default for all ACME issuers then.

still poking - I moved a few things around, and now its doing acme dns only - but of course, I've been rate limited not 0/

Always always always use the staging endpoint when testing with Let's Encrypt! :man_teacher:

(zerossl only gives non-wildcard, and only 3 free certs? - worth mentioning, as i was disappointing, given the PR suggests its a full drop in replacement (yes, I'm contemplating paying, but its just more stuff to deal with)

No, if you use ACME it's free and unlimited, and you get wildcards.

When you get a chance, please update me on your latest complete config and the full output, I would like to reproduce the errors you've been seeing. Thanks!

[SvenDowideit]

yes, your solution works perfectly - excellent to know about the zerossl - I'm going to try that out too then, as having the dashboard is pretty darned golden - might be worth getting that spelled out in the pricing page (assuming they want to talk that up)

I'll have to go break things again to show you the errors in detail - the trouble is its all based around the caddy-docker-proxy code, and so has too much stuff in it.

[mholt]

excellent to know about the zerossl - I'm going to try that out too then, as having the dashboard is pretty darned golden - might be worth getting that spelled out in the pricing page (assuming they want to talk that up)

My understanding is they're working on it! Before we do the 2.3 release I hope it will be updated by then.

yes, your solution works perfectly

I'll have to go break things again to show you the errors in detail - the trouble is its all based around the caddy-docker-proxy code, and so has too much stuff in it.

I see... so, you say that my solution works perfectly -- are there any remaining issues?

I'll see if we can do anything about the error messages, maybe with more code (some heuristics) we could eliminate those (for example, by making the dns subdirective a local default for acme type issuers that don't have it set, in that same tls block).

Anything else? If not, feel free to close the issue. :)

Thank you for trying it out!! This is great feedback.

[SvenDowideit]

Yeah, I'm guessing the only real thing we can do to improve this is docs, error checking or making the caddyfile syntax more premissive

While the error

Removing invalid block: parsing caddyfile tokens for 'tls': Caddyfile:20 - Error during parsing: cannot mix issuer subdirective (explicit issuers) with other issuer-specific subdirectives (implicit issuers)

_is_ correct, it doesn't mean anything to the reader until after they know the correct solution.

once you show the example - its meaning is clear.

I'm wondering if there's a possibility to have all (yup, i'm stretching) syntax errors (warnings?) to come with either a URL, or a unique number that resolves to a full example showing a fully working example of the right thing - cos pretty much every time I come here, its because I failed to find / think of the right snippet - which is exacerbated by the fact I only _use_ Caddy, and once I have the right syntax, it just works, and i don't look at it for months.

mmm, Yeah, I'm supposed to be working on a flutter app this week - I'll close this, and if I have something concrete to show will open a new one.

great job btw.

[mholt]

I'm wondering if there's a possibility to have all (yup, i'm stretching) syntax errors (warnings?) to come with either a URL, or a unique number that resolves to a full example showing a fully working example of the right thing

That's a good idea. It'd be a lot of work but I will keep it in mind and try to prioritize it, or something like it.

Glad you got it working!