1

I have a server containing just media (images). The media server has an SSL certificate purchased from GoDaddy.

If I go to

https://media.mydomain.com/media/SiteImages2/KHeadshot.jpg

it opens a page containing only the JPG image mentioned. I see the "secure" lock in Chrome, Firefox, and Safari on my Mac.

Most other members of our team also see the same thing.

But some team members get a warning page instead. The warning is different for different browsers, but for Firefox it reads, "Your connection is not secure. The owner of media.mydomain.com has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website."

Most of the few users with this problem only see this kind of message in Firefox. One also said they see it in Chrome and Safari. Most get a secure connection with the green "secure" lock with all browsers, like I do.

I talked to GoDaddy support and they patiently tried testing with all the URLs I gave them and to them they were able to get a secure connection each time and they said the site appears to be fine and the SSL certificate appears to be fine.

Their suggestion was to Google around and see if I could find an answer. So I came here.

I am not able to duplicate the problem myself, but the team testing results so far are as follows. I did have them clear their browser caches.

  • Windows user: Chrome and Edge ok, Firefox not
  • Mac user: Chrome, Firefox, Safari all ok
  • Mac user: Chrome and Firefox ok
  • Mac user: Chrome, Firefox, Sari all ok
  • Mac user: Chrome and Safari ok, Firefox not
  • Windows user: Edge ok
  • Mac user: Firefox and Opera ok
  • Mac user: Firefox, Chrome, and Safari all not ok

Any suggestions about what might be the cause for some users in some browsers?

Doug Lerner
  • 165
  • 1
  • 9
  • If you gave us your real URL, we could check your certificate and how it is presented to your visitors – TomTomTom Sep 07 '17 at 05:31
  • OK. I didn't want to swamp the server. But anyway this URL is https://media.edweb.net/media/SiteImages2/KHeadshot.jpg – Doug Lerner Sep 07 '17 at 07:58

1 Answers1

3

Your server seems to be only sending the end-entity (server) certificate. Running:

openssl s_client -connect media.edweb.net:443

returns just the server certificate.

However, that certificate was signed by Starfield Secure Certificate Authority - G2 and that certificate also needs to be sent by your server. You need to talk to the server admin and point them in the direction of RFC 5246 Section 7.4.2. Once they understand their mistake, they then need to reconfigure their web server to send both the server and CA certificate.

Your site works for some clients for two reasons:

  1. Your certificate has the Authority Information Access (AIA) extension which contains the URL of the missing CA certificate. Some clients (notably Microsoft and Chrome for Windows - unsure what does in the Apple world) use that URL to fetch the missing certificate. Others (notably Firefox) don't and will therefore fail to build the certificate chain, thereby showing errors.
  2. Clients cache previously accessed certificates. Some of your users will have come across this missing CA certificate during routine browsing of correctly configured sites. The certificate will therefore be cached and can be used in the chain-building process when visiting your site. On the other hand, browsers which haven't cached it, will show errors.

Therefore, users who use browsers that don't use AIA and don't have the certificate cached will fail.

Users who use browsers that use the AIA extension or have the CA certificate cached will not show any errors.

Community
  • 1
garethTheRed
  • 4,539
  • 14
  • 22
  • Thank you for your detailed explanation. Unfortunately I am the server admin. However, using your explanation I believe I fixed the problem. Would you mind very much testing again. I ran the test before my change and saw the error "verify error:num=20:unable to get local issuer certificate". After my change I am no longer seeing errors and see depth=2, depth=1, and depth=0 "verify return:" messages. So I think I may have fixed it, but wonder what you see. Thank you. – Doug Lerner Sep 08 '17 at 10:51
  • You seem to have fixed it. The proof of the pudding is in the eating though - have your users stopped receiving errors? – garethTheRed Sep 08 '17 at 19:11
  • Yes, thanks very much. I have also confirmed that it is working with the users who were receiving errors. – Doug Lerner Sep 08 '17 at 23:03