3

Why does Chrome trust the certificate authority for this site, but not for this one?

This is the same machine, same browser, signed by the same authority, and Chrome shows the intermediate chain signed by the same root CA.

You can confirm the host does not serve the intermediate CA chain as is reported by Tim's answer via services like sslshopper and digicert by manually downloading and verifying it with openssl

openssl s_client -showcerts -connect www.jessclark.com:443

However the full chain does clearly appear in Chrome details when examining the certificate, yet crazily enough it still doesn't trust the authority even though it recognizes it. Because the intermediate chain is missing, then I would expect it to only show www.jessclark.com and not the Let's Encrypt cert linked to DST Root CA X3.

I'm using Google Chrome Version 50.0.2661.102 m on Windows 7

Click the image to view full resolution screenshot.

side-by-side screenshot of error

Interestingly, the authority is trusted in other browsers like Chromium Version 51.0.2704.79 Ubuntu 16.04 (64-bit), Internet Exploder 11 Windows 7, and reportedly by others as well in the comments. Firefox does seem to strictly reject it the most.

Community
  • 1
Jeff Puckett
  • 229
  • 5
  • 15
  • The certs are fine for me - Chrome Version 52.0.2743.116 m windows 10. – user9517 Aug 26 '16 at 17:48
  • @lain interesting - could you check a couple other browsers? I've updated my question with results from firefox, chromium, and internet exploder. – Jeff Puckett Aug 26 '16 at 18:30
  • What is your relationship with these sites ? – user9517 Aug 26 '16 at 19:50
  • @lain, unexpected question, but honestly - none. I have no access to either server, but I'm mostly concerned with the specific client-side trust issues. – Jeff Puckett Aug 26 '16 at 20:02
  • 1
    Compare https://www.ssllabs.com/ssltest/analyze.html?d=www.jessclark.com&hideResults=on with https://www.ssllabs.com/ssltest/analyze.html?d=www.brownlawoffice.us&hideResults=on&latest and you'll quickly see that one is set up to serve the intermediate certificate (proper configuration) while the other one is not. You'll also see that there are also several other configuration issues. – Håkan Lindqvist Aug 26 '16 at 21:08
  • I just wanted to know so I could vote to close. Idle curiosity doesn't fit well with SF. – user9517 Aug 27 '16 at 05:36
  • @lain I reread the help center guidelines in consideration of your comment, but I still feel this question is on topic. Idle curiosity is not representative of my intentions, so to go deeper into detail for my relationship fyi, jessclark is a friend of mine that I would like to help. I've used let's encrypt before, but I no longer have any valid hosts to compare since I primarily use InCommon and my own CA. The other site I pulled from their forums as an example. – Jeff Puckett Aug 27 '16 at 11:47

1 Answers1

4

Both work fine in Chrome on W10. On Firefox I get the following error "parts of this page are not secure (such as images). For example, this link. Firefox is often fussier about certificates and chains.

Update - the core reason for the error is because there's a missing certificate in the chain. See this page, or this page.

enter image description here

Tim
  • 30,383
  • 6
  • 47
  • 77
  • Thanks for the feedback, it's a helpful comment, but this doesn't answer the question why I'm getting invalid authority errors. Also note I qualified the known insecure resources error to be ignored in my question. I'm only stumped about the authority error. If you have any idea of what more information I can include to reproduce the error for you, then let me know, but I don't have Windows 10. Thanks again! – Jeff Puckett Aug 26 '16 at 19:00
  • @JeffPuckettII But this is the answer! The certificate isn't trusted from the jessclark site because the image is being served via http and not https. – Rob Aug 26 '16 at 20:03
  • @Rob for you, yes, but notice the question is about the certificate *authority* error for me. There are two errors at play here - one for mixed resources which you've answered, but secondly the authority error which is inconsistent across systems and is the topic of interest. I'm sorry I can't fix the insecure resources error to distill the question. I appreciate your attention to the matter, but I'm trying to determine the problem with the certificate authority, not the mixed resources. – Jeff Puckett Aug 26 '16 at 20:30
  • 1
    @JeffPuckettII answer updated - the website is missing a certificate in the chain. Chrome seems to trust more CAs than Firefox, which is why I don't see an error in Chrome but do in Firefox. The solution is for the website owner to add the next certificate in the chain to their SSL configuration. – Tim Aug 26 '16 at 20:58
  • That's so strange because my browser is showing the same intermediate certificate chains are installed for both sites. But, I'm almost certain you are correct because this was actually my initial suspicion. How do I determine the intermediate chains as specified from the client? The links you provided for services digicert and sslshopper both corroborate this, but don't provide the technical detail I'm looking for, because the browser is showing the same chain for both. – Jeff Puckett Aug 27 '16 at 00:31
  • I suspect site #1 includes the intermediate cert and sends it to you, whereas site #2 doesn't. I recall when I set up Let's Encrypt for my server I had to concatenate two files together, my cert plus the intermediate cert, and this is stored in fullchain.pem on my server. Have a look at a tutorial I have in this area if you like, though it doesn't quite answer your question it's interesting background: https://www.photographerstechsupport.com/tutorials/hosting-wordpress-on-aws-tutorial-part-5-free-https-https2-for-wordpress-using-lets-encrypt-aws/#acme – Tim Aug 27 '16 at 00:46