Due to a recently discovered bug in Apple's code, your browser is exposed to MITM attacks. Click here for more information.
Assessment failed: Unable to connect to the server
Known Problems
There are some errors that we cannot fix properly in the current version. They will
be addressed in the next generation version, which is currently being developed.
No secure protocols supported - if you get this message, but you know that
the site supports SSL, wait until the cache expires on its own, then try again, making
sure the hostname you enter uses the "www" prefix (e.g., "www.ssllabs.com", not just
"ssllabs.com").
no more data allowed for version 1 certificate - the certificate is invalid; it is declared as version 1,
but uses extensions, which were introduced in version 3. Browsers might ignore this problem, but our parser is strict
and refuses to proceed. We'll try to find a different parser to avoid this problem.
Failed to obtain certificate and Internal Error - errors of this type will often be reported
for servers that use connection rate limits or block connections in response to unusual traffic. Problems of
this type are very difficult to diagnose. If you have access to the server being tested, before
reporting a problem to us, please check that there is no rate limiting or IDS in place.
NetScaler issues - some NetScaler versions appear to reject SSL handshakes
that do not include certain suites or handshakes that use a few suites. If the test is failing
and there is a NetScaler load balancer in place, that's most likely the reason.
Unexpected failure - our tests are designed to fail when unusual results are observed.
This usually happens when there are multiple TLS servers behind the same IP address. In such
cases we can't provide accurate results, which is why we fail.
Common Error Messages
Connect timed out - server did not respond to our connection request, sometimes
before we are dynamically blocked when our tests are detected
No route to host - unable to reach the server
Unable to connect to server - failed to connect to the server, it usually happens due to firewall restrictions
Connection reset - we got disconnected from the server
Unrecognized SSL message, plaintext connection? - the server responded with plain-text HTTP on HTTPS port
Received fatal alert: handshake_failure - this is either a faulty SSL server or some other server listening on port 443;
if the SSL version of the web site works in your browser, please report this issue to us
Failed to communicate with the secure server - No secure protocol supported. Possibly this server only supports a draft version of TLS 1.3
AAA Certificate Services
Self-signed
Fingerprint SHA256: d7a7a0fb5d7e2731d771e9484ebcdef71d5f0c3e0a2948782bc83ee0ea699ef4
Pin SHA256: vRU+17BDT2iGsXvOi76E7TQMcTLXAqj0+jGPdW7L1vM=
RSA 2048 bits
(e 65537) /
SHA1withRSA
Weak or insecure signature, but no impact on root certificate
Click here to expand
Why is my certificate not trusted?
There are many reasons why a certificate may not be trusted. The
exact problem is indicated on the report card in bright red.
The problems fall into three categories:
Invalid certificate
Invalid configuration
Unknown Certificate Authority
1. Invalid certificate
A certificate is invalid if:
It is used before its activation date
It is used after its expiry date
Certificate hostnames don't match the site hostname
It has been revoked
It has insecure signature
It has been blacklisted
2. Invalid configuration
In some cases, the certificate chain does not
contain all the necessary certificates to connect the web
server certificate to one of the root certificates in our trust store.
Less commonly, one of the certificates in the chain (other than the
web server certificate) will have expired, and that invalidates the
entire chain.
3. Unknown Certificate Authority
In order for trust to be established, we must have the root certificate
of the signing Certificate Authority in our trust store. SSL Labs does not
maintain its own trust store; instead we use the store maintained by Mozilla.
If we mark a web site as not trusted, that means that the average web user's
browser will not trust it either. For certain special groups of users, such
web sites can still be secure. For example, if you can securely verify that
a self-signed web site is operated by a person you trust, then you can trust
that self-signed web site too. Or, if you work for an organisation that manages
its own trust, and you have their own root certificate already embedded in
your browser. Such special cases do not work for the general public, however,
and this is what we indicate on our report card.
4. Interoperability issues
In some rare cases trust cannot be established because of interoperability
issues between our code and the code or configuration running on the server.
We manually review such cases, but if you encounter such an issue please feel
free to contact us. Such problems are very difficult to troubleshoot and you
may be able to provide us with information that might help us determine the
root cause.
Certification Paths