The browser will not accept your site’s certificate
What it is
The server answers on port 443, but the certificate it handed us is one a browser would not accept. We checked it the way a browser does, from the outside. We tested nothing else on your site.
Based on what we saw, it is one of these cases:
- Self-signed: the server issued the certificate to itself and no trusted party signed it.
- Name mismatch: the certificate was issued for a different domain than the one the site runs on (typically the host’s default certificate).
- Untrusted chain: an intermediate certificate is missing, or an unknown or private authority signed the certificate.
- Not yet valid: the start of validity (
notBefore) is in the future. - Weak key: an RSA key shorter than 2048 bits, or a SHA-1 or MD5 signature.
Why it’s a problem
In most cases visitors see a full-page warning and most of them close the tab, as with an expired certificate. A missing intermediate certificate is the milder case: many browsers fetch it on their own, but other clients fail (see below).
- API clients, payment gateways and mobile apps refuse the connection.
- Search engines treat the site as untrustworthy.
- Getting used to clicking “proceed anyway” is exactly what helps an attacker on the path to slip in their own certificate.
How to fix it
First, see what the server sends
openssl s_client -connect example.cz:443 -servername example.cz </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates -ext subjectAltNameThe output shows the issuer, the validity dates and the names in subjectAltName. That tells you which case you have.
Self-signed, unknown authority, wrong name, weak key
A new certificate from a public authority fixes all of them. Make sure it covers the bare domain and the www variant. Let’s Encrypt is free and issues modern keys:
sudo certbot --nginx -d example.cz -d www.example.czMissing intermediate certificate
The server has to send the whole chain, not just its own certificate. Many desktop browsers hide the gap by fetching the missing certificate themselves (via AIA), so the site may look fine to you. Some clients, such as API clients, scripts, payment gateways and older Android versions, do not do that and refuse the connection. On nginx use fullchain.pem, not cert.pem:
ssl_certificate /etc/letsencrypt/live/example.cz/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.cz/privkey.pem;On Apache put fullchain.pem into SSLCertificateFile.
Not yet valid
Most often the clock on the machine that issued the certificate was wrong. Check date and time sync (NTP), then issue the certificate again.
Shared hosting
Look for the SSL or HTTPS section in the control panel and add a certificate for your domain. If the host’s default certificate stays in place, contact support.