Different challenge types for hostnames in certificate

[JensSpanier]

I would like to issue a certificate with a wildcard (DNS-01 challenge) and a hostname (HTTP-01 challenge). But it's only possible to chose one challenge type for the whole certificate.

Does the acme protocol support mixing challenge types and would it be possible to implement this in win-acme?

[WouterTinus]

The ACME protocol supports it, but there's no way to configure it in the client currently.

A workaround would be to validate one of the domains in a seperate renewal and abuse the fact that validations remain valid for a while.

E.g. you validate only the normal domain with HTTP-01 validation, but throw that certificate to the garbage (no store or installation steps). Next you create a renewal that includes the wildcard and the other domain with DNS-01 validation. The other domain will still be valid because of the previous validation, so it will skip the validation with DNS-01. It's a bit fragile but should work.

Note that it doesn't work the other way around because HTTP-01 plugins will refuse to validate wildcard domains.

[WouterTinus]

One way to solve this, which has been in my mind for a while, is to allow users to configure global validation settings for specific (patterns of) hosts. The primary goal of that would be to make it easier to manage large amounts of renewals on the same domain. You'd only have to configure your DNS provider or file transfer credentials once instead of repeating them over and over.

But also would make these kinds of mix-'n'-match scenarios possible.

[JensSpanier]

I like the idea of having global validation settings. So it would be possible to define a list of hostnames for each validation method?

My idea is to have an option "Choose validation method for each hostname" in the step where the validation method is selected. After creating a validation method for one hostname you can choose if the next hostname should use the same validation method or if you want to create another.

So in the end you have a list of validation methods (maybe multiple DNS-01 etc.) and the list of hostnames contain a reference to one of this validation methods. That would change the current format of how a certificate is saved, but I think it would allow maximum flexibility.

[webprofusion-chrisc]

The way we did this in Certify The Web was to have a domain match rule (wildcard etc or list of domains to match) which determined which validation config to use. Having a global config is a good idea (and is something we will be adding as well) especially if you will have many sites that are a subdomain of a single domain, and you are using DNS validation. Defaulting to http validation is still the most useful option for general use.

It could be useful to be able to select a specific named global rule (e.g. "Cloudflare DNS as Hosting Company", "Route53 as Example Corp", "Route53 as Another LLC") because a global rule could be reused against thousands of domains/zones and you don't necessarily want to define what they are all in the rule.

[WouterTinus]

So in the end you have a list of validation methods (maybe multiple DNS-01 etc.) and the list of hostnames contain a reference to one of this validation methods. That would change the current format of how a certificate is saved, but I think it would allow maximum flexibility.

Yes, that would be most flexible, but also a bit cumbersome to configure and I wouldn't even know how to start making that possible from the command line.

So my initial idea to capture 80% of the power at 20% of the cost was to create an overarching validation configuration object that would automatically apply to a matching (set of) domain(s), regardless of which renewal they happen to find themselves in.

So roughly the logic for each host name validation would be: 1) check if an overarching configuration is defined that matches the host 2) if so, use that 3) if not, use whatever has been specified at the level of the renewal

[WouterTinus]

Some groundwork for this has landed in release 2.1.22, perhaps the next release will see the required UX to start using it.

[WouterTinus]

This is possible in https://github.com/win-acme/win-acme/releases/tag/v2.2.0 (advanced menu, global validation options)