Phones and operating systems
macOS "This certificate is not trusted": Keychain fixes
This certificate is not trusted"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:
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:
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.
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" |
| "Mail can't verify the identity of the server" | |
| Chrome on macOS | 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:
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 before deploying.
FAQ
Should I set a website's certificate to Always Trust?
Not for websites you do not control. Doing so tells your Mac to accept that certificate even if it was issued to an impersonator. Use Always Trust only for your own development or company CA root, installed from a trusted source.
Why does Chrome still warn after I trusted the root in Keychain?
Chrome on macOS honours roots trusted in the System or login keychain for TLS, but needs a restart to pick up changes. Firefox uses its own store unless enterprise roots are enabled. Also confirm the certificate meets Apple's rules, which Safari enforces.
A system root shows as not trusted. What happened?
Someone may have changed its trust setting manually, or a profile restricted it. In Keychain Access open the System Roots keychain, double-click the root, and set "When using this certificate" back to Use System Defaults.