Tag Archives: OS X keychain

Weekly output: 2015 tech fails, apps versus mobile sites, 2015 in tech policy, CES newbies, OS X Keychain, how to read CES stories

Posted on by
Reply

 

A few stories I’d filed earlier went up this week, lending a false sense of my output. Tomorrow, I depart for my 19th CES in a row, and even after all that experience I’m still not quite sure what I’ve signed up for.

USAT tech-fails column12/30/2015: Tech fails: The year’s worst consumer gadget calamities, USA Today

My editors elected to run the column that appeared online last week in Wednesday’s print edition. Can’t lie; that’s still neat.

12/30/2015: Tip: Does That Site Really Deserve To Be An App On Your Phone?, Yahoo Tech

I’ve had this topic on my story-ideas list for a while, and now it’s finally posted.

12/30/2015; The Year in Technology Policy: It Wasn’t All That Bad!, Yahoo Tech

My latest take on this evergreen end-of-year topic found me in a better mood than usual.

12/31/2015: Tip: How to Cut Old Passwords Out Of Apple’s Keychain, Yahoo Tech

Like my other tip this week, this was something I’d had on my mind for a while.

1/1/2016: CES 2016 Survival Guide: What Newbies Need to Know, Yahoo Tech

You’ve read earlier versions of this how-to here in 2011 and 2013. This time around, I think I did a better job of monetizing my thoughts.

1/3/2016: How to read the hype of CES, USA Today

This weekend’s column takes another break from the usual tech-Q&A format to offer advice about interpreting the impending deluge of CES coverage.

Advertisement

Cert-ifiable: How my Mac didn’t trust a new secure site from the Feds

Posted on by
Reply

For about three minutes on Monday, I thought I’d uncovered a gigantic security flaw in a new government site set up to push other .gov sites towards secure browsing: When I tried visiting The HTTPS-Only Standard, my iMac’s copy of Safari reported that it couldn’t verify that site’s identity and its copy of Chrome said my connection wasn’t private.

https.cio.gov cert errorBut when you think you’ve uncovered an obvious error in a site that’s been out for over a week, it’s usually your own setup at fault. And within minutes of my tweeting about those warnings, I got a reply from the guy who configured the site saying he couldn’t reproduce the problem.

After some quick testing on this computer, my MacBook Air, my iPad and my phone (during which I silently congratulated myself for editing some accusatory sarcasm out of that tweet before posting it), I realized this fault was confined to Safari and Chrome on my two Macs. Every other browser, including Firefox on my iMac, got through to that HTTPS-Only site normally.

Further Twitter conversations pointed me to each Mac’s store of saved site certificates, accessible in the Keychain Access app. For Safari and Chrome to encrypt a connection to that government site, OS X needed to match its digital certificate against a sort of master key, a “root certificate” stored in the system.

old Comodo certificate(For a better description of how the mathematical magic of encrypted browsing happens, consult my friend Glenn Fleishman’s 2011 explainer for the Economist.)

Both Macs had an old copy of Comodo Group’s root certificate, one not listed on Apple’s inventory of trusted root certs. I tried deleting that certificate, figuring it probably wouldn’t make things worse–and that was all it took for the HTTPS-Only site to work as advertised and for one or two other sites to stop coughing up security warnings.

With my encrypted browsing back to normal, I’m left to wonder how my system keychains got tangled up like that. Any theories? Before you ask: Yes, I’ve done a full scan with the ClamXav malware scanner and haven’t found any issues.