I have a server running behind SSL (https://es.content-index.oustatic.com:8443). We got a report from somebody that that SSL cert was bad:

Screenshot from client

However, it seems good on our end. I plugged it into to an ssl checker (https://www.sslshopper.com/ssl-checker.html#hostname=es.content-index.oustatic.com:8443) which shows that the certificate to be good.

Is there some misconfiguration, perhaps, on the client's machine? Why would his machine complain about the cert?

  • I notice that this is in fact a wildcard certificate for *.content-index.oustatic.com. Maybe there are some user-agents that do not like those? Oct 9, 2015 at 13:50
  • I'd be surprised if there was any UA in use today that didn't know what to do with a wildcard sAN. At any rate, the screenshot is clearly Chrome dev tools, and I'm quite confident that's always understood wildcards.
    – womble
    Oct 11, 2015 at 23:30
  • If there's a reason the existing answers don't met your question and none is accepted, please point it out ;)
    – Sebb
    Oct 13, 2015 at 19:15
  • Very good reason...no answer is 100%, they're all a bunch of suggestions, and none of them am I able to follow up with the client. In order to test any of this, I would probably need access to his computer, which is not going to happen. That said, you're answer probably was the most comprehensive, with the most suggestions, so I will probably choose it soon.
    – blockhead
    Oct 14, 2015 at 5:54

4 Answers 4


There's a great many reasons why a client might find a certificate to be unsuitable. Most likely, the client doesn't consider the certificate as chaining to a trust anchor. I'd run the site through Qualys SSLLabs (which is, IMO, by far the most comprehensive and informative SSL test tool) but that site only supports services on port 443, so we're missing some useful diagnostic information there.

At this point, I'd say it's time to ask the client what exactly they've got going on, so you can reproduce the problem with a similar configuration.

  • Interesting! Never thought of this possibility.
    – MEMark
    Oct 9, 2015 at 13:00

Since it looks like the client is a normal web browser I would suggest that the problem is no the browser itself but there is some SSL interception going on. This is very typical for current client side virus scanners (which usually put the necessary proxy CA into the systems CA store) or for some middleboxes like firewalls in corporate environments. Usually in this case other SSL sites will fail too but it might also be that there is some special handling going on because of the non-standard port.

A look at the certificate and chain as delivered to the clients browser will probably help to debug the issue.


Yes, of course! There are a lot of possibilities why a client may not accept an otherwise valid certificate. Here are just a few common ones:

  • Invalid client time. This is the most common cause (i.e. when the BIOS battery is empty), despite it's probably not whats bothering you.
  • Wrong domain name. This is usually caused by subdomains which are not included in the certificate. This is a possible client error if your browser doesn't support SNI, check here. Most modern browsers support this for ages, the exception is the browser of a big software company you surely know ;)
  • Insecure encryption. I don't know about other browsers, but Chrome recently started showing connection which are using https but use a cipher they consider insecure (RC4, SHA1) as insecure. Your client is using chrome, so this is an option. For me it shows the connection as secure, but this may be out of date.

A error due to a weak cipher. Picture by SO user Knelis.

  • Man-in-the-Middle attack. The warning the browser always shows but no one bothers reading anyway. This may a real attacker trying to sniff data or a company proxy trying to spy on what is going on on an exotic port. Also, some AV- and Ad-software messes with your https certificate store.

  • Invalid CA. This is uncommon, but when you have it the causes are hard to track down. This starts with some browsers not accepting specific CA (i.e. CACert is blocked in Firefox). Some browsers do have their own certificate store (Firefox again) while others are dependent on the systems certificate store, which is even worse. Why? Because except for AV-, Ad- and NSA-software messing with your certificate store on all your windows versions, you also have the problem of distribution-specific acceptance variety and company policies installing their own. If a company has an AV proxy, you'll instead need to go for its certificate store. And this may be proxy software specific. If this is your problem, good luck.

It's hard to tell exactly what your clients problem is with so few information, but a client problem is most definetly in.


You have one iframe in the page that has a invalid / or non existing ssl certificate.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .