About Domain Control Validation (DCV) Monitoring
Before a public CA will issue a certificate for a domain, it has to confirm that your organization controls that domain. That confirmation is called domain control validation (DCV), and it doesn't last forever: each CA records when a domain was validated and when the validation expires, and CA/Browser Forum rules continue to shorten how long a validation can be reused. When a validation lapses without anyone noticing, the next certificate request for that domain fails, which usually surfaces as an outage rather than as a warning.
DCV monitoring gives you the validation status of every domain in your CA accounts inside Palo Alto Networks Trust Protection Foundation™, so you don't have to log in to each CA console to find it. Trust Protection Foundation asks each CA for the domains registered to the account the CA Template object connects with, normalizes the CA's own wording into one set of statuses, stores the result against the CA Template object, and checks again once a day. Monitoring is CA-focused rather than certificate-focused: you see every domain the CA account knows about, whether or not you currently have a certificate for it.
NOTE DCV monitoring reads validation data. It does not start a validation, complete a challenge, or change anything in your CA account.
CAs that report domain validation data
DCV monitoring is available on the CA Template objects for these CAs:
-
DigiCert CertCentral
-
Sectigo Certificate Manager
-
GlobalSign MSSL
-
HID PKIaaS
A CA Template object for any other CA has no Domain Control Validation tab, and certificates issued by it show no validation data.
Validation statuses
Each CA describes validation in its own words. Trust Protection Foundation maps what the CA reports onto one of the following statuses, so that domains from different CAs can be read and filtered the same way.
|
Status |
What it means |
|---|---|
| VALIDATED | The domain has passed validation and the CA will issue certificates for it. |
| PENDING | Validation has started, and the CA is waiting for the DNS or HTTP challenge to be completed or detected. |
| EXPIRED | The domain was validated, but the reuse period has closed. It must be validated again before the CA will issue for it. |
| FAILED | The CA tried to validate the domain and could not, for example because a DNS record was wrong or an HTTP path was unreachable. |
| NOT VALIDATED | The CA has no validation for this domain, either because it was never validated or because the CA account doesn't hold a record of it. |
| UNKNOWN | The CA returned a status that Trust Protection Foundation doesn't recognize. This is different from NOT VALIDATED, which means no validation was found at all. |
What the daily checks do
Two scheduled checks run once a day against each CA Template object that supports DCV.
-
The Domain Control Validation Status Daily Check asks the CA for current validation data and updates the stored records. Domains the CA no longer reports are removed. If a check is still running when the next one is due, the new one is skipped rather than run twice.
-
The Domain Control Validation Expiry Notices Daily Check reads the stored records and logs an event for each domain whose validation is close to expiring or has recently expired. Nothing is fetched from the CA during this check.
Expiry notices escalate as the date approaches, so that a notification rule can act on the severity rather than parse the message:
|
Event |
When it's logged |
|---|---|
| Domain Control Validation - Expiration Notice | The validation expires in 6 to 10 days. Logged as Info. |
| Domain Control Validation - Expiration Escalation | The validation expires within 5 days, including today. Logged as a Warning. |
| Domain Control Validation - Expired | The validation expired within the last 7 days. Logged as an Error. After 7 days, the domain stops being reported. |
NOTE A notice is logged on the day the domain falls into one of these windows, and a missed day is not made up. If the engine is down on the day a domain enters a window, that day's notice is not logged later.
When the same domain has been validated more than once, the notices use the latest expiration date among those validations. example.com and *.example.com are tracked separately, because neither one's validation covers the other's name.
Viewing domain validation data
There are two places to look, both in Policy Tree:
-
The Domain Control Validation tab on the CA Template object lists every domain the CA reports for that account. Each row shows the Domain, the Validation Method (DNS, HTTP, or Email), the Status, the Expiration Date, the CA's own identifier for the validation in Certificate Authority ID, the Last Validated Date, when Trust Protection Foundation last refreshed the record in Last Checked, and any Error the CA returned. You can filter on any column, which is the quickest way to find everything that is EXPIRED or FAILED.
-
The Summary page of a certificate shows the validation records for the names on that certificate, taken from the CA Template object that issued it. This section appears only when the certificate's CA supports DCV.
Both views are driven by permissions on the CA Template object, not on the certificate: you need Read permission on the CA Template object to see validation data, and Write permission to retrieve it on demand. A user without Read permission on the CA Template object sees no validation data on a certificate issued by it.
Retrieving validation data on demand
You don't have to wait for the daily check:
-
On the CA Template object's Domain Control Validation tab, click Retrieve Validation Status to refresh every domain in the account.
-
On a certificate's Summary page, click Check DCV Status to refresh the data for that certificate's CA.
Both run in the background. The grid doesn't update while you watch it; refresh the page after the fetch has had time to finish. A refresh calls the CA's API with the same account your certificate requests use, and some CAs apply a rate or volume limit to that account, so prefer the daily check for routine monitoring and use these buttons when you have just corrected a validation and want to confirm it.
Securing the connection to the CA
A DCV check calls the CA's API with the credential stored on the CA Template object, which is the same credential used to request certificates. Whether Trust Protection Foundation verifies the CA's HTTPS certificate on that call is decided by the platform-wide Certificate Verification setting, which applies to all outbound HTTPS connections and is not specific to DCV.
IMPORTANT The default is None, which accepts any certificate the server presents. Under that default, anyone able to intercept the connection or redirect the CA's host name can pose as the CA, collect the credential the request carries, and return false validation data. Set Certificate Verification to Basic or Strict so the CA's certificate is checked before the credential is sent. Public CA APIs present publicly trusted certificates, so turning verification on should need no extra trust configuration on your Trust Protection Foundation servers.
For what each mode checks and where to set it, see Setting up Certificate Verification for securing outbound HTTPS connections.
Reading validation data from the Web SDK
The Web SDK exposes the same data under the domaincontrolvalidation route: fetch/ca queues a refresh for a CA Template object, status/ca returns the stored records for a CA Template object, and status/certificate returns the records for the names on one certificate. The same permissions apply as in the console.