Management Hub 7.2.0: Managed Challenge with Infoblox fails second SAN with NXDOMAIN, direct provider works

Hi,

I think I have found a reproducible issue with Managed Challenges in Management Hub 7.2.0.0 when using the Infoblox DDI DNS API (Posh-ACME) and a certificate containing multiple identifiers.

Environment:

  • Certify Management Hub 7.2.0.0
  • Windows Server 2019
  • Let’s Encrypt production
  • dns-01 validation
  • Infoblox DDI DNS API (using Posh-ACME)
  • Infoblox external DNS view
  • Certificate is managed directly by the Management Hub instance

Problem:

When the certificate uses “(Use Managed Challenge)” and contains two identifiers, for example:

easysecure.ch
www.easysecure.ch

the first identifier validates successfully, but the second identifier consistently fails with NXDOMAIN.

Example:

Preparing automated challenge responses for: easysecure.ch

[after the configured propagation delay]

Validation completed: easysecure.ch

Attempting challenge response validation for: www.easysecure.ch
Submitting challenge for validation: www.easysecure.ch

Validation failed: www.easysecure.ch
Response from Certificate Authority:
DNS problem: NXDOMAIN looking up TXT for _acme-challenge.www.easysecure.ch

I initially suspected DNS propagation and increased the Managed Challenge propagation delay progressively from 90 seconds to 300 seconds and finally 450 seconds.

The problem still occurred with a 450 second delay.

The interesting part is that this seems to affect the second identifier systematically. We observed the same pattern with other multi-SAN certificates, e.g. domain.tld + www.domain.tld. Automatic retries often succeed because the first authorization is then already valid and only the second challenge needs to be prepared.

A/B test:

I then created another certificate with the same structure:

easyshelf.ch
www.easyshelf.ch

but instead of “(Use Managed Challenge)” I configured the Infoblox DDI DNS API provider directly in the certificate authorization settings.

I deliberately reduced the propagation delay to only 90 seconds.

This request succeeded on the first attempt.

Relevant log:

Validation completed: easyshelf.ch
DNS: Deleting TXT Record ‘_acme-challenge.easyshelf.ch’ … using API provider ‘Infoblox DDI DNS API (using Posh-ACME)’

Validation completed: www.easyshelf.ch
DNS: Deleting TXT Record ‘_acme-challenge.www.easyshelf.ch’ … using API provider ‘Infoblox DDI DNS API (using Posh-ACME)’

Completed certificate request.

So the comparison currently looks like this:

Managed Challenge → Infoblox:

  • 2 identifiers
  • 450 sec propagation delay
  • first identifier succeeds
  • second identifier fails with NXDOMAIN

Infoblox provider configured directly:

  • 2 identifiers
  • 90 sec propagation delay
  • both identifiers succeed on the first attempt

This strongly suggests that the DNS propagation time itself is not the problem and that the issue may be in the Management Hub Managed Challenge handling for multiple identifiers.

There is an older related issue:

“Renewal Fails validation when multiple domains specified”

In that case async DNS challenge cleanup was involved and the issue was reported as fixed in 7.x. My case may be different because the two identifiers use different TXT record names:

_acme-challenge.easysecure.ch
_acme-challenge.www.easysecure.ch

and the direct Infoblox provider works correctly with exactly the same setup.

Could you please check whether there is a regression or a separate multi-identifier issue in the Managed Challenge implementation in Management Hub 7.2.0.0?

I can provide complete request logs or additional diagnostics if required.

Thanks.

Thanks for raising this issue. Note that licensed customers can email issues to support@certifytheweb.com - you don’t have to post them here.

The infoblox provider is part of POSH-ACME so it would be interesting to see if you have the same issue with a test subdomain using that. We don’t have an infoblox account to test against ourselves.

When you validate a domain/subdomain with Lets Encrypt it stays validated for some time after, so in the case where there is some sort of DNS cleanup race you will find that if one validates and the other fails, repeating the request (which the system will do automatically) will fix the problem.

However this does suggest that the cleanup phase of the DNS challenge is clobbering the still in progress record for the other subdomain, we will investigate either way.