When you hear the phrase “digital certificate expired,” you probably immediately assume something terrible happened, your security has in some way been impaired, and you need to take action. Fortunately and unfortunately, that’s not what happened yesterday. Rather, Apple failed to renew a critical digital certificate related to the Mac App Store, and some apps couldn’t be launched or failed as a result of OS X being unable to validate them.
Digital certificates combine cryptographic information with metadata that can include explicit details, such as the date on which it becomes valid and the date after which it should no longer be accepted. The certificate takes the plainly readable text, including expiration date, and encrypts it in such a way that only a party that possesses the private half of a public-private encryption key pair—a fundamental component of many kinds of Internet validation and session security protocols—could have done so.
In this case, this allows OS X to be sure that the software running is a version downloaded from the Mac App Store, instead of something else. With an expired certificate, the software can’t determine that. Instead, it reports the app has been damaged and suggests a user delete and re-download it—which wouldn’t solve the problem.
This is embarrassing, because Apple should have a master tracker and multiple people responsible for ensuring the renewal of all their digital certificates, domain names, and the like—critical pieces of integrity, security, and navigational infrastructure that are directly tied in with the trust of an organization.
Roots of trust
I’ve written many times in this column about how trust on the Internet typically descends from a root of trust. While many aspects of the Internet are decentralized and lack central control, others are deeply hierarchical, although there’s no top-down enforcement to choose one or another.
Take DNS (domain naming system), the protocol that’s used to turn human-readable domain names into Internet Protocol (IP) addresses that are used by system software to direct traffic to the right destination. DNS is decentralized, in that no central authority registers all domain name to IP address mappings. Instead, there’s a hierarchy from the root (literally . or a dot) through top-level domains (.com, .nz, .aero) to second-level domains (macworld.com, co.uk, and the like) and so on. At each level, delegation takes place.
But DNS has central points of failure: all Internet-enabled devices point to the root to figure out how to descend delegations and find the right domain-to-IP conversion. The root is a number of machines distributed around the world. It’s possible—and was tried years ago—to establish alternative DNS roots and domain-naming systems, but those almost entirely failed to take hold because the current domain systems works just well enough.
It’s not secure, however. While efforts have been made over many years to build cryptographic elements into DNS, and some progress has been made, there’s no way to be sure on any given local area network that a legitimate domain lookup has occurred. (This is called DNS poisoning when such hacks occur.)
Digital certificates, on the other hand, rely on an extensive cross-checks using certificate authorities (CAs), information about which is built into operating systems and separately into some browsers, like Mozilla’s Firefox. CAs counter-sign digital certificates, which allows any device receiving a certificate to validate that the plain-text portion hasn’t been tampered with.
When a certificate fails—whether through an accidental expiration or due to tampering—it’s a reasonable precaution for software to act as if the sky is falling, because there’s no good reason it should fail unless an attack or compromise is underway.
I bring up DNS above, because one of the most common attacks to hijack secure traffic involves suborning a certificate authority (something that has happened with too much frequency) and then poisoning DNS, sometimes at a national level, as in Iran. This lets a fraudulent, but legitimately verifiable certificate be assigned with an illegitimate DNS lookup. It redirects a user’s device securely—to the wrong place.
When the unthinkable happens
But you can approach this from a variety of angles. Apple wasn’t prepared for a certificate failure of this kind, building OS X to assume the software was at fault, rather than Apple. And, to be fair this is a sort of epochal event: It should happen never, or failing that, so rarely as to be implausible.
And yet because Apple’s infrastructure is seemingly so brittle, not only did it happen, it inconvenienced an unknown number of Mac App Store software purchasers, while offloading the frustration and customer-service load to developers.
Apple has reissued its Mac App Store certificate with an expiration date of 2035. But this isn’t a good idea, either. Short-term expirations of a year or two prevent future unexpected and unintended exploitation of integrity guarantees present in digital certificates. Even though Apple controls the use of this certificate, it implies a lack of trust in its ability to remember as a corporate entity to renew it again.
Having caused hundreds of thousands to millions of dollars in lost productivity and staff time to users and developers alike, this might cause more developers to rethink their relationship with the Mac App Store. Its primary advantage is access to iCloud as a means of syncing or storing data, like preferences, instead of requiring the use of Dropbox or developers building their own sync systems.
Some developers discontinued MAS versions an OS X release or two or three ago. This may cause some to reconsider the App Store advantage once again.
Author: Glenn Fleishman, Senior Contributor
Glenn Fleishman’s most recent books include Take Control of iOS and iPadOS Privacy and Security, Take Control of Calendar and Reminders, and Take Control of Securing Your Mac. In his spare time, he writes about printing and type history. He’s a senior contributor to Macworld, where he writes Mac 911.