How to check an SSL certificate for a website and mail server
To check an SSL certificate, identify the server hostname and port. A website usually uses 443; email uses different ports depending on the protocol and how TLS starts. Check the name, validity dates and certificate chain, then compare the result with the browser or mail client error. A successful website SSL test does not validate mail on the same domain.
Check your website’s SSL certificate first
- Open the SSL certificate checker. Enter the website hostname, such as example.com, and port 443. If you also use www, check www.example.com separately.
- Compare the hostname with the certificate’s Subject Alternative Names, or SANs. Read the start and expiry dates. A certificate for example.com does not necessarily cover www.example.com; *.example.com covers neither example.com itself nor a.shop.example.com.
- Read the chain and trust results. Note the expiration date and issuer. If a CDN serves the hostname, the result describes the CDN endpoint’s certificate, which may differ from the certificate on your origin server.
The tool makes a fresh connection on every run. It also reports supported TLS versions and HTTPS redirect observations. Save the exact browser error code: it helps distinguish a certificate validation error from a failed TLS connection.
Check a mail server certificate and SMTP TLS
Use the incoming or outgoing hostname configured in the mail client, such as mail.example.com. It may differ from the website address. Match the actual connection hostname and port; different services on one mail server can present different certificates.
| Port | Service | How TLS starts |
|---|---|---|
| 443 | HTTPS website | Immediately on connection |
| 25 | SMTP between mail servers | STARTTLS if the server supports it |
| 587 | SMTP client submission | STARTTLS |
| 143 | IMAP incoming mail | STARTTLS |
| 110 | POP3 incoming mail | STLS |
| 465 | SMTP client submission | Implicit TLS on connection |
| 993 | IMAP incoming mail | Implicit TLS on connection |
| 995 | POP3 incoming mail | Implicit TLS on connection |
STARTTLS begins with the mail protocol and then upgrades the connection to TLS. With implicit TLS, encryption starts immediately. RFC 8314 describes the distinction. Our checker selects the method by port. An address such as mail.example.com:993 overrides the separate port field.
- Check the incoming service using the hostname and port in the mail client. Test outgoing mail separately: its hostname or certificate may differ.
- If the name cannot be resolved or a mail port cannot be reached, review the suggested domain MX hosts. MX records route incoming mail; they do not necessarily identify your client’s outgoing SMTP submission server.
- Compare the SANs, expiry and chain with your website result. If 443 validates but 993 fails, investigate the mail service and its certificate configuration.
Diagnose expired, incomplete-chain and not-trusted errors
A certificate chain links the website or mail certificate to a certificate authority through intermediate certificates. Validation must reach a trusted root. Serving only the leaf certificate can work for some clients while others reject the connection.
| Result | Check | Next step |
|---|---|---|
| Certificate expired | Validity dates and the device clock | Renew or reissue, then install the certificate on the affected service. |
| Hostname mismatch | Connection hostname and SANs | Use the intended hostname or a certificate covering it. |
| Certificate chain incomplete | Server’s intermediate certificates | Install the chain following the CA’s instructions for your server. |
| Self-signed certificate | The certificate issuer | Use a suitable publicly trusted certificate for a public service. |
| Certificate not trusted | Private CA and the client trust store | Check the trust policy; do not substitute disabled verification for a fix. |
ERR_SSL_PROTOCOL_ERROR does not identify one cause: protocol settings, server configuration or network interference can break the TLS handshake. Cloudflare’s explanation covers this distinction. Confirm the hostname, port and TLS mode before reading server logs. A successful remote test does not rule out a problem confined to your device or network.
Use OpenSSL to check the certificate from Linux
For administrator-level output, run these commands in a Linux shell with current OpenSSL and a configured CA trust store. Replace the example hostnames with your own. The first command tests HTTPS; the second tests SMTP STARTTLS on port 587.
openssl s_client -connect example.com:443 -servername example.com \
-verify_hostname example.com -verify_return_error -showcerts </dev/null
openssl s_client -connect mail.example.com:587 -starttls smtp \
-servername mail.example.com -verify_hostname mail.example.com \
-verify_return_error -showcerts </dev/null
The -servername option sends SNI, -verify_hostname checks the hostname and -verify_return_error stops on verification errors. By itself, -showcerts only prints the certificates sent by the server; it does not prove the chain is valid. See the OpenSSL option reference.
Retest the service after installing a fix
Repeat the test for every affected hostname and port, then connect with the browser or mail client. If the old certificate remains visible, check which service terminates TLS and whether it has reloaded the files. A single successful connection cannot confirm identical configuration across multiple external endpoints.
If you need a replacement certificate, list the website and mail hostnames first, then compare the options on the SSL certificates page. Ordering a certificate does not install it on every service and port.