# macOS "This certificate is not trusted": Keychain fixes

> Keychain Access says "This certificate is not trusted" or "signed by an unknown authority". Why it happens on a Mac and how to fix it safely.

Source: https://ssl.sh/errors/macos-certificate-not-trusted/
Last updated: 2026-11-10

**"This certificate is not trusted" means macOS could not connect the certificate to a root it trusts, or a trust setting forbids it.** It appears in Keychain Access, in Safari and Mail certificate sheets, and behind Safari's "This Connection Is Not Private". The fix depends on who owns the certificate: a public site, your company or your own development setup.

## Is it the site or your device?

For public websites it is usually the site; for internal and development certificates it is your Mac's trust settings. For a public website, check it with the [SSL checker](https://ssl.sh/tools/ssl-checker/):

```bash
curl ssl.sh/example.com
```

- **The checker flags the chain:** the site needs fixing; do not override trust on your Mac.
- **The checker passes:** compare the certificate shown on your Mac with the checker's. A different issuer means interception (antivirus, proxy or a profile). The same certificate means a local trust setting is off.

On the Mac itself, test with Apple's tools:

```bash
security verify-cert -c server.pem -p ssl -s example.com
```

## Causes

### 1. Self-signed or private-CA certificate

Internal servers and development tools use certificates whose root is not in the System Roots keychain. Expected; install the CA root deliberately or switch to a public certificate.

### 2. Missing intermediate

The server sends only the leaf; macOS usually fetches the intermediate, but not when the AIA URL is unreachable. Fix the server's chain with the [chain builder](https://ssl.sh/tools/chain-builder/).

### 3. Trust setting changed

A root or intermediate set to "Never Trust" in Keychain Access, or restricted by a configuration profile, overrides the system default.

### 4. Certificate breaks Apple's TLS rules

For TLS, macOS requires SAN entries, RSA keys of at least 2048 bits, SHA-2 signatures, the serverAuth EKU and limited validity (825 days for certificates issued after 1 July 2019, 398 days for publicly trusted ones issued after 1 September 2020). Homemade certificates often miss one of these.

### 5. Interception software

Security tools that inspect HTTPS install their root in the System keychain. If that install failed or was removed, intercepted sites show as untrusted.

## What it looks like on each device

| Where | What you see |
|---|---|
| Keychain Access | Red icon and "This certificate is not trusted" or "This root certificate is not trusted" |
| Safari | ["This Connection Is Not Private"](https://ssl.sh/errors/safari-this-connection-is-not-private/) |
| Mail | "Mail can't verify the identity of the server" |
| Chrome on macOS | [NET::ERR_CERT_AUTHORITY_INVALID](https://ssl.sh/errors/net-err-cert-authority-invalid/) |

## How site owners fix it

Public sites need a full chain from a public CA; internal CAs need their root trusted on each Mac.

**1. Public sites:** serve a full chain from a public CA and confirm with `curl ssl.sh/example.com`.

**2. Company or development CAs:** trust the root, not individual server certificates. From Terminal:

```bash
sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain company-root.crt
```

Or in Keychain Access, double-click the root, open Trust, and set "When using this certificate" to "Always Trust". For many Macs, deploy the root with an MDM profile instead.

**3. Reissue non-compliant certificates** so they meet Apple's requirements, and check them with the [certificate decoder](https://ssl.sh/tools/certificate-decoder/) before deploying.