Safari Can’t Verify the Identity of the Website: Diagnosis and Fixes

Before applying any fix, apply one diagnostic test. Open the same URL in Chrome on the same device. Two possible outcomes determine everything:

Chrome also shows an error: the problem is the certificate itself, the server’s SSL configuration, or a device-level issue affecting all browsers. The certificate is broken in a way that both browsers reject.

Chrome loads fine, Safari errors: the problem is Safari-specific. This is the most commonly overlooked distinction and the one that most troubleshooting guides skip. Safari uses Apple’s Keychain trust store and enforces Apple’s specific certificate requirements. Chrome uses its own certificate verification engine. A certificate that passes Chrome’s checks can fail Safari’s for specific, diagnosable reasons.

This article covers both paths. Identify which applies to you, then go to the relevant section.

Why Safari Behaves Differently From Chrome

Understanding Safari’s architecture explains why it shows this error when Chrome does not. This is not a Safari bug. It reflects deliberate design choices Apple has made about certificate trust on its platforms.

Safari uses macOS/iOS Keychain for certificate trust

Safari delegates all certificate validation to Apple’s Security framework, which uses the Keychain as its trust store. The Keychain contains trusted root certificates, pinned certificates, user-trusted certificates, and cached validation results. Chrome builds and maintains its own certificate verification engine (BoringSSL with Chrome Root Store) separately from the OS trust store.

When the Keychain contains a stale, corrupted, or conflicting certificate entry for a domain, Safari’s validation fails while Chrome, using its separate engine, may succeed. This is the most common explanation for Safari-specific errors on sites that work perfectly in Chrome.

Apple enforces Certificate Transparency requirements

Apple’s Certificate Transparency policy requires that all publicly trusted TLS certificates issued after October 15, 2018 must be logged in at least two CT logs and include Signed Certificate Timestamps (SCTs) as proof of logging. Certificates without compliant CT logging are treated the same as expired or self-signed certificates on all Apple platforms: failed TLS connection.

This requirement applies to Safari, iOS apps, and macOS apps across the entire Apple platform, not just the browser. A certificate that Chrome accepts without CT issues might fail Apple’s CT checks if the SCT configuration is marginal or if a CT log it was logged to was subsequently removed from Apple’s approved list.

Apple prohibits SHA-1 in the certificate chain

Since iOS 11 and macOS 10.13 (High Sierra), Apple does not allow SHA-1 certificates in TLS connections unless the user explicitly trusts them. This applies to the entire chain: a leaf certificate signed with SHA-256 but with an intermediate CA certificate using SHA-1 fails on Apple platforms. Chrome has different (more permissive) SHA-1 handling. A server presenting a legacy SHA-1 intermediate fails in Safari while potentially loading in Chrome.

App Transport Security applies to all iOS/macOS apps

App Transport Security (ATS) requires that all network connections from apps compiled for iOS 9 or later and macOS 10.11 or later meet minimum security requirements: TLS 1.2 or higher, forward secrecy cipher suites, SHA-256 or stronger certificates, and RSA keys of at least 2048 bits. Safari uses WebKit, which applies these requirements. If the server’s TLS configuration does not meet ATS requirements, connections from Apple platforms fail regardless of whether the certificate itself is valid.

The practical consequence: a site that works in Chrome on Android or Windows may consistently fail in Safari on Mac and iPhone for the same underlying certificate issue. The error message ‘Safari can’t verify the identity of the website’ covers identity verification failures, certificate chain problems, CT compliance failures, SHA-1 in the chain, and ATS mismatches. The message is the same; the causes require different fixes.

Diagnostic Decision Tree: Finding the Actual Cause

Apply these checks in order. Each check either identifies the cause or moves you to the next check.

Path A: Fixes When the Error Is on Your Device (Chrome Also Has No Issue)

If Chrome loads the site without error and Safari fails, the problem is in your Safari environment, not the site’s certificate. These fixes address the Safari-side causes.

Fix 1: Correct your system clock

Certificate validation checks the certificate’s validity period against the current time. A significantly wrong clock causes ALL certificate validation to fail simultaneously across many sites. On macOS: Apple menu, System Settings, General, Date and Time. Enable Set date and time automatically using a time server. On iOS: Settings, General, Date and Time, enable Set Automatically.

Verify the correction by reloading Safari after enabling automatic time sync.

Fix 2: Remove stale Keychain certificate entries

Safari’s certificate trust evaluations are cached in the macOS Keychain. A stale or corrupted certificate entry for a specific site causes persistent validation failures for that site only. Remove it:

1. Open Keychain Access (Applications, Utilities, Keychain Access)
2. In the search field, type the domain name of the failing site
3. Look for any certificate entries for that domain. Right-click and select Delete.
4. Also look in the System and Login keychains.
5. Quit Safari completely (Command-Q, not just closing the window)
6. Reopen Safari and try the site again

For iOS, clearing cached certificate data requires a different approach. Go to Settings, General, Transfer or Reset iPhone, Reset, Reset Network Settings. Warning: this removes all saved Wi-Fi passwords. A less disruptive option for a specific site is to install a fresh profile through Safari and trust it explicitly if the issue involves an enterprise certificate.

Fix 3: Disable VPN or proxy

VPNs that perform traffic inspection and corporate network SSL inspection proxies intercept HTTPS connections and present their own certificate to Safari instead of the server’s certificate. If the proxy’s CA certificate is not in the Keychain trust store, Safari rejects it with the identity verification error.

Test by turning off any active VPN and retrying the site on your regular network. If the error disappears, the VPN’s certificate is not trusted by your device. For a corporate VPN proxy, contact IT to install the proxy’s CA certificate on your device.

Fix 4: Disable Safari extensions

Some Safari extensions, particularly content blockers and privacy tools, can interfere with Safari’s certificate validation or block resources needed to complete the chain validation. In Safari on macOS: Safari menu, Settings (or Preferences), Extensions. Disable all extensions. Reload the page. If the error clears, re-enable extensions one at a time to identify which one causes the problem.

Fix 5: Clear Safari’s website data

Safari caches HSTS (HTTP Strict Transport Security) policies, certificate pinning data, and other security-related information per site. Clearing this data removes potentially stale cached state. In Safari on macOS: Safari menu, Settings, Privacy, Manage Website Data, remove data for the specific site. In Safari on iOS: Settings, Safari, Advanced, Website Data, find and remove the site.

Fix 6: Update macOS or iOS

Apple periodically updates the trust store (the list of trusted root certificates), Certificate Transparency log lists, and revocation data through OS updates. A CA root that was added after your last update may not be in your trust store. New macOS and iOS versions also fix Safari bugs related to certificate handling. Run available OS updates before concluding the site’s certificate is broken.

Path B: Fixes When the Certificate or Server Is the Problem (Chrome Also Shows Error or Site Owners Only)

If Chrome also shows an error, or if you own the site and visitors are reporting the error, the certificate or server configuration needs fixing.

Fix 1: Renew the expired certificate

Expired certificates are the most common cause. The Safari error dialog shows the certificate expiry date when you click Show Certificate. If it has passed the Not After date, renew the certificate through your CA or let AutoSSL on your hosting platform reissue it. Deploy the new certificate and verify the deployment with the SSL Labs test at ssllabs.com/ssltest.

Fix 2: Fix the certificate chain

A missing or outdated intermediate CA certificate is the second most common server-side cause. Safari requires the complete chain: leaf certificate plus all intermediate certificates up to (but not necessarily including) the root. If the intermediate is missing, Safari fails to build a trusted chain even if Chrome succeeds (Chrome uses AIA fetching to retrieve missing intermediates; Safari may not in all cases).

Check the chain with the SSL Labs test. The Chain Issues field shows ‘Incomplete’ or ‘Contains anchor’ if the chain is misconfigured. Fix by updating the certificate bundle on the web server to include the complete chain. For Nginx, use ssl_certificate pointing to a file that concatenates the leaf certificate followed by the intermediate. For Apache, use SSLCertificateChainFile or include the chain in the certificate file.

Fix 3: Address Apple-specific SSL requirements

If the SSL Labs test passes but the site fails specifically on Apple platforms (Safari on Mac and iPhone but not Chrome), check for Apple-specific requirements:

• SHA-1 in the chain: Any certificate in the chain using SHA-1 signing fails on iOS 11+ and macOS 10.13+. Check the SSL Labs test for ‘Chain’ and look for SHA1withRSA or similar. Replace any SHA-1 intermediate or root certificate with a SHA-256 equivalent chain.
• Certificate Transparency: The certificate must include at least two SCTs from approved CT logs. All certificates from major public CAs automatically include SCTs. If using a certificate from an unusual or private CA, check whether it meets Apple’s CT requirements. Run the SSL Labs test and check the Certificate Transparency section.
• RSA key size below 2048 bits: Apple rejects RSA keys shorter than 2048 bits. This is rare in modern certificates but can appear in very old or internally-issued certificates. Reissue the certificate with a 2048-bit or larger RSA key, or use an ECDSA key.
• TLS version: Apple requires TLS 1.2 or higher. A server configured to use only TLS 1.0 or 1.1 fails ATS requirements. Update the server’s TLS configuration to enable TLS 1.2 and TLS 1.3.

Certificate Transparency compliance is handled automatically by all major Certificate Authorities (DigiCert, Sectigo, Let’s Encrypt, GlobalSign). If your certificate is from a publicly trusted CA, CT compliance is already built in. The CT requirement only becomes relevant if you are using a certificate from a non-standard or internal CA, or if a CT log that your certificate was logged to was removed from Apple’s approved list after issuance. Check the SSL Labs test for any CT warnings.

The Email Client Variant: ‘Cannot Verify Server Identity’ on iPhone and iPad

A related but distinct error appears in iOS Mail, macOS Mail, and other Apple email apps: ‘Cannot Verify Server Identity.’ This error has the same underlying cause as the Safari error but occurs when the mail app attempts a secure connection to your IMAP, SMTP, or Exchange server.

The most common cause is a hostname mismatch: the mail server hostname in your account settings (for example, mail.yourdomain.com) does not match any SAN entry in the mail server’s SSL certificate. A certificate issued for webmail.yourdomain.com does not cover mail.yourdomain.com. Apple’s mail apps enforce strict hostname matching.

Secondary causes: the mail server’s certificate has expired, the certificate chain is incomplete, or the certificate is self-signed and not trusted in the iOS/macOS Keychain.

Fixes:

• Check the exact hostname in your email account settings matches what is in the mail server’s certificate SAN entries.
• If your hosting provider has changed their mail server hostname, update the settings in the mail app to match the new certificate.
• If the mail server uses a self-signed certificate, the certificate must be manually trusted: tap Continue or Details in the iOS prompt to view and trust the certificate explicitly.
• Contact your email provider or hosting company for the correct, certificate-matching mail server hostname.

When (If Ever) Is It Safe to Proceed Past the Warning?

Safari offers a Continue button on some certificate errors. The safety of proceeding depends entirely on what caused the error.

Never proceed past a certificate warning on banking websites, email login pages, password managers, or any site where you would enter credentials or payment information. A certificate error on these sites may indicate that your connection has been intercepted. If the error appeared suddenly on a site that previously worked, and you are on an unfamiliar network, change networks and retry before proceeding.

Frequently Asked Questions

Why does Safari show this error but Chrome does not on the same site?

Safari and Chrome use different certificate validation engines. Safari uses Apple’s Security framework and the Keychain trust store. Chrome uses its own BoringSSL-based engine and the Chrome Root Store. Differences that cause Safari-specific failures include: a stale or corrupted certificate entry in the macOS Keychain, Apple’s Certificate Transparency requirements (stricter than Chrome’s for specific cases), Apple’s prohibition on SHA-1 in any part of the certificate chain, and App Transport Security requirements for TLS version and key size. A site can have a certificate that Chrome accepts while Safari’s stricter validation rejects it.

What does ‘Safari can’t verify the identity of the website’ mean?

It means Safari could not confirm that the certificate presented by the server legitimately belongs to the domain you are trying to reach. This can happen because the certificate is expired, the certificate’s domain does not match the URL, the certificate was not issued by a trusted Certificate Authority, the certificate chain is incomplete (missing intermediate), or a Safari-specific validation requirement failed (CT compliance, SHA-1 prohibition, ATS requirements). The connection may be encrypted but the identity of the server cannot be confirmed.

Is the website safe if I see this error?

Not always. The error means Safari cannot verify the website is who it claims to be. In most cases it is a technical misconfiguration rather than an active attack, but you cannot be certain without investigating. If you are on a public or unfamiliar network, the error could indicate a man-in-the-middle interception. If you just changed networks or installed a new VPN and the error appeared, it is likely a proxy certificate. If the error appeared suddenly on a site you have used safely for years with no network changes, investigate before proceeding. Do not enter passwords or payment information on a site showing this error.

How do I permanently trust a certificate in Safari?

For a certificate you want to permanently trust in Safari on macOS: click Show Certificate in the error dialog, then expand the Trust section. Change the SSL dropdown from System Default to Always Trust. Enter your administrator password when prompted. The certificate is added to the Keychain with the Always Trust setting and Safari will no longer show the error for that certificate. On iOS, you can tap Details and then Trust in the certificate warning prompt, or install the certificate through a configuration profile via Settings, General, VPN and Device Management.