In short. The error "cannot verify the server's certificate (or identity)" means a program — a mail client, browser, or app — connected to a server over a secure connection but couldn't confirm that its SSL certificate is genuine and issued for that address. There are only a few causes: the name in the certificate doesn't match the server's address, the certificate is expired or self-signed, the server sends an incomplete chain, the device's date is wrong, or the revocation-checking server (CRL/OCSP) is unreachable. All of it is diagnosed in a minute: check the server's certificate — who it's issued to, until when, and whether the whole chain is present. Below is what each cause means and how to fix it.
Where this error appears
The wording varies, but the meaning is one — the client doesn't trust the server's certificate:
- "Cannot verify server certificate" — in mail clients and apps when connecting to a mail server (IMAP/SMTP).
- "Cannot Verify Server Identity" — on iPhone and Mac in Mail when adding an account.
- "The revocation server was offline, unable to verify" — when the client can't reach the revocation-checking service (CRL/OCSP).
Note: this is specifically about the server's SSL certificate (mail or web). If you were looking for a game-server error like "failed to verify username," that's something else — about game login, not a certificate.
The "cannot verify certificate" error isn't about the server being broken but about trust: encryption works, but the client can't confirm the other end is really the server it claims to be. Until that's confirmed, a safe client refuses to continue.
Five causes and how to tell them apart
Diagnosis starts with one step — look at the server's certificate itself via an SSL check: it shows who it's issued to, until when, by whom, and whether the server sends the whole chain. Then, by cause:
| Cause | How it looks | Fix |
|---|---|---|
| Name mismatch | The cert is issued for a different domain (e.g. for mail.host.com while you connect via mail.yourdomain.com) | Connect by the name in the cert, or issue a cert for the right name |
| Certificate expired | The "valid until" date is in the past | Reissue/renew the certificate on the server |
| Self-signed | Issuer = the server itself, no trusted authority | Install a cert from a trusted CA (e.g. free Let's Encrypt) |
| Incomplete chain | The server sends only its own cert without the intermediate | Add the intermediate certificate to the server config |
| Wrong date on the device | Error for one user while everyone else is fine | Set the correct date and time on the device |
A special case: "revocation server offline"
The wording "the revocation server was offline, unable to verify" means the client couldn't reach the certificate-revocation service (CRL or OCSP) — for example, due to network filtering or temporary unavailability. The certificate itself may be fine; the problem is access to the check. Retrying later or checking whether the network/firewall blocks the revocation services often helps.
How to fix it, step by step
The rule is simple: if the error is for everyone, fix the certificate on the server (name, expiry, chain). If it's only for one user, it's almost always their device (date, outdated system, local network).
- Run the server through an SSL check. It shows at once what's wrong: wrong name, expired, self-signed, or incomplete chain.
- Name/expiry/self-signed — reissue the certificate for the correct name with a trusted CA. How to fix an expired one is in the expired-certificate breakdown.
- Incomplete chain — the trickiest case: it works for some clients and not others. Add the intermediate certificate. More in the incomplete-chain article.
- Only one user — check the date/time and updates on their device; for corporate traffic interception, the trusted root certificate.
How establishing a secure connection and verifying the certificate work in general is in the breakdown of the SSL handshake.
Frequently asked questions
Is my data at risk if the certificate isn't verified?
The traffic is still encrypted and hard to intercept. The danger is different: since the client can't confirm the server's authenticity, a substitution (man-in-the-middle) is theoretically possible. So you shouldn't just permanently "accept" an unverified certificate — find the cause first.
Can I hit "trust anyway" and continue?
For your own test server, once — yes. But for work mail or someone else's server, bypassing the check removes protection against substitution. The right way is to fix the cause (reissue the cert, add the chain), not disable the check.
The error appeared suddenly, though it used to work.
Two common causes: the certificate quietly expired (the most frequent — run an SSL check, look at the date), or the server's cert was changed and the intermediate wasn't added. Less often — the date on the user's device drifted.
Checklist to remember
- The error is about trust in the server's SSL certificate, not a broken connection (and not a game server).
- Causes: name mismatch, expired, self-signed, incomplete chain, wrong date, revocation server unreachable.
- Diagnosis in a minute — an SSL check of the server: name, expiry, issuer, chain.
- For everyone — fix the certificate on the server; for one user — the user's device.
- Don't disable the check permanently — that removes protection against server substitution.