Why is Safari asking for three certificates and once approved will not load the site

Question

Why is Safari asking for three certificates and once approved will not load the site

Hello,

Can someone take a look at https://www.sls.net as when I first tried to go to it today, it asked me about three certificates:

com.apple.idms.appleid.prd.4b747336494d5531363537716548494e6278565349513d3d. The common name certainly doesn't seem to be an apple one:

I few interesting things. I have never been to this site before, but now I have a favicon for it, so it downloaded something. At some point, I clicked "continue" as I thought they were valid, and I was just looking anyway, not login in or doing anything with the company. I end up with a blank page, view source, blank too.

curl sls.net yields an empty result, adding a -v to it will get me the rolling output ( this is port 80 though, so those certs don't matter yet ):

* You can also see the redirect to the SSL site in the curl output below.

curl -v sls.net

* Rebuilt URL to: sls.net/

* Hostname was NOT found in DNS cache

* Trying 206.19.54.185...

* Connected to sls.net (206.19.54.185) port 80 (#0)

> GET / HTTP/1.1

> User-Agent: curl/7.37.1

> Host: sls.net

> Accept: */*

>

* HTTP 1.0, assume close after body

< HTTP/1.0 302 Found

< Location: https://www.sls.net

< Server: BigIP

* HTTP/1.0 connection set to keep alive!

< Connection: Keep-Alive

< Content-Length: 0

<

* Connection #0 to host sls.net left intact

Here is the SSL version:

$curl -v https://sls.net

* Rebuilt URL to: https://sls.net/

* Hostname was NOT found in DNS cache

* Trying 206.19.54.185...

* Connected to sls.net (206.19.54.185) port 443 (#0)

* SSL certificate problem: Invalid certificate chain

* Closing connection 0

curl: (60) SSL certificate problem: Invalid certificate chain

More details here: http://curl.haxx.se/docs/sslcerts.html

Now, if I go load Chrome, and put in sls.net it redirects to the SSL version, no alerts, all is well. iPhone, same, no issues there. This concerns me on a few levels. First, is chrome using a different certificate store than keychain? If so how in the heck do we keep on top of that? We need one place where we can managed and delete the bad ones that sometimes sneak in.

Are these valid certs? They say Apple all over them, but could that be forged? The actual certs name is not a apple.com domain, though to me, it looks like someone is trying to make it look that way, though this could be like a PTR records where they are reversed or it could just be the format they are set in and they need not resolve correctly: com.apple.idms.appleid.prd.4b747336494d5531363537716548494e6278565349513d3d As it is, it is either .prd is the TLD, or .4b747336494d5531363537716548494e6278565349513d3d is the TLD. Or, if it is reversed, then I guess it is ok as is.

If I approve them, I still get a blank page, any idea what gives? I played the repair keychain game and such, no luck. Can someone who knows more about certs take a look at the ones connected to sls.net?

Thank you so much.

MacBook Pro, OS X Yosemite (10.10), Added 8GB memory

Posted on Jul 29, 2015 8:18 PM

Reply

Answer 1

Linc Davis

Level 10

209,547 points

Jul 29, 2015 9:17 PM in response to this-is-my-alias

Some websites require a special client certficate for access. If you don't have that certficate, you'll have to contact the site operator to find out how to get one.

Sometimes the problem is caused by a web server that is configured to request an optional client certificate. Safari treats the request as mandatory. In that case, other browsers such as Firefox and Chrome may be able to connect to the site, because they ignore the request.

The first time you were prompted for a certificate, you may have clicked through a dialog that requested access to the Apple certificate in your keychain that is used to secure the iMessage service. In that case, you may be able to regain access to the site in Safari by doing as follows.

Back up all data.

Launch the Keychain Access application in any of the following ways:

☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)

☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.

☞ Open LaunchPad and start typing the name.

Search the list of keychain items for one with the Name of the site in question and the Kind "identity preference."

Delete the item by selecting it and pressing the delete key. The next time you visit a site that prompts for an optional client certificate, cancel out of the prompt. You may have to do this several times before the server stops asking.

Reply

Answer 2

Jul 30, 2015 12:34 AM in response to Linc Davis

Thanks for the detailed info. I am pretty versed in the working of a OS X and spent my life as a developer and system admin prior to the "Cloud" coming around and splitting the jack of all trades into ops, dev ops, net admin, sys admin, front end, back end, DBA, etc etc. All too confusing for me these days 🙂

Before I posted here I did search out the keychain for any certs that looked out of the ordinary. I found a few expired ones that I knew were safe to delete, and a few that were still valid but have been known to "go rogue" in the past. There was this issue ad well as some others I can't remember.

I also did the usual "cross your fingers and play the Disk Utility game of futilely running repair privileges instead of finding out what actually changed those privileges. So I did the same in Keychain Manager and ran the first aid tools and did some manual poking around, cleaned out some old wifi connections that don't exist or I will never use again as well as those I don't mind recreating. That didn't fix it.

After your post, I started digging deeper as you got me thinking. Thanks! I found nothing with the domain name in it, or portions of the domain name. But I did find three certs that matched the contains string of "appleid.prd". These matched the three I was referring to in my OP.

I then exported each one. I also have local Time Machine backups as well as Arq offsite backups. Then I deleted the three items. Fired up Safari, loaded up the site, and it came up, with an SSL cert enabled no less. I clicked on the lock icon, and it is now using a valid Verisign issued cert. It is chained a few times, but that is normal these days and fine.

Thanks for getting me on the right track. I know it was only that one site, and possibly more but it is a large internet and I probably would not have bumped into those sites for a while. Though I have noticed Safari takes a long time to load a page after I press Return/Enter, sometimes is just sits there like a Javascript submit button on a form that is not working because it has some bad JS code in it that only works on IE 5. That is what it feels like. I disabled all the search ahead features, pre-loading, pre-load top hit, spotlight suggestions, and quick website search. I don't think that will help as I notice it in Safari and Chrome, as well as CLI apps like ping, netstat, dig, nslookup, etc. Basically anything that hits the network seems to have lag to it. I am thinking it is slow DNS lookups. I have had crappy internet with (DUP) packets for the last month, Comcast is coming tomorrow. Second dig lookup on DNS go down from the usual 2000ms to 800ms, and by the third, it seems to have cached the result to a more reasonable 10-15ms. But it is pretty random, making me think it is connection related. I am using google RR's, I will try their secondary as a primary, and then I will try openDNS again. I can actually try that with dig.

$dig reddit.com @208.67.222.222 +norecurse

33ms first try, and I have not been to reddit today. +trace is an acceptable average of 18ms up to around 100ms.

Never been to this site in my life, and not looking too bad:

;; Query time: 11 msec

;; SERVER: 208.67.222.222#53(208.67.222.222)

;; WHEN: Thu Jul 30 00:30:01 2015

;; MSG SIZE rcvd: 43

I think I will change to openDNS for the time being.

Thanks again for your help, it really sped things along as far as troubleshooting this one. I even pulled out wireshark, which I wish I would not have done, because now I have to figure out why I get 10,000 ARP packets in a very short time. I know why they are there and what they are for, but they are coming from the CMTS right at the head, why isn't the router/firewall/modem dropping them? Its not much in total, a few bytes, it does add up to about 900k a month, almost a 1MB waste of very tiny ARP requests that the router should be nicely dropping. I suspect Comcast has really over subscribed this area and I am on one node with a huge subnet of address space allocated to far too many people.

Thank you again.

Reply