Skip to main content
Certificate problems cover — one page for the whole certificate story. This is the single page for every AgenShield certificate symptom. Find yours in the table, then read that section.

​
The two commands, if you already know what you are doing

Check (if it reports CSSMERR_TP_NOT_TRUSTED, run it again with -p ssl added before concluding anything — see below):
Fix (asks for your password), then fully quit and reopen any AI agent that had stopped connecting:
Everything below explains what these do, when you need them, and what to do if the warning does not clear afterwards.

​
First: check what state you are in

Run this in Terminal. It is read-only and safe.
Type the command, or paste it as plain text. Chat apps, email clients and some browsers silently turn straight quotes (") into curly ones (”). The shell does not treat curly quotes as quotes, so the command ends up looking for a file whose name literally contains them and answers ***Error reading file — which looks like a missing certificate when nothing is missing. Every command on this page avoids quotes for that reason.Running the check with sudo makes no difference and is not needed: trust settings are readable by everyone. A sudo run that disagrees with a plain one means something else is wrong — see When to escalate.
If you saw CSSMERR_TP_NOT_TRUSTED, check TLS trust specifically:
  • It reports ...certificate verification successful: the certificate is trusted for exactly what AgenShield needs. This is how most MDM certificate profiles install it, and nothing needs fixing. On 2026.9.0 and earlier the setup card can still show for this form; from 2026.9.1 it is recognised.
  • It also reports CSSMERR_TP_NOT_TRUSTED: the certificate exists but is not trusted. Go to Certificate not trusted.

​
Certificate not trusted

​
What this means

The certificate was created on this Mac. What did not happen is the second half — recording it as trusted in the system keychain, which needs an administrator password. Until that completes:
  • Encrypted (HTTPS) traffic is not inspected. Network observation runs degraded, and AgenShield suspends inspection rather than interfering with connections.
  • Everything else is unaffected. The security and network extensions keep enforcing, your organization’s policy keeps syncing, and command and file activity keeps being recorded.
This is a gap in coverage, not an unprotected machine.
On 2026.9.0 and earlier, an untrusted certificate can break tools, not just reduce visibility. AgenShield inspected encrypted connections even while its own certificate was untrusted. Applications that read the system keychain — which includes most command-line AI agents and other tools not built on Node.js — could not verify the connection and saw it close immediately. The usual report is an AI assistant saying a server is unreachable, closed, or has been disabled, while a browser on the same Mac is fine.From 2026.9.1, inspection is suspended automatically whenever the certificate is untrusted, so connections keep working and only visibility is reduced. Trusting the certificate restores inspection with no further action.

​
The most common cause: nobody was at the keyboard

If AgenShield was installed by your IT team without anyone signed in — a zero-touch deployment, or an install that ran overnight — the Mac was almost certainly at the login screen or locked. The certificate step needs the Mac unlocked, because it needs a user session and an administrator password. It cannot complete on a locked Mac; it waits for someone to unlock. If that describes your Mac, unlock it and sign in. That lets the step proceed — but it does not finish on its own: macOS still has to ask for an administrator password, and someone has to approve that prompt. The setup card clears only once AgenShield has confirmed the certificate is trusted — which is after the prompt is approved, not after the unlock.

​
The same cause after an overnight update

AgenShield updates itself automatically, and an update can run while the Mac is asleep — macOS wakes briefly in the background for maintenance with the display off. If the certificate is not yet trusted when that happens, the update has to ask for an administrator password at a moment when nobody can see the request. On an affected version, use How to fix it below; it takes one password.

​
How to fix it

1

Use the menu bar action (preferred)

Open the AgenShield menu bar item and choose Trust Certificate, then enter your administrator password when macOS asks.This is the supported path: it keeps the app’s own state in step, and the setup card clears on its own once it succeeds.
2

If the action is missing or the prompt never appears, run it yourself

Copy and paste both lines. The first asks macOS to trust the certificate and will prompt for your password; the second confirms it worked.
Expect ...certificate verification successful from the second command.
What this command does, so you can decide with your eyes open. It marks the AgenShield certificate — the one already on this Mac at the path shown — as a trusted root, which is what lets AgenShield inspect encrypted traffic. It is the same operation the Trust Certificate menu action performs; running it by hand only removes AgenShield from the middle of it. It grants nothing to any other certificate, and it can be undone at any time with sudo security remove-trusted-cert -d ~/.agenshield/mitm-ca.pem.
Do not add -p ssl. You will find that flag in most general guidance about trusting an interception certificate, and the instinct is sound — it scopes trust to TLS instead of granting it for every purpose.But macOS then records the trust differently, and the standard check — security verify-cert without a policy — reports CSSMERR_TP_NOT_TRUSTED for it. On 2026.9.0 and earlier AgenShield used only that check, so a certificate trusted with -p ssl reads as untrusted and the setup card never clears.Use the command exactly as written above. From 2026.9.1 AgenShield also checks TLS trust specifically, so an -p ssl certificate — including one installed by your MDM — is recognised as trusted and inspection stays on.
3

Reopen the apps that were failing

An AI agent that already marked a server unreachable will not retry on its own. Quit it fully and start it again.
Keychain Access works too — in the System keychain. Open Keychain Access, select the System keychain, double-click AgenShield CA, expand Trust, set When using this certificate to Always Trust, then close the window and enter your administrator password. Keychain Access should then say “This certificate is marked as trusted for all users”. If it says “trusted for this account” instead, see Trusted for your account only.

​
Trusted for your account only

What it means. The certificate is trusted in your own macOS account’s settings, not in the system-wide ones. Keychain Access describes this as “trusted for this account”. Apps you run can verify inspected connections, but AgenShield’s background service runs for the whole Mac, not as you — it still sees the certificate as untrusted, so it keeps network inspection suspended. How to confirm. In Keychain Access, open AgenShield CA and read the line under the certificate name: “trusted for this account” means this state; “trusted for all users” means system-wide trust is in place. How to fix it. Choose Trust Certificate in the menu bar (one administrator password), or run the command in How to fix it. Either adds system-wide trust; the account-level setting can stay. The menu bar shows this state from the release after 2026.10.2; earlier versions show it as installed (not trusted).
Administrator rights are needed only to approve the prompt. AgenShield tries the non-interactive route first and, where that succeeds, no password is asked for at all — so a standard-user account is not automatically blocked here.When the prompt is required and your account is a standard user, someone with administrator rights has to approve it. Fleets can remove the per-device step entirely by distributing the certificate through MDM — see MDM deployment.

​
The command worked, but the warning is still showing

This is expected on 2026.9.0 and earlier, and it does not mean the fix failed. Confirm the fix first:
If that reports success, the certificate is trusted. What you are still seeing is a stale reading: AgenShield’s background service checks trust at startup and caches the answer, and it has no way to notice that you changed the system trust settings by hand. Quitting and reopening the AgenShield app does not clear it — the background service keeps running independently of the app. Restart the background service and the card clears within a few seconds:
From 2026.9.1 the service re-checks on its own, but after the first few minutes only about once an hour, and after a day not at all. On 2026.10.2 and earlier that is why the menu bar can keep showing installed (not trusted) for up to an hour after you trusted the certificate yourself — in Keychain Access, with the command above, or even with Trust Certificate — because the menu bar defers to the background service’s last answer. From the release after 2026.10.2, the menu bar notices the change within about 30 seconds and asks the background service to check again immediately, so the warning clears on its own and the restart above is not needed.
On 2026.9.1 and later there is a second reason not to leave this stale: while AgenShield believes the certificate is untrusted it suspends traffic inspection, so that connections keep working. Until the service picks the change up, inspection stays off on a Mac that is actually fine.

​
If it comes back

  • You dismissed the password prompt once. AgenShield deliberately does not re-ask immediately — repeatedly prompting for a password nobody wanted to give is worse than waiting. Use Trust Certificate from the menu bar when you are ready, or run the command above.
  • It reappears after every update. See Password prompt after an update.
  • It reappears on many Macs at once. Ask your IT team whether your organization can distribute a company-wide certificate through MDM, which removes the per-device step entirely. See MDM deployment.

​
Seeing it across the fleet

In the Frontegg Portal, Devices → the Setup filter narrows the list to every device still waiting on the certificate, so you can tell one stuck Mac from a rollout-wide gap. See Fleet setup status.

​
Password prompt after an update

​
What you are seeing

Shortly after AgenShield updates itself, macOS shows its standard administrator dialog asking to modify the system certificate trust settings. It may appear while you are working, and again on the next update.

​
What it means

In affected versions this prompt could appear even when the certificate had not changed at all. Two internal checks ran at the same moment and interfered with each other; one briefly could not confirm the certificate’s status, and AgenShield responded by asking macOS to re-apply trust — which needs your password. Your protection was not affected. The certificate was already installed and already trusted throughout. Network inspection kept working whether you entered your password or dismissed the dialog. In 2026.8.4 and earlier, an update could finish by warning that the certificate was not trusted and that inspected connections would fail — even though it had been installed and trusted seconds earlier. Two checks that run at the end of an update could interfere with each other, and the second reported a failure that had not happened. The warning was cosmetic. Network inspection kept working normally. To confirm your own Mac is fine, run the check command. If it reports success, the warning was the false one and there is nothing to do.

​
Prompt although MDM installed the root

Your MDM profile installs the AgenShield root certificate, yet right after an update from 2026.10.2 macOS asked an administrator to trust an AgenShield certificate (seen on macOS 26.5). The update renews, once, the certificate this Mac had generated for itself, and macOS cannot trust that one without asking. Affected versions kept using it unless your organization’s certificate policy was switched in the Frontegg Portal, so the root delivered by your profile was not used. From the fixed version on, a Mac whose profile installs the root uses a certificate issued under that root as soon as it updates, whatever the policy says, and never asks for trust. Until then, approving or dismissing the dialog are both safe: dismissing it only pauses inspection of encrypted traffic until the certificate is trusted. Macs installed with the installation script. A Mac on which AgenShield was installed with an enrollment token (the installation script or a token on the command line) and that also receives your MDM profile kept asking after every update, even on the versions above. AgenShield deliberately keeps such a Mac in the organization its token chose, and it wrongly applied the same rule to the certificate your profile installs. From the fixed version on, the root your profile delivers is used on these Macs too, and they are not asked to trust a certificate. You do not need to create a new campaign, re-upload the profile or reinstall: updating is enough.

​
What to do

1

You can safely dismiss it

Click Cancel. Nothing breaks — AgenShield will not re-show it in a loop, and inspection continues normally.
2

Entering your password is also fine

Approving simply re-applies trust settings that were already in place.
3

Update to the fixed version

On 2026.8.5 or later the prompt stops appearing for a certificate that has not changed.

​
When a prompt IS expected

A genuine request for your password is normal in one case: when the certificate has actually been renewed or replaced. macOS treats a new certificate as new, and approving it once is required. That is a rare, deliberate event — not something that should accompany routine updates. The update that fixes the format error in git or curl is one of these: it re-issues the certificate once, so expect one prompt after it.

​
Expired certificate errors

​
What you are seeing

An AI agent (an AI coding assistant, an MCP client, or similar) fails to connect over HTTPS with a certificate-expired error such as CERT_HAS_EXPIRED. Typically it fails for every inspected destination at once, while the same sites open normally in a browser or in a tool that is not being inspected.

​
What is actually happening

For the connections it inspects, AgenShield presents its own certificate for the destination, issued under the AgenShield root your organization installed. Those per-site certificates are short-lived and normally re-issued automatically. In affected versions the background service could keep re-using a previously issued per-site certificate after it had expired. After about a week of continuous uptime those certificates aged out, so the agent received an expired certificate for every inspected destination. Two things confirm this is the cause rather than a problem with the destination:
  • The destination’s own certificate is valid — the site opens fine in a browser or in any tool AgenShield is not inspecting.
  • The AgenShield root certificate is valid — it has a normal multi-month lifetime and is unchanged. The check command confirms this.
Only the short-lived per-site certificate is expired.

​
How to recover now

Restart the background service, or restart the machine. That discards the stored per-site certificates, and the next connection is issued a fresh one, so inspected connections work again immediately. This is temporary — on an affected version the problem can return after about a week of continuous uptime. Updating is the durable fix. AgenShield now checks a stored per-site certificate’s expiry before re-using it and issues a fresh one instead of presenting an expired certificate. No configuration change is needed.

​
Format error in git or curl

​
What you are seeing

git or curl fails on a site that AgenShield inspects, while the same site works in a browser and in your AI agent’s own requests:
It happens with the git and curl that ship with macOS, which an AI agent uses whenever it fetches a repository or downloads a file.

​
What it means

The certificates AgenShield used for inspection wrote their validity dates in a format the certificate standard does not allow for dates before 2050. Most software accepts it anyway; the TLS library built into macOS’s own git and curl does not, and rejects the AgenShield root certificate itself. Nothing is expired and nothing is misconfigured on your Mac.

​
How to fix it

Update AgenShield. The fixed version issues its certificates in the standard format and re-issues the AgenShield root certificate once on each Mac, with the same key. macOS treats the re-issued certificate as new, so you will be asked once to approve it (see Certificate not trusted if nobody is at the Mac when the update runs). After that, git and curl work against inspected sites, and the previous certificate is removed automatically. Until you update, a git or curl that you install yourself (for example from Homebrew) is not affected.

​
An agent that was already running stops trusting AgenShield

​
What you are seeing

An AI agent that has been running for a while (a Claude Code session, Cursor, an MCP client) suddenly fails every request to an inspected destination, often an HTTP MCP server, with:
A new session of the same agent on the same Mac, started now, connects without a problem. So do curl and the browser.

​
What it means

Most AI agents read the certificates they trust once, when they start, and never look again. AgenShield’s root certificate changed while the agent was running, so the agent still trusts the old one and rejects the new one. The root certificate changes when:
  • AgenShield is reinstalled, or the Mac is enrolled into a different campaign;
  • your organization rotates its campaign certificate;
  • during installation, for a few seconds, while the Mac receives its own certificate.
Nothing is wrong with the Mac’s trust settings. The certificate on disk and in the System keychain is the new one, and it is trusted.

​
How to fix it

Quit the agent and start it again. For Claude Code, exit the session and run claude again (claude --resume continues where you left off). For Cursor or VS Code, quit the app completely and reopen it, so that its background processes restart too.

​
Planned certificate rotations

From the first AgenShield release after October 27, 2026, AgenShield adds your organization’s next certificate to the agents’ trusted certificates as soon as the rotation is prepared, and reports the Mac as ready only after that. Agents started after that point keep working through the switch. An agent that was already running before the rotation was prepared still needs a restart, as does every running agent after a reinstall or a move to another campaign.

​
When to escalate

Collect a diagnostics bundle and contact support if:
  • ~/.agenshield/mitm-ca.pem does not exist even after the Mac has been unlocked and signed in for a few minutes;
  • verify-cert still fails right after the add-trusted-cert command reports success;
  • the setup step clears and then returns without an update having been installed;
  • the prompt still appears on every update on 2026.8.5 or later;
  • connections still fail with a certificate-expired error after updating and restarting;
  • a newly started agent fails with unable to get local issuer certificate.
Include the exact error text and the destination host. See Collecting diagnostics.