Domain authorization with more than one defaults to HTTP instead of DNS as configured

I am trying to establish a certificate that will house three wild/root domains. I have created a domain authorization for each domain using DNS challenge, and the method being AWS Route53.

The first problem is one domain which I know if in Route53 is not displayed in the DNS Zone id drop down, and I have had to provide the zone id manually. Not sure why this listing is limited, but it does not display all the host zones we have in AWS.

The second problem is when I test the configuration after creating the three-domain authorizations for each domain. The test immediately fails and states that the http-01 authorization cannot be used for wildcard domains and use DNS validation instead. Funny as it is configured for dns-01 validation to begin with. It appears when when I have more than one domain authorization configured, it always fails as the application uses the wrong validation method. When I adjust it for one domain and one authorization only, it does perform the dns-01 validation, and the test is successful.

I have even removed the domain that was not displayed in the DNS Zone id and entered it manually thinking this may have caused the issue, and still the test fails.

Any help as to how I can overcome this setup issue would be greatly appreciated.


How many AWS Route53 zones do you have? I suspect you may have lots (over 100?), and therefore we’re hitting a maxresults limit (first time this has been reported). Manually entering the ZoneID will work around this as you have noted. The alternative reason would be that the API credentials don’t have permissions for that zone.

Assuming all of your domains are different zones you will indeed need different authorization configs for each (per zone), as you already have.

Regarding the fallback to http validation, this occurred with another user yesterday, they had entered their domain match rules as, *.domain (comma delimited) instead of using the expected semicolon (e.g.; *.domain). Release 5.3.1 added support for comma delimiters in domain match rules (yesterday).

You should ensure you are on the latest version and check the Preview tab. All of your domains should be mentioned next to a DNS authorization config, if the domain isn’t mentioned it will fallback to http. In a future update we will be expanding the preview to highlight/warn about unmatched domains which will default to http.

Thank you for the input as the comment about the semi-colon delimited approach did resolve my problem and allowed my test to complete and gen a certificate.

1 Like

Excellent, glad to hear that. Were you using commas or perhaps spaces to delimit the domains? I’m interested in catching these automatically as any potential source of failure is also a potential source of frustration for users.

Hi everyone,

I got the same problem with the test validation (with DNS) when I add multiples domain name into the certificate. I don’t have IIS installed on the server because I generated certificate for a third-party web application.

My DNS provider is Cloudflare.

I set 2 domain into my certificate: and app.
I set the 2 DNS validation with Cloudflare with each right zone ID (selected in the dropdown).
I set the domain match with semicolon :
DNS validation 1 :; *
DNS validation 2 :; *

When I do the Test, I receive the error "The website root path for [certificate name] could not be determined.


What’s can be wrong ?

Like rniedosmialek said in the previous message, when I set only one DNS check, all tests passed.

I found the problem.

For one URL, I set so the validation process doesn’t find any domain matching (saw this in the preview table).
So, I changed the URL to and the validation process passed !

1 Like

Great! Glad you got it working.