Domain control and serving a certificate are separate checks
A certificate request needs a supported method to validate domain control. A public endpoint also needs the issued certificate associated with the intended serving configuration. A certificate appearing in an administration list does not prove that the hostname's clients receive it.
Certificate Manager supports different authorization designs with different diagnostic evidence. Google documents CNAME mismatch for DNS authorization and serving-address problems for load balancer authorization. Identify the chosen method before changing A, AAAA or CNAME records; a fix for one method is not automatically correct for another.
Prepare a renewal-friendly certificate design
- Inventory every hostname, certificate resource, authorization method and serving association. Assign DNS ownership separately from load balancer ownership where different teams operate them.
- Record the expected authorization record or serving-address requirements from the actual resource. Avoid manually reconstructing a validation value from another certificate request.
- Keep expiry monitoring and a rehearsal plan. Preserve a still-valid serving certificate while a replacement is being validated, following the supported association design.
For beginners, issuance is not the only event worth monitoring. DNS changes made long after initial deployment can affect a later renewal even while the current certificate still appears valid.
Illustrative incident: the validation CNAME points to an old target
A DNS migration copies an earlier authorization record instead of the value required by the current certificate resource. Provisioning remains unsuccessful. This is an illustrative scenario. Repeatedly recreating the application backend cannot correct an authoritative DNS record with the wrong validation target.
Read resource-specific failure evidence
Inspect the certificate's authorization state and reported reason, then compare the actual required record with authoritative DNS answers. For load balancer authorization, inspect both IPv4 and IPv6 serving assumptions where applicable. A correct A record does not excuse an inconsistent AAAA record in a design that requires both to point to the serving endpoint.
| Observation | Evidence | Responsible boundary |
|---|---|---|
| DNS authorization reports CNAME mismatch | Expected value versus resolved value | DNS configuration |
| Load balancer authorization finds an unserved address | Relevant A and AAAA answers | DNS and serving design |
| Certificate is issued but clients receive another | Hostname and certificate association | Endpoint configuration |
| Renewal becomes unhealthy after a DNS change | Authorization history and DNS timeline | Lifecycle ownership |
Use external observations appropriate to public validation without publishing private account data. Account for normal DNS caching while comparing answers, and retain the original record values for a reviewed reversal.
Correct the demonstrated mismatch
For the illustrative CNAME fault, have the DNS owner publish the exact required authorization record. Preserve unrelated records and confirm the authoritative answer before rechecking provisioning. Do not remove a functioning certificate first merely to simplify the resource list.
Verify the replacement reaches the expected issued state, then connect through the real hostname and inspect the certificate served to the client. Check all required names and representative IPv4 or IPv6 paths as applicable. An active resource state is useful evidence but does not replace a hostname-level TLS acceptance test.
Reliability and certificate SOP
Track expiry, renewal health and correct certificate presentation separately. An illustrative internal objective could require investigation of a renewal failure while the existing certificate still has the organization's agreed safety margin. This is an operating target, not a certificate-issuance SLA or fixed provisioning-time promise.
The SOP should retain domain, authorization method, DNS owner, certificate resource, serving association and test result. Escalate ambiguous delegation or third-party proxy behavior before changing a shared domain. Review this inventory after migrations so a future renewal does not depend on a forgotten record managed by a previous team.
Clouvenix can scope related engineering support around a documented environment and agreed acceptance criteria.
Technical reference
Google Cloud: troubleshoot Certificate Manager. Reviewed 19 October 2026; confirm resource-specific prerequisites and behavior for the deployed configuration.