Troubleshooting¶

Feature-specific guidance also appears under certificate workflows, Delegated DNS-01, plugins and Entra ID. This page covers issues that cut across features.

Start at the Overview¶

The dashboard Overview has a Needs attention list, most urgent first: Agents waiting for approval; expired certificates; certificates revoked at their CA but still current (clients that check revocation reject them, and an Agent does not renew a revoked certificate), offline Agents and public endpoint problems; the newest failed renewal of each certificate with the first line of its error, and Delegated DNS-01 records whose CNAME check found the CNAME missing or pointing elsewhere; upcoming expiry; late Agents. Each entry opens the page with the detail and the next step; a revoked certificate's entry reads How to replace and opens the certificate, which gives the command to run on the Agent's host (CertIntel does not replace it). No outstanding issues is shown only when none of these stands.

Signing in¶

"Too many attempts. Wait a minute and try again."¶

The sign-in page allows 10 attempts per minute for one email address from one network address and 30 attempts per minute from one network address across all email addresses. Eight consecutive wrong passwords also lock the account for 15 minutes. Wait, then try again; while throttled the API's POST /api/v1/auth/login answers 429 with a Retry-After header and Too many sign-in attempts. Wait and try again., also for the right password. The limit counts attempts per network address, never per account, so the answer says nothing about whether an account exists.

The two-factor code is rejected¶

Check that the phone's clock is set automatically: a code is accepted only for about 30 seconds either side of its time step, and each code works once, so wait for the next code rather than entering the same one again. After five failed attempts within five minutes, further codes are refused until the window passes (a correct code does not count); ten failures in a row lock sign-in for 15 minutes. Use Use a recovery code instead if the app is not available. See Two-factor sign-in.

I lost my authenticator and my recovery codes¶

Ask an administrator of your workspace to Reset two-factor for your account on Users → Manage. You are signed out everywhere and can sign in with your password and set it up again. Administrators cannot reset their own; another administrator (or a tenant administrator) has to. See Administrator reset.

Every page sends me to "Account security", or the API answers "mfa-required"¶

Your workspace requires two-factor sign-in and your grace period has ended. Set it up under Account security; until then the dashboard offers nothing else and the API answers 403 mfa-required. Single sign-on users, demo accounts and API keys are not affected. An API session that signed in with a password and has not verified its code yet gets the same answer; call POST /api/v1/auth/mfa/verify first.

Every page sends me back to "Change password"¶

An administrator created or reset your account, so a password change is required before anything else. Until you change it, every other form submission is redirected to the password page. The new password must differ from the current one (The new password must be different from the current one.). Demo accounts cannot change their password at all (This is a demo account, changing password is not supported.).

"Too many wrong current passwords"¶

Changing your password checks the current one with its own limit: eight wrong attempts per account within 15 minutes, after which the form (and the API, with 429 and Retry-After) answers Too many wrong current passwords. Try again in N minutes. without saying whether the password was right. These attempts do not count toward the sign-in lockout, so a mistyped current password never locks you out of signing in.

A federated (SSO) user can sign in but has no access¶

Role mapping is default-deny - see OIDC / SSO overview. Check that the claim value your identity provider actually sends matches a configured mapping (or a CertIntel.* convention value) exactly, byte for byte.

Signing out at the identity provider does not end the CertIntel session¶

Front-channel logout only takes effect when the provider's request carries both sid and iss and iss equals the Issuer configured on the provider exactly. For Entra ID that means the v2.0 issuer; see Entra ID troubleshooting. The session still ends on CertIntel's own Sign out or at expiry.

Agent¶

An Agent shows Late or Offline¶

A running Agent reports to CertIntel at least every hour: its heartbeat, and every report a renewal, scan or check produces. The Agents page shows each Agent as Reporting, Late (two hourly reports are missing: Last report 3 h ago, expected every hour) or Offline (no report for 24 hours: Offline since … (26 h)), and the Reporting filter selects each state. An Agent whose key cannot report is never Late or Offline: it is shown by the reason - Disabled, Unregistered, Expired or Pending approval (for example Its API key is disabled, so it cannot report; it is not counted as late or offline.) - and left out of the filters, the counts and the alert.

While an Agent is offline its certificates are not renewed or reported. A certificate whose renewal it planned shows a renewing agent late or renewing agent offline pill in the certificate list (renewing agent disabled and so on for a key that cannot report), and its page says … is late: Last report 3 h ago, expected every hour. The planned renewal happens only while it reports; inspect the agent. The Agents that stopped reporting alert (agent.silent) is sent once when it has been offline for 24 hours and once more, as critical, at 5 days; in between the daily summary lists it. That alert is selected by default on a new destination. While no destination subscribes to it, the Overview and Alert Settings say that nobody is told when an agent stops reporting, with Add a destination for it (see Events).

On the Overview, an unreachable endpoint whose name a Late or Offline Agent's certificates cover names that Agent in its row - Its server's agent web01 is late too. - and the name links to the Agent's details. Only users who can read Agents see it.

On the device, check that the server is up and that the service runs and can reach CertIntel: systemctl status certintel-agent and sudo certintel status (Linux), or the CertIntel Agent service and the desktop app (Windows). Start the server or the service if it is stopped. Do not delete or disable the Agent in CertIntel: it reports again as soon as it is back. The Agent's details show the same steps under Late: what to do or Offline: what to do.

Without a shell on the device, the Agent's details add Without access to the device: what CertIntel's own public endpoint checks of the names its certificates cover say: an endpoint answered after the Agent's last report (the server is up, so the Agent service or its connection to CertIntel stopped), none has connected since then (the server, its network or its web service may be down too), the last checks are older than that report (open one and check it now), or a private address that CertIntel does not check (check it from your network). Each endpoint links to its result. With no endpoint for those names, the details suggest adding one, with Add an endpoint for a role that may. Only users who can read public endpoints see this.

Last report on the Agent's details is when it last contacted CertIntel. Last renewal run reported is something else: when it last reported the outcome of issuing or renewing a certificate, which happens only then, so it is often days or weeks old and does not show whether the Agent is running.

A renewal keeps failing¶

The Renewals page shows repeated failures of one certificate as one row, the newest, with the first line of its error and +N earlier (which opens every attempt of that renewal); tick Every failed attempt (not grouped) to list each attempt. The Overview's Needs attention lists the same newest failure. Open the failure: its detail leads with the newest error - an older failure opened from an alert or a list says Newest error and offers Open the newest failure - followed by What to do. A DNS-01 challenge CNAME that points to the wrong place names the exact record and target to set; other causes name the next step (the CNAME check, the CA's rate limit, a CAA record, or the Agent's own status). Beside the failure the page says what the Agent does next, as the Agent reported it: the time of its next try and how many attempts in a row have failed, or Stopped retrying (see When the Agent tries again). After fixing the cause, start it on the Agent with the one command the page names: certintel certificates issue ID for a certificate that was never issued, certintel certificates force-renew ID otherwise.

An issued certificate whose installation failed is listed as Installation failed (with the certificate the server still serves, when the Agent's error names it), not as a failed renewal. Its What to do says to fix what stopped the installation and run certintel deployments retry ID, which installs the issued certificate again and orders no new one, and its page offers Install again with that command instead of Renew now.

The Agent retries one renewal under one row, so the row and its detail show the newest attempt and how many attempts failed, whatever their error (the number certintel status shows as attempt N): the list says 8 failed attempts, the last 2 h ago (or Last tried …), the Overview Renewal failed (8 attempts): …, and the detail 8 attempts failed, the last …; first reported …. While another certificate of the same Agent was failing too, a failure that names neither could be either one's: the count is then a lower bound and reads at least 8 (At least 8 failed attempts, …). The count comes from the Agent's own reports, so it is shown only for the CertIntel Agent and not for a failed installation (those are retried without such a report); a failed installation's detail shows when the Agent installs again by itself. The same failure again is not alerted again.

The agent says setup is required or cannot authenticate¶

Open Settings, supply either an install token or an existing agent API key, then select Test connection. A saved local credential is not proof that the platform accepted it:

• Approval required: Approve this agent in the CertIntel dashboard, then test the connection again. (428 Precondition Required) means an administrator must approve the newly enrolled device on the platform's Agents page. The same condition shows up as CertIntel HTTP 428 elsewhere; see below.
• 401 Unauthorized means the key is wrong, expired, revoked or unregistered. An unregistered key (the device ran certintel unregister, disconnected, or was uninstalled with its data) stops working; an administrator can bring it back with Re-register or Rotate on the Agents page.
• this is an integration API key, not an agent key, and the platform refuses it for agent work; … - an API key from the API Keys page was pasted. Create an install token on the Install Tokens page and enroll the computer with it (certintel enroll --api-base …), or paste an agent key. An Agent already connected with such a key keeps cloud work paused and says why once, instead of reconnecting every 15 minutes.
• This host does not serve CertIntel agents. Enroll against … The install token was not used. (404) - the installer or certintel enroll used the platform console's address or another workspace's address. Use the address the message names, which is the one the Install Tokens page puts in its commands.
• An enrollment with … is not finished. or An enrollment on this computer received an agent key from the platform, but … - an earlier enrollment may have created a key on the platform (the request was sent and no definite answer came back), so enrolling again is blocked to avoid a second key. On the Agents page, disable or delete the agent named after this computer, run certintel unregister (or Disconnect), and enroll again, with a new token if it was a one-time token. A failure that created nothing (a wrong or used token, a refused request, a DNS, connection or TLS failure) does not block the next attempt; the Agent names that failure instead.
• The platform accepts this agent's key but refused ROUTE with 403; that refusal is a setting on the platform, not the key, so it no longer pauses cloud work. - the key is valid, but a workspace setting (for example an IP allowlist) or the key's permissions refuse that one request. Check the workspace's Settings → Security and the key; other cloud work continues.
• This one-time install token has already been used. Mint a new one from the Install Tokens page. (401) - a one-time token enrolls exactly one agent, and this one already has; the first install consumed it. If that install was yours and the agent is now waiting for approval, nothing is wrong. Mint a new token for another machine.
• This one-time install token has expired. Mint a new one from the Install Tokens page. (401) - the token's Expires after window (15 minutes to 24 hours) ran out before the install. Mint a new one; the organization token does not expire.
• Invalid install token. (401) - the token is mistyped, revoked, or the organization token has been rotated since the command was copied. The specific one-time messages above appear only when the secret matched.
• A network or TLS error means the configured API/server URL cannot be reached or trusted from the service host.

If you installed with the raw MSI, the agent has no credential at all: the MSI does not accept INSTALLTOKEN or APIKEY. Connect it from Settings or with certintel enroll.

CertIntel refused this agent on the address it is connected to¶

The workspace accepts agents only on its own address (Only accept agent submissions on our workspace address under Settings → Security), and the Agent is connected through another one, such as the shared ingest host https://api.certin.tel. Every agent call there is refused with 404. The Agent says so: CertIntel refused this agent on the address it is connected to: This workspace accepts agents only on its own address, https://…. Enrol the agent again with that address, or turn off "Only accept agent submissions on our workspace address" on the workspace's Security page. Dashboard assignments show it as the last check's failure, and reports wait and are sent again later instead of being dropped.

Either enrol the Agent again with the workspace address the message names (the commands on the Install Tokens page use it), or have a workspace administrator turn the setting off.

CertIntel refused the DNS delegation credential for …¶

The Agent names CertIntel's reason when the delegated DNS-01 API refuses a delegation's credential, when you test or add it and when a renewal publishes or removes its challenge: CertIntel refused the DNS delegation credential for example.com ("Invalid record or secret."). The delegation username or secret is wrong, or the record was disabled, deleted or given a new secret in CertIntel. …

In the dashboard, open Delegated DNS-01 and find the record for that domain: Reactivate it if it was revoked, or Rotate secret if you no longer have the current secret (a deleted record has to be created again). Then enter the record's current username and secret on the device with Add / replace delegation (see Test or replace a credential). CertIntel does not know the DNS delegation for … means the platform has no such record: check the delegation username and the API address, or create the record again.

certintel says the agent service is not running¶

A certintel command that could not reach the service says why. The command was not sent, and it exits with status 3:

• The CertIntel agent service is not running: nothing is listening at …. Check it with: systemctl status certintel-agent. Start it with: sudo systemctl start certintel-agent. If it stopped with an error, the reason is in: journalctl -u certintel-agent -n 50 (Linux). On Windows the message names the service CertIntelAgent: check it with Get-Service CertIntelAgent and start it from an elevated PowerShell with Start-Service CertIntelAgent (or start CertIntel Agent in Services).
• This account may not use the CertIntel agent's control socket …: run the command as root (for example sudo certintel status). On Windows, run it from an elevated prompt (Run as administrator).
• local agent unavailable or identity verification failed (…); the command was not sent. The service may be starting or stopping; … - something answered that could not be verified as the Agent service, or nothing answered. Check the service and try again.

certintel tui prints the same text when it cannot start.

Activity, diagnostics or a job shows "CertIntel HTTP 428"¶

The Agent enrolled successfully but has not been approved yet. Nothing is wrong with the key, the URL or the network: open the dashboard's Agents page, find the device with the pending approval badge and click Approve, then Test connection again. See Install tokens & enrollment.

The Agent says so once: an approval-pending event (Waiting for administrator approval in the CertIntel dashboard (CertIntel HTTP 428 from ROUTE); Private CA, Internal TLS Probe - Cloud, AD CS and CRL cloud checks resume after approval), approval_pending: true in certintel status --json, private_ca.status pending, and a disabled waiting for administrator approval issuer entry in the wizards. When the approval is noticed, an approval-granted event follows (This agent was approved in the CertIntel dashboard; cloud checks resume and the Private CA availability is being checked) and the cloud checks and Private CA probe run at once.

Use Activity for the readable error. Routine activity stays in the agent; only errors are written to the Windows Application event log (source CertIntelAgent), including CertIntelAgent service failed: … when the service cannot start. Debug entries are always recorded; show them with Show debug details on Activity. Retention is under Settings → Log retention.

The desktop app shows "View only" and nothing can be changed¶

The app runs without administrator rights until you approve changes. Click Unlock changes (or simply make a change) and accept the Windows prompt. The approval lasts until you click Lock, close the app, or 15 minutes pass without changes. A standard (non-administrator) Windows account cannot use the app at all; use Restart as administrator with an administrator account. See Administrator approval.

If the second confirmation dialog (CertIntel Agent - administrator approval) lists changes you did not make, choose No. After three refusals the helper closes and the next change asks for Windows approval again.

A workflow cannot change its CA, account or certificate names¶

This is intentional. The domain set, ACME account, directory/profile, key type and renewal identity are part of persisted order and replacement policy. The Agent rejects changes to these fields on an existing workflow.

Create a new workflow for a different issuance identity. Existing workflows can still change their display name, automatic-renewal preference, DNS credential, output password, and storage/installation plans.

Choosing the correct workflow action¶

Manual actions and first issuance run immediately. Weekly renewal windows constrain only unattended renewal and automatic installation retries. The Renewal due column and History… explain why a renewal has not happened yet.

A renewed certificate is issued but not installed ("Waiting for deployment window")¶

The certificate has a deployment window (its workflow's own or the Agent default), so the renewed certificate waits for the next opening while the current one stays installed. The desktop app shows Waiting for deployment window, the terminal interface the time it installs, and CertIntel lists it under Deferred deployments on the Agent's host detail and says when the window opens (The agent installs the renewed certificate when its deployment window opens, in 3 hours, at 22:00 CET.). Install again, or certintel deployments retry ID on the device, installs it at once without waiting for the window. If the installed certificate would expire within the window's margin before the next opening, the Agent installs anyway and CertIntel raises Deployment window overridden.

When installing the certificate failed and is being retried, the Agent says so in certintel status --json: the certificate's deployment (phase, the last error, attempts and next_attempt) and its next_step, Issued but not installed: installing it failed (attempt N); the agent tries again at …, or now with: certintel deployments retry ID. Last error: …. CertIntel shows the same next try beside the failure, and lists the certificate under Certificates as Issued, installation failed.

The renewal date moved, or a certificate renewed early¶

The Agent follows the CA's renewal window (ARI) when the CA offers one, and picks a random time inside it. When the CA moves the window earlier or reports that it has already ended - for example ahead of a mass revocation - the Agent renews on its next pass, outside renewal windows too. The Agent checks the window again when the CA's Retry-After asks (kept between a minute and a day, and 6 hours when the CA gives none or a check fails). Check renewal window in the desktop app, C in the terminal interface or certintel certificates check-ari ID asks the CA at once. The Renewal due tooltip, the terminal interface's certificate detail and the certificate's Renewal schedule in CertIntel show the basis and the window. See when a certificate renews.

A certificate request is refused by the CA, or the certificate is held for review¶

The Agent shows the CA's own reason for a refusal - its problem type and explanation, including up to three subproblems - in certintel status, the job result, the activity log and the failure report in CertIntel, for example invalidContact: contact email has invalid domain …. A failed account registration and a refused finalization are named as such. The explanation of a failed validation is kept with the values it quotes hidden (…), as they could be other tenants' TXT values; see "ACME validating failed".

For a refusal the Agent holds (below), the renewal's page in CertIntel says under What to do what to change, then use Renew now (for a certificate that was never issued: run certintel certificates issue ID on the agent), and Waiting does not help: the CA refuses it the same way until this is changed. Beside it the page shows Stopped retrying: the Agent does not try such a certificate again by itself. For a CAA refusal it names the domain and the record to add to its CAA records (or to the parent domain that holds them): 0 issue "letsencrypt.org" for Let's Encrypt, "sectigo.com" for ZeroSSL and Sectigo, "pki.goog" for Google, "digicert.com" for DigiCert and "globalsign.com" for GlobalSign (the other names each CA accepts count too). A CAA refusal that comes while the CA validates the challenge is held too.

Failures that are retried back off, up to 12 hours apart, and stop after 12 failed attempts in a row with the automatic retry limit was reached; review the failure, then use Renew now or acme.reset-order; an attempt started by hand is not limited. CertIntel then shows Stopped retrying beside the failure, with the number of failed attempts. The retries after the CA made an order invalid (a refused validation) are counted too, and the Agent orders again instead of resuming the invalid order.

A refusal that cannot succeed without a change is held for an administrator instead of being retried: invalidContact, unsupportedContact, accountDoesNotExist, invalidProfile, rejectedIdentifier, caa, externalAccountRequired, badCSR and similar, and unauthorized or malformed when the CA refuses the request itself (account registration, new order, finalization). A validation that failed because the TXT record was not seen yet is still retried. Fix the cause (the contact email, the CAA record, the EAB credentials) and use Renew now on the device (or certintel certificates force-renew ID); a successful attempt clears the hold. A held certificate that was never issued says so in its renewal history (First issuance of … is paused and is not retried automatically: …); start it again with certintel certificates issue ID. While a certificate is held, the dashboard does not offer Renew now for it (Renew now is not offered here: … stopped retrying … After fixing the cause, start it on the device: …), and a request is refused with needs-review.

The CA refused: CAA prevents issuance¶

The CA refused the order because the domain's CAA records do not name it (the CA's reason starts with caa). The Agent holds such a certificate for an administrator instead of retrying (see the section above). Use Check CAA on the workflow form, the CAA records card of the name's Delegated DNS-01 record, or GET /api/v1/caa-check: each says which records decide and gives the exact record to add, for example example.com. CAA 0 issue "letsencrypt.org". Add it at your DNS provider of the zone named there, wait for the old record's TTL, then use Renew now on the device. For a wildcard name add an issuewild record when the domain has one; a record with validationmethods must include dns-01. See CAA records.

"Renewal refused" after Renew now in the dashboard¶

The Agent decides whether to act on a dashboard renewal request. It refuses it while the configuration lock is on (config-locked), while a failed attempt's own retry is not due yet (retry-not-due), while the certificate is held for review (needs-review, see above), and within an hour of an earlier dashboard renewal, failed or not (rate-limited). The reason is shown on the page; see Renew now. Scheduled renewals are not affected by the lock.

"… retry is not due until …"¶

A job the Agent will not start yet says until when, in UTC: ACME retry is not due until 2026-11-07 09:30:00 UTC (Private CA retry …, deployment retry …) while it waits after a failed attempt before it tries again by itself. A renewal check (certintel certificates renew ID) of a certificate that is not due completes with certificate is not due for renewal until …; use Renew now to renew early; that is not a failure and is not reported as a failed renewal. Wait until then, or start it yourself: certintel certificates force-renew ID (or Renew now on the device) does not wait for that retry, only for a CA rate limit, and certintel deployments retry ID installs again at once. A revocation is not held back by a failed renewal: a revoke right after a failed Renew now goes to the CA at once. Only a failed revocation waits, and a revoke in that time says when the Agent tries again by itself (revocation retry is not due: the previous revocation attempt failed; the agent tries again by itself at …); see Revoking a certificate.

A failing certificate says "was due at …, waiting for the agent's next report"¶

The time the Agent planned for its next try has passed, and the Agent has not reported since. It normally reports the outcome within minutes. If the line stays, the Agent is not running or cannot reach CertIntel: see An Agent shows Late or Offline. See also When the Agent tries again.

"ACME validating failed: the CA could not verify domain ownership"¶

The CA looked up the DNS-01 record for a name and did not find the value it expected. The error ends with what the CA said, naming the record it looked up, with the values it found hidden, and says when the Agent retries by itself: ACME validating failed: the CA could not verify domain ownership; the agent retries by itself at 2026-11-06 17:03:12 UTC. The CA said: Incorrect TXT record "…" found at _acme-challenge.app.example.com (unauthorized). When the CA's text does not name the name, the error does (The CA said about app.example.com: …). For a certificate that is already issued, the current certificate stays in use and the Agent tries again when the renewal is due (… not before …).

Check that the _acme-challenge CNAME of that name points to its target (see DNS-01 challenge never resolves), then let the Agent retry, or use Renew now to try at once.

"HTTP-01 is no longer supported"¶

DNS-01 is the only validation method. A certificate whose configuration still names HTTP-01 keeps its installed certificate but is not renewed, and shows HTTP-01 is no longer supported (removed in Agent 1.5.0); delegate DNS-01 for these names and remove the challenge setting. Create a DNS delegation for its names, then use Switch to DNS-01 (see HTTP-01 was removed). In the dashboard, HTTP-01 is no longer supported; use DNS-01 delegation. means an assignment or API request still names an HTTP-01 challenge; omit challenge.

A dashboard assignment shows "Blocked by configuration lock"¶

A local administrator turned on the Agent's configuration lock, so the Agent applies no dashboard assignment until it is turned off on the device; the assignment stays awaiting approval with Configuration lock is on; platform changes are blocked on this agent. Ask the device's administrator to run certintel unlock (elevated, or with sudo) or turn it off in the desktop app's or terminal interface's settings, then approve the assignment there. Proposals that arrived during the lock are never auto-applied. See configuration lock.

The desktop app's "Lock" button and the configuration lock¶

They are unrelated. Unlock changes and Lock start and end the desktop app's administrator approval session. The Configuration lock under Settings is a file that makes the service refuse dashboard-assigned workflows. See Configuration lock.

An endpoint is "serving an old certificate"¶

The endpoint, public or internal, is linked to a managed certificate that renewed more than the grace period (24 hours by default) ago, and its last probe since the renewal still saw the previous certificate. The renewed certificate was usually installed somewhere else than the server that answers - another node behind a load balancer, a CDN or proxy in front, or a site whose binding was not updated - or the service was not reloaded. Reload or restart the service; if it serves the old certificate again afterwards, check the deployment step of the workflow that renewed it. After the next probe the status and the Public or internal endpoint still serving an old certificate alert clear on their own once the endpoint serves the renewed certificate. An internal endpoint is probed by an Agent, not by CertIntel: select Recheck on it, and the status changes when an Agent has checked it again (it asks for work hourly by default). If the link is wrong, Unlink it on the endpoint. See Served versus issued.

A failed installation alert shows "[redacted]" or no output¶

The Agent replaces every secret it knows of with [redacted] before sending a failed step's output. No output at all means the failure came from another ACME client, a failure before installation, or an Agent or workflow with report_step_output turned off. See Reporting failed step output.

A step that printed nothing, such as a TCP or endpoint check, gives The failed step printed nothing; its error is below., then The step printed nothing (or this agent is set not to report step output). and the step's error, which says what failed. When the Agent's retry later installs the certificate, the destinations that were sent the failure alert also get Installation succeeded after an earlier failure; see Events.

A workflow setting, step output, or secret is missing¶

Open Edit workflow… → Edit workflow settings and steps… → Review. Missing shared settings belong on Setup; secret names belong on Advanced, with their values saved separately through Protected secrets…. Use Insert value… to select references. Moving a producer below its consumer breaks the reference, and a skipped or failed producer cannot supply its normal outputs. See the studio guide.

A message such as input "name" cannot use runtime-derived reference means a ${steps.*}, ${certificate.*}, ${renewal.*} or ${system.*} value was used to build a path, file name, host or other target. Use a literal or a shared setting there; see where runtime values may be used.

Validate with agent checks the definition without running it. A successful validation does not prove a secret is stored, a directory exists, or a service is reachable. Validate / preflight performs the supported non-installing checks on a saved workflow; check actual job results after execution.

A replaced certificate remains in the Windows store¶

By default the Evaluate previous Windows store certificate step verifies the replacement and then retains the predecessor (retained: true, reason: acknowledgement_required), because the Agent cannot prove that every Windows consumer has switched. Removal happens only when both shared settings Remove previous certificate after confirmation and No other application uses the previous certificate are on and no IIS, HTTP.sys or Remote Desktop binding still references the old certificate (reason: in_use otherwise). The scheduled Purge of superseded store certificates under Settings → Schedules is a separate, off-by-default sweep. Otherwise remove the old certificate from certlm.msc yourself once you are sure nothing uses it. See Windows store verification.

JKS issuance or installation fails¶

Confirm that the workflow points to the exact absolute .jks file, the Java runtime's real keytool.exe, the intended alias, and the existing keystore/key password. The containing application directory must already exist. A JKS password must be supplied because Java must be able to open the keystore after the agent writes it.

If keytool reports an invalid CSR, inspect Activity for the command phase and verify that the selected executable is Java keytool, not another file with the same name. If certificate import completed but the selected Tomcat/Windows service did not restart, use Install again. The agent recognizes an already imported reply and continues with the exact configured service restart instead of trying to create another certificate order.

A Windows update is offered but will not install¶

The updater accepts a release only when its two signed metadata sources agree and their authorization has not expired. It also verifies exact size, the MSI SHA-256 digest, Authenticode signer and MSI product identity before starting Windows Installer, and never installs an older version. Check Activity for a source-disagreement, signature, hash or installer error (update-failed). A transient disagreement can mean one release endpoint has not finished publishing; retry after both endpoints contain the same release.

Use the current release URLs; the assets record is downloads/agent/latest/info.json. Records are re-signed on a schedule and expire after 30 days, so check the machine clock if the record appears expired or from the future. An update that starts but rolls back can have failed the installed-version or service-health check; inspect C:\ProgramData\CertIntelAgent\update-install.log and the resulting service status instead of treating launch as a successful upgrade.

On Linux, run certintel update check and sudo certintel update install. The Agent also checks for updates on its own and shows update available. From Agent 1.12.1 it installs the update by itself when automatic installation is turned on for that machine; deb or rpm installations update through apt or dnf. See Linux updates.

"Update now" or "Update all outdated" did not update an Agent¶

The dashboard only requests an update; the Agent picks the request up with its next heartbeat (within about an hour; Agent 1.13.0+: within about a minute) and decides. The Agent's row or host page shows the state and the reason (see Agent updates from the dashboard):

The configuration lock does not block signed updates.

An appliance deployment fails¶

See Appliance deployment. The appliance templates were tested against simulated APIs, not real devices, so also check the details listed for your template there.

• credential not set: certintel secret set remote … - the workflow uses a local credential that was never set. Set it on the Agent machine with certintel secret set remote WORKFLOW-ID:credential (elevated or sudo), or have the assignment name a platform credential.
• the management certificate (SHA-256 …) does not match the pinned fingerprint - the appliance's management certificate changed. Compute the new fingerprint (how) and update the pin. Nothing was sent to the device.
• … already holds a different certificate named … - choose another Certificate name on the device, or remove the old object on the device.
• Configuration lock is on; platform credentials are not fetched. or remote_credentials is not accepted on this agent … - platform credentials need the local opt-in and the lock off; see Platform credentials.
• The Agent's activity log says the platform refused a delivery with sealing-key-unapproved - nobody has approved the sealing key the Agent reported yet: its first key after the opt-in was turned on, or a new key after a re-enrolment or certintel secret rotate-sealing-key. Approve it on the host page with Approve key (first key) or Approve new key if you expect it; see Sealing keys.

"starter hook certintel-KIND.sh is not installed"¶

Agent 1.14.0+ installs the starter hook itself when the workflow is approved on the device or applied by its auto-apply policy, so this message means one of: an earlier Agent; install-starter-hooks is off on the device (sudo certintel config set install-starter-hooks=on); or the root hook runner's socket is missing (sudo systemctl enable --now certintel-agent-hooks.socket). When the installation itself failed, the reason reads the starter hook certintel-KIND.sh could not be installed: … Nothing was changed on this device.; fix the cause named there and use Send again.

Otherwise a dashboard assignment of a Linux service template (for example haproxy-standard) needs the root starter hook on the host first. Run sudo certintel hooks starter KIND --write (or set the service up once in sudo certintel tui), check the paths in the written script, then use Send again on the workflow's page (the Agent gets a new proposal). The dashboard knows before you send: the form says Needs setup on the device: … and sending answers HTTP 422 with the same command; send once the Agent has reported the hook. hooks starter KIND --write reports it at once and says whether CertIntel knows it; a hook installed another way is reported with the Agent's next check of dashboard assignments (about every 5 minutes), or at once with sudo certintel assignments refresh. On Get a certificate for a server, step 6 shows the hook as the server last reported it (Installed, Not installed yet or Cannot run), reads the report again by itself every 15 seconds (Check again does so at once), and Propose the certificate appears once it is installed. The template's Agent folder must also be a folder the Agent may write; prepare it once with sudo certintel tui. See Linux service targets.

Renew now right after an issuance fails with "the CA could not verify domain ownership"¶

Renew now validates DNS-01 again. Within about a minute of the previous validation, the CA's resolvers can still hold the previous challenge value, and the CA refuses the new one (… the CA could not verify domain ownership (unauthorized)). Wait a minute and use Renew now again. After the CA refuses a validation, the next attempt places a new order.

A MySQL or MariaDB starter hook says "the server's ssl_cert is …"¶

The server serves the files its [mysqld] settings named when it started, and those are not the files the hook installs. Set ssl_cert, ssl_key and ssl_ca in the [mysqld] section to the files the hook installs (see Linux service targets), then restart the server once; MariaDB does not start while the files are missing, so restart it after the first certificate. The Agent retries the installation on its own.

A Microsoft service step fails¶

The Microsoft service templates were not verified on a live server. A failed binding step binds the previous certificate again. Check the message against the template's prerequisites, for example Reporting Services has no SSL binding on IP:PORT. Add the HTTPS URL in Report Server Configuration Manager first., There is no WinRM HTTPS listener at address …, The Routing and Remote Access VPN role is not installed and configured. or This computer is not a domain controller.

Server detection says "Read-only session"¶

On Linux, server detection runs only as root: in the terminal interface started with sudo certintel tui, or with sudo certintel servers detect. The service and the desktop path never run it; from Agent 1.14.0 the service asks the root hook runner to run it every 24 hours and when the dashboard's Check again asks. See Server detection.

Internal endpoints assigned in CertIntel are never checked¶

Platform-assigned checks are on by default and can be turned off on the device. Turn on Check internal endpoints assigned by CertIntel on the agent Overview (Windows) or with m on the Linux terminal interface's Agent Monitors screen, approve the change, and confirm the Internal endpoints assigned by CertIntel row under Settings → Schedules no longer says Disabled. The agent must also be registered or enrolled; an unconnected agent never polls.

The "CertIntel Private CA" choice does not appear, or is disabled, in the Agent¶

The Agent offers a Private CA only when the platform answers its availability probe with a list of CAs. Run certintel status --json and read private_ca.status and private_ca.detail: forbidden means the Agent's key has not been allowed to request certificates (an administrator turns on Allow private CA on the Agents page or Who may request certificates on the CA page) or the subscription lacks the feature; pending means the Agent itself is still waiting for approval; unsupported means the platform does not offer it; available with no CAs means no CA in the organization is active yet.

The Agent shows the entry disabled with the reason (not allowed for this agent (ask an administrator to Allow private CA), waiting for administrator approval, no active issuing CA is offered to this agent yet, availability unknown (see certintel status --json)), and notices an Allow private CA granted shortly after approval within about a minute. It picks a change up immediately with certintel private-ca refresh or a service restart; the full sequence (approve, allow, refresh) is under Enabling it for an Agent.

A Private CA client certificate is not trusted on Windows, or hosts stay on a retiring CA¶

A host that the CA page's Trust on hosts matrix shows as Trusted (server only) trusts the Private CA root for TLS server authentication only. Run certintel private-ca trust CA-ID again from an elevated prompt (or Trust this CA on this computer…) so the root is trusted for TLS server and client authentication; see Trust status on hosts.

When a CA page says hosts are still renewed from this retiring CA (needs Agent 1.5.0 or unlock to follow rotation), those Agents have the configuration lock on. They keep renewing from the retiring CA until it expires; unlock them. A successor under a different root needs certintel private-ca accept-rotation CERTIFICATE-ID on the device. See Rotation.

A dashboard assignment shows "Rejected" with a reason from the agent¶

The Agent refused the proposal before anyone on the device saw it (decided by agent). The reason names the first failing rule: the template is not bundled with that Agent or not available on its operating system, its version differs from the one the dashboard offered (the Agent was updated after its last capabilities report), a variable is unknown or has the wrong type, the certificate id already exists on the device, a name is invalid for the issuer, a file name or folder breaks its setting rule (setting "name": file name "site.pem" is not allowed: …), the Private CA is not an active CA that Agent may use (CertIntel Private CA issuance is not available to this agent (status forbidden) - see enabling it for an Agent), the ACME account is not configured on the Agent (nor one of the organization's ACME accounts), or the document carried something assignments cannot contain (unsupported assignment document: …). A re-sent revision of an assignment the device had already approved is refused too: create a new assignment instead of re-sending this one. When the cause is on the device (a missing hook, a folder, an account, the Private CA), fix it there and send the proposal again from the workflow's page: Send again, or Start a new round when several Agents may run the workflow. The Agent checks the proposal afresh. When the proposal itself was wrong, Edit the workflow; saving offers it again with the change. A workflow that several Agents may run moves on to the next Agent by itself when one rejects it. The Agent's Activity shows the same reason under assignment-rejected. A Rejected with decided by administrator is a person's decision on the device, with the reason they typed.

Sending a dashboard assignment fails with "file name … is not allowed"¶

The dashboard refuses a template setting the Agent would refuse, for example Setting 'Filename prefix (no extension)': file name 'site.pem' is not allowed: …. The message names what is wrong - an extension such as .pem (leave it out, the Agent adds it) or a Windows device name such as CON. See setting rules.

An organization ACME account is not on the device¶

The Agent writes organization ACME accounts into its configuration only when its auto-apply policy covers the organization and its configuration lock is off. Otherwise either approve a dashboard assignment that uses the account (approval adds it), or turn auto-apply on. certintel status --json shows platform_acme_accounts: auto_sync: false means auto-apply does not cover the organization, status unsupported a platform that does not offer them, pending an Agent awaiting approval, error a failed read (with detail). An account configured on the device with the same ID (org-…) is kept instead of the organization's. The Agent reads the list hourly and at its next heartbeat after a change; a service restart reads it at once.

Approving a dashboard assignment answers "conflict: revision N was reviewed but revision M now awaits approval"¶

Between your review and your approval the dashboard re-sent the assignment with changes, so the Agent refused to apply what you had not seen. Open the assignment again (Details, enter in the terminal interface, or certintel assignments show ID), check the new proposal and approve or reject it again. The related conflict: the configuration changed while the assignment was being applied; approve it again means another configuration change landed at the same moment; simply approve again. Both leave the proposal awaiting approval; nothing was written. In the desktop app the same situation means the list is older than the proposal: refresh it, open the assignment again and decide on the new revision.

certintel assignments approve says it "needs --revision N"¶

The command could not ask you to confirm: it ran without an interactive terminal (a script, an RMM tool, a redirected input) or with --json. Review the proposal with certintel assignments show ID; its last line is the exact command, certintel assignments approve ID --revision N, that approves the revision you just read. In an interactive elevated prompt approve ID without --revision shows the proposal and asks [y/N] instead.

The desktop app says an assignment "is too long to review in the approval dialog"¶

The administrator approval dialog shows every character of what it approves, and this proposal does not fit its pages. Nothing was approved. Open a prompt with Run as administrator, read the whole proposal with certintel assignments show ID, and approve it with the certintel assignments approve ID --revision N command the app (and show) names. Long single settings alone do not cause this: they are shown in numbered parts in the dialog.

Approving answers "unavailable: the CertIntel Private CA availability could not be confirmed"¶

The assignment names a CertIntel Private CA, and at that moment the Agent could not tell whether it may use it: it has not checked the Private CA yet with its current key, the last check failed, or its approval is pending. The proposal is fine and stays awaiting approval; check certintel private-ca list (or certintel status --json → private_ca.status; certintel private-ca refresh checks now) and approve again in a few minutes. The same situation keeps a newly sent Private CA assignment Pending in the dashboard until the Agent's next successful check.

The Agent's activity log says "Automatic application of dashboard-assigned workflows was turned off"¶

The Agent's auto-apply consent belonged to another connection: it was registered or enrolled with a different platform address, or the service started with a configuration whose consent names another platform than the one configured (or no valid organization). The Agent turned auto-apply off instead of applying proposals from a platform nobody consented to. If this platform should apply assignments without a local approval, turn auto-apply on again (certintel assignments policy --auto-apply on, the desktop checkbox or A in the terminal interface).

A dashboard assignment stays "Applying" with "issuance is being retried after a failed attempt"¶

The certificate and workflow were created, but the first Issue now attempt failed for a reason the Agent retries on its own: DNS propagation, a CA rate limit or a CA outage. The Agent's scheduled renewal pass retries; when the certificate is issued and the workflow delivered the assignment turns Applied with the thumbprint, and when the order is held (a policy rejection or exhausted attempts) it turns Failed with issuance stopped after repeated failures. Follow the certificate on the device meanwhile; see DNS troubleshooting for the common cause. The assignment settles at the Agent's next check after the pass.

The Agent's activity log says "the auto-apply policy no longer covers this assignment"¶

Auto-apply was turned off, or re-bound to another organization or platform, while a check was in flight. The proposal was not applied and now awaits a local approval like any other; approve or reject it on the device. Proposals that were already awaiting approval when auto-apply was turned on are never applied retroactively either, nor are the ones in the first list the Agent fetches after a reinstall or a new key. A proposal fetched by certintel assignments refresh or Check now is applied at the Agent's next own check, within about 5 minutes, not by the refresh.

A dashboard assignment shows "Failed"¶

Approval happened on the device but the Agent could not finish. If the message starts with the certificate and workflow are configured, but the issuance job failed or issuance stopped after repeated failures, the certificate and workflow exist; open the certificate on the device (or certintel jobs get ID with the job id from the assignment) for the ACME or Private CA error and issue again from there. Any other message means nothing was written: the Private CA was disabled or forbidden between approval and apply, or the merged configuration was invalid. A busy service or a storage error while saving does not fail the assignment; it stays awaiting approval and you approve it again. Create a new assignment once the cause is fixed; a failed one is final.

If the certificate was issued and only the check after installing it failed (for example step wait failed: cannot connect to …, see below), nothing has to be proposed again: make the site serve the files and run sudo certintel deployments retry ID on the device (the certificate id). The assignment then becomes Applied. The Agent keeps such an assignment Applying while it retries the installation; its card says when it tries again.

"step wait failed: cannot connect to host:port: …"¶

After installing a certificate, the workflow checks that the service answers on its port. The message names the host, the port and the cause, with what to do:

The Agent retries the installation by itself (see Get a certificate from the dashboard); sudo certintel deployments retry ID checks again at once.

Installing fails: "certificate thumbprints do not match"¶

After installing, the workflow checks that the site serves the new certificate; certificate thumbprints do not match means the site serves another one. The message names the endpoint, the certificate it served, the likely cause and what to check:

certificate thumbprints do not match: api.example.com:443 serves another certificate.
It serves web.example.com (names web.example.com; issuer …; expires 2027-01-09).
The web server has no site for api.example.com, so another site answers, or the site points at other files: check its certificate settings (the agent saves the files in /etc/certintel/certs/api-example-com) and reload it.

Usually the web server has no site (server block) for the name, so another site answers, or the site for the name points at other files; when the served certificate covers the name, the message says the site points at other files or the server was not reloaded. Add the site, or point its certificate lines at the files the Agent saves, reload the server, then run sudo certintel deployments retry ID (the certificate ID): it installs the issued certificate again and orders no new one. The Agent also tries again by itself. In the dashboard the renewal reads Installation failed, and its page offers Install again with that command instead of Renew now, which would order a new certificate and fix nothing.

A dashboard assignment stays "Pending", or shows "Cancelled" or "Expired"¶

Pending (Waiting for the agent to fetch it in the list) means the Agent has not fetched it yet. It checks every 5 minutes (Agent 1.13.0+ hears of a new proposal within about a minute), and within a minute for 15 minutes after approval; run certintel assignments refresh on the device or restart the service to check now, and read certintel status --json → dashboard_assignments.status: unsupported is a platform that does not offer assignments (checked again every six hours), pending means the Agent itself awaits approval on the Agents page, error carries the last network or server error in detail. Cancelled was a dashboard user's action before the device applied it; Expired means nobody approved within the assignment's lifetime (30 days by default). Both are final on the platform; on the device the record is closed without a report. If the device approved at the same moment the dashboard cancelled, the device wins and the state moves to Applied or Failed with an after cancel mark; other reports that arrive after a cancel or expiry show in the timeline as changing nothing. A Private CA assignment can stay Pending while the Agent cannot yet confirm that it may use the Private CA (see the unavailable entry above). Re-sending or cancelling a proposal whose lifetime has just run out is refused because it turns Expired first; send the workflow again from its page. A workflow that several Agents may run does not stay Pending on an Agent that is offline: after an hour the next Agent is offered it.

An Agent cannot be picked for a workflow: "Agent too old" or "Waiting for the agent's capabilities report"¶

New workflow on Workflow Assignments lists every Agent with the reason it cannot be ticked, and the Agent's row menu on Agents says the same in place of Workflows. Waiting for the agent's first heartbeat means the device has never reported; Agent too old: update it to 1.3.95 or later goes away after the update (it also appears for a client that is not the CertIntel Agent). An Agent whose configuration lock is on cannot be ticked until a local administrator turns the lock off. Waiting for the agent's capabilities report; it is sent within minutes of approval means the Agent is new enough but has not yet told the platform which templates, accounts and delegated names it has; it does so on its first check after approval and whenever they change. If it stays, run certintel assignments refresh on the device and check certintel status --json → dashboard_assignments for unsupported (the platform does not offer the feature yet) or an error detail.

The Agent's activity log says "The platform refused the … report for dashboard assignment …"¶

The device decided (assignment-report-refused), but the platform would not record the report: the assignment was deleted or belongs to another key (404), a newer revision or a terminal state already exists there (409), or the body was malformed (422). The local outcome stands - a created certificate and workflow stay on the device - and the dashboard keeps the state it had. One refusal is expected: when the dashboard re-sent an assignment while it was being approved on the device, the platform keeps the revision the device applied, so the Agent's refusal of the re-sent revision is answered 409. Compare certintel assignments list --all with the assignment's timeline; re-create the assignment if the dashboard must reflect the device.

validate --file or config apply --file reports "malformed JSON" for a valid file¶

The file is most likely UTF-16. In Windows PowerShell 5.1, > redirection writes UTF-16, which the Agent refuses; a UTF-8 byte-order mark, as Out-File -Encoding utf8 and Set-Content -Encoding UTF8 write, is accepted. Check with Format-Hex C:\certintel\config.json | Select-Object -First 1 (UTF-16 shows as FF FE) and write the file again as UTF-8: -Encoding ascii for ASCII-only content, [IO.File]::WriteAllText($path, $json, [Text.UTF8Encoding]::new($false)), or PowerShell 7 (pwsh), whose Out-File and > default to UTF-8 without a BOM. See Command-line configuration.

For any other file the message points at the actual problem: malformed JSON at line L, column C: reason for a syntax error, or invalid JSON fields or types at line L, column C: … for an unknown field or a value of the wrong type.

The Windows uninstall fails with "CertIntel data erasure was incomplete"¶

You chose to remove all data (or passed REMOVEALLDATA=1) and a folder or registry key could not be deleted, often because a file is open or permissions were changed. The uninstall stops rather than leaving protected data behind silently. Close programs using C:\ProgramData\CertIntelAgent, fix permissions, and retry the uninstall with REMOVEALLDATA=1.

API and dashboard¶

"401 Unauthorized" with no other detail¶

CertIntel deliberately gives the same generic 401 for a wrong secret, a revoked key, and an expired key - there's no way to distinguish them from the response, so a leaked key prefix can't be used to probe a key's state. Check, in order:

1. Is the key/prefix actually the one you think it is? Compare against the API Keys or Agents page.
2. Has it expired or been revoked? Both show clearly in the dashboard even though the API response doesn't distinguish them.
3. For an agent key specifically: is it still pending approval? See Install tokens & enrollment - a pending key returns a distinguishable 428, not a 401, so if you're seeing a plain 401 the key isn't the pending-approval case.
4. For an install-token exchange: the generic message is Invalid install token.; a one-time token whose secret matched says instead that it has already been used or has expired (see the agent cannot authenticate).

POST /api/v1/auth/logout also returns 401 Authentication required. when called without a session or key.

"404 Not Found" for something you're sure exists¶

CertIntel answers a cross-tenant or cross-organization id with 404, never 403 - this is deliberate, so a permission boundary never reveals whether something exists on the other side of it, only that you can't see it. If you're confident the resource exists, check that you (or the API key) are scoped to the right organization, and that a tenant-wide/organization-switcher filter isn't hiding it. An organization administrator also gets 404 for users who hold tenant-wide authority.

"422 Request validation failed." from a reporting script¶

A field exceeded its size limit and the whole request was rejected; nothing was stored. The response lists the field and message, for example String should have at most 32768 characters for log_output. Truncate before sending. The limits are listed under ACME check-ins & renewals and Internal certificate scanners.

A write-scoped key can't do something it should be able to¶

A write key does not grant general inventory reads or target management; specific Agent identity/policy and collection-assignment endpoints remain available as authorized by the server. If it also looks like it can't submit a specific kind of report, check whether it was narrowed to a subset of renewals / checkins / internal_certs at creation - see API keys & authentication.

The API answers 403 "This API key is read-only"¶

The key's API role holds only read permissions (the API read-only role, or a custom API role with reads only): it can read through the API (GET requests under /api/v1) and can't change anything, reveal an install token, download a private key or open dashboard pages. Use a key whose role holds the permission for the request, for example API operator; see API roles.

An organization administrator can't see something a tenant administrator can¶

This is usually correct behavior, not a bug: most resources are scoped to one child organization, and an organization-level role only ever sees its own organization's data - even tenant-wide (organization-less) resources are invisible to it. Tenant-wide visibility requires tenant administrator authority.

"This target cannot be monitored (resolves to a non-public or otherwise special-use address)."¶

Public endpoints, alert destinations and identity-provider discovery URLs must resolve to public internet addresses. Private ranges, loopback, link-local and carrier-grade NAT (100.64.0.0/10, used by Tailscale) are refused. A public endpoint with such an address is still created, but every check records this message instead of a probe result; identity-provider discovery reports URL host is not allowed (non-public/special-use address). Monitor internal hosts with an Agent's internal endpoints instead.

"The last active tenant administrator cannot be disabled." (or "...demoted.")¶

A tenant must always keep one active tenant administrator, and you cannot disable or demote yourself. Promote a successor first, then disable or demote the original account.

A site shows "not graded" or "Key exchange group unknown"¶

A site's TLS grade needs a captured certificate and at least one negotiated protocol version; it is assessed within an hour of a successful check, then once a day. Key exchange group unknown means CertIntel's own client could not see the negotiated group; it does not affect the grade. TLS 1.0 and 1.1 are tested only when you turn on Test TLS 1.0/1.1 too for that site.

CSV cells start with an apostrophe¶

Exported CSV cells that begin with =, +, -, @, a tab or a line break are prefixed with ' so a spreadsheet cannot interpret them as formulas. Spreadsheets hide the apostrophe; strip it in scripts if needed.

DNS-01 challenge never resolves¶

Almost always one of:

• The CNAME target was copied with a stray trailing character, or without the trailing dot some DNS providers require - use the copy button on the delegation record rather than retyping it. CertIntel's DNS answers only for the exact 32-character label it generated; anything else is NXDOMAIN.
• Cloudflare: the record is proxied (orange cloud) instead of DNS only (grey cloud) - see Delegated DNS-01 (dashboard).
• The CNAME hasn't propagated yet - DNS propagation delay, not a CertIntel issue; wait out your provider's TTL.

DNS-01 validation fails with a delegated record¶

Check the CNAME check column on Delegated DNS-01, or the CNAME check card on the record's page. CertIntel looks _acme-challenge.<name> up in public DNS and compares it with the record's CNAME target:

Validation for the name fails while its CNAME is missing or points elsewhere. CertIntel checks a new record by itself a few minutes after it is created (every 5 minutes during its first hour while the CNAME is missing, points elsewhere or cannot be looked up), when its page is opened, when an Agent reports a certificate issued for one of its names while its last check was not CNAME OK (at most every 5 minutes per record; also when installing the issued certificate then failed), and every few hours afterwards; a record not checked yet says Not checked yet: add the CNAME below at your DNS provider, then Check now. Check CNAMEs now on the list (up to 50 records, those checked longest ago first) or Check now on a record checks at once (10 checks a minute per workspace). DNS changes can take a few minutes to reach public resolvers, longer when the old record had a long TTL. active on a record means CertIntel answers the challenge for it; whether your CNAME points there is the CNAME check.