You must be joking. Not all developers have the resources to anticipate a change like this.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Expiring Developer Certificates Causing Some Mac Apps to Refuse to Launch
- Thread starter MacRumors
- Start date
- Sort by reaction score
You must be joking. Not all developers have the resources to anticipate a change like this.
why should a certificate for a software you already have installed and did all the checks at that time expire?
Why? No software, in the history of ever, has ever had an "implode by" date. If Apple intends to start creating an "Implode by" date, they should make it explicitly clear to the end user.
This is something the system is doing, not something the apps are doing. In fact, it'd be better to not have a certificate at all than to have this behavior.
Can you just open them with a right-click to open, ignoring the cert? Or do they always stop working?
Can you just open them with a right-click to open, ignoring the cert? Or do they always stop working?
Thank you for this article. I read this before I realized I had a problem and was able to fix the issue with 1Password. This saved me a lot of troubleshooting.
A number of Mac apps failed to launch for users over the weekend because of a change to the way Apple certifies apps that have not been bought directly from the Mac App Store.
Several users of apps including Soulver and PDFPen who had downloaded the apps from the developers' websites all reported immediate crashes on launch. Developers of the apps quickly apologized and said that the issue was down to the apps' code signing certificates reaching their expiration date.
Apple issues developer signing certificates to assure users that an app they have downloaded outside of the Mac App Store is legitimate, comes from a known source, and hasn't been modified since it was last signed. In the past, the expiration of a code signing certificate had no effect on already shipped software, but that changed last year, when Apple began requiring apps to carry something called a provisioning profile.
A provisioning profile tells macOS that the app has been checked by Apple against an online database and is allowed to perform certain system actions or "entitlements". However, the profile is also signed using the developer's code signing certificate, and when the certificate expires, the provisioning profile becomes invalid.
Victims of expired provisioning profiles over the weekend included users of 1Password for Mac who had bought the app from the developer's website. AgileBits explained on Sunday that affected users would need to manually update to the latest version (6.5.5), noting that those who downloaded 1Password from the Mac App Store were unaffected. The developers' surprise was explained in a blog post:
Currently, the common factor among affected apps appears to be those that were issued iCloud entitlements as part of their provisioning profile. Smile, developers of PDFpen and PDFpenPro, told TidBITS that users would need to manually download the latest updates to the apps to fix the problem.
Acqualia, developers of number-crunching app Soulver, also apologized for the problem and asked affected users to download an update to fix the issue.
As the above suggests, the immediate solution for developers with potentially affected apps is to renew their code signing certificates before they expire. AgileBits said the incident had given them "a new understanding of the importance of expiring provisioning profiles and certificates" and would be renewing its current certificate, due to expire in 2022, "far before then".
Article Link: Expiring Developer Certificates Causing Some Mac Apps to Refuse to Launch
Well, not really. (by the way, I have fixed your spelling error above)
Expired certificate is no longer trusted. Revoked certificate is no longer trusted, although it did not expire yet. In terms of certificate management, both lead to the same status: cert is not trusted. Hence the described issue.
I do agree Apple failed to clarify what exactly happens after certificate is no longer trusted. However, Agilebits failed to verify their applications, "assuming" in their own words it would still work.
I guess nobody in Algebits uses 1Password. Otherwise they would see the issue even before support call started mounting
[doublepost=1487608451][/doublepost]
All certificates come with an expiration date. If expired, certificates are no longer valid. If you verify the validity of a certificate before starting an app and not only before installing or on the first start, you will have to change signed certificates from time to time.
If the app is alive in APS, the system will push you an update timely. For third party apps from trusted developers, those developers have to take care of that manually.
Now, here is the twist. Agilebits pushes updates. Although new version of a program is installed, the signing certificate remains the same. To change that, you have to reinstall app completely. That is the workaround for 1Password 6.5.5. Agilebits did know their developer certificate is about to expire. They did not care to check what happens to the app after expiration date passes. This is a tiny QA issue that scared a lot of people around. They have figured out a fix quickly, kudos for that. But with some forward thinking, they could avoid "fire in the office" and scared customers.
Now, let's blame Apple for that, because it is fun
No, the cert is different in that it has a specified expiration date. If Apple keeps doing this, that is a guaranteed date when the app will stop working. In other cases, it's a "may" stop working situation--e.g., an OS update might break backward compatibility with an older app, but in may cases it won't.
If you buy piece of software, there's no reason that you shouldn't except it to continue to work more or less indefinitely if you keep your system the same, e.g., by not upgrading your OS to a newer version on which the app is not supported.
If Apple decides this is the correct behavior, it would be nice to be able to re-sign such apps (or any) yourself. I assume that is possible--and not within the reach of the average user, but it's mostly going to be power users trying this anyway. That would enable them to keep running for as long as you decide you trust them (or they break for other reasons, but that's always been a possibility on the Mac--or anywhere, but Apple certainly isn't known for bending over backwards like Microsoft about this).
There is usually a fee, though I'm not sure if Apple includes it for "free" as part of paid developer memberships. In most cases, the fee goes to the certificate authority (though in this case it's usually just Apple) who will use the fee to cover the costs associated with issuing and maintaining such certificates.
Listing apps in the App Store is not free, and many small or independent developers cannot afford it (or at least have decided the cost isn't worth it). Additionally, some "power user" apps are not allowed in the App Store, at least in their full form (e.g., TextWrangler), due to some features that need to exist outside more limited set of things Apple lets you do. (Xcode would be one of these, but Apple lets themselves cheat a little in that the original Xcode download seems to be a bit of a glorified stub that takes are of installing what it really needs later.)
Windows malware, by the way, comes from a variety of sources, many of which are "drive-by downloads," some of which install only as the current user (thus bypassing UAC) or exploit security vulnerabilities to elevate access--and, yes, some are things that appear to be legitimate software that the user knowingly installs but shouldn't. But almost nobody gets apps from Microsoft's store on the Windows side.
Last edited:
I know this. My complain is the obligatory need to have an expiration date for something that is already checked and approved at the original time.Well, not really. (by the way, I have fixed your spelling error above)
Expired certificate is no longer trusted. Revoked certificate is no longer trusted, although it did not expire yet. In terms of certificate management, both lead to the same status: cert is not trusted. Hence the described issue.
I do agree Apple failed to clarify what exactly happens after certificate is no longer trusted. However, Agilebits failed to verify their applications, "assuming" in their own words it would still work.
I guess nobody in Algebits uses 1Password. Otherwise they would see the issue even before support call started mounting
[doublepost=1487608451][/doublepost]
All certificates come with an expiration date. If expired, certificates are no longer valid. If you verify the validity of a certificate before starting an app and not only before installing or on the first start, you will have to change signed certificates from time to time.
If the app is alive in APS, the system will push you an update timely. For third party apps from trusted developers, those developers have to take care of that manually.
Now, here is the twist. Agilebits pushes updates. Although new version of a program is installed, the signing certificate remains the same. To change that, you have to reinstall app completely. That is the workaround for 1Password 6.5.5. Agilebits did know their developer certificate is about to expire. They did not care to check what happens to the app after expiration date passes. This is a tiny QA issue that scared a lot of people around. They have figured out a fix quickly, kudos for that. But with some forward thinking, they could avoid "fire in the office" and scared customers.
Now, let's blame Apple for that, because it is fun
That's got to be the saddest reply I've seen this year. Go blame the developers for Apple's BULLCRAP NONSENSE.
Software you have already installed and was already validated should NEVER STOP WORKING. PERIOD. There is NO EXCUSE for what Apple did as this will invalidate any software that authors stop updating.
What happens if an author dies or stops developing Mac software? Your older software should just stop working? What a load of crap and even more so for someone defending Apple.
Very good point. Just the other day, I needed a timer. Turns out I had downloaded a free utility that works as a timer and stopwatch. It was a few years old, but ran perfectly under Sierra. I looked to see if there was a new version, and the developer wasn't even around. Fine. It was free. But if there had been an expiring code signing, the app would no longer have worked.
Apple's security is getting out of control. Apple should not invalidate a program that runs perfectly because the developer no longer supports it!
Well, not really. (by the way, I have fixed your spelling error above)
Expired certificate is no longer trusted. Revoked certificate is no longer trusted, although it did not expire yet. In terms of certificate management, both lead to the same status: cert is not trusted. Hence the described issue.
I do agree Apple failed to clarify what exactly happens after certificate is no longer trusted. However, Agilebits failed to verify their applications, "assuming" in their own words it would still work.
I guess nobody in Algebits uses 1Password. Otherwise they would see the issue even before support call started mounting
[doublepost=1487608451][/doublepost]
All certificates come with an expiration date. If expired, certificates are no longer valid. If you verify the validity of a certificate before starting an app and not only before installing or on the first start, you will have to change signed certificates from time to time.
If the app is alive in APS, the system will push you an update timely. For third party apps from trusted developers, those developers have to take care of that manually.
Now, here is the twist. Agilebits pushes updates. Although new version of a program is installed, the signing certificate remains the same. To change that, you have to reinstall app completely. That is the workaround for 1Password 6.5.5. Agilebits did know their developer certificate is about to expire. They did not care to check what happens to the app after expiration date passes. This is a tiny QA issue that scared a lot of people around. They have figured out a fix quickly, kudos for that. But with some forward thinking, they could avoid "fire in the office" and scared customers.
Now, let's blame Apple for that, because it is fun
Believe me, revocation and expiration are completely different in the context of Apple app-signing. The current behavior is a bug that Apple will probably fix with the next macOS update. If you need more information, please read the Apple codesigning documentation.
Apps that have previously been signed using a now expired certificate should definitely still work and also continue to work fine forever. The date is only relevant at the time the developer signs the app before he releases it. Due to a bug in combination with entitlements this currently doesn't work correctly.
For example the latest version of my app (BetterTouchTool) is signed with a Developer ID certificate that has now expired. However the app continues to work fine because it is not affected by the entitlements bug. Only that specific combination of entitlements and expired certificates triggers this bug.
You can blame whomever you want, but developers could not know this as Apple's documentation clearly promises different behavior.
Last edited:
Completely different. Expired certificate was trusted. It was used to verify the app, therefore the app can be trusted. Expiration doesn't matter: The app was verified with a trusted certificate, so it can be trusted, 100 years after expiration of the certificate.
A revoked certificate has just been found out to be untrustworthy. It should never have been trusted in the first place. The app was verified with a certificate that should never have been trusted, therefore the app cannot be trusted.
It's like the difference between a child minder who let his certification slip, and a child minder who you just found is a multiple child killer. You don't trust either, but there is just that tiny little difference... And of course if you had been using a child minder for a year and his certification runs out, it's still the same person so you can trust them just as much as the day before.
Last edited:
Lol no that's not how this works
[doublepost=1487615862][/doublepost]
Actually that's how certificates work. The entirety of secure HTTP works like this.
Disclaimer: I work for AgileBits, makers of 1Password.
Hey all,
For anyone who is having trouble here please let me know.
For anyone who had trouble but isn't anymore, I'm really sorry. We really had no intention of putting our users through this trouble.
We are currently helping any users who are still encountering trouble today and then the rest of the week will be investigating what happened. Then working on a blog post that will discuss what happened, why it happened and what we'll be doing in the future to prevent it from happening again.
Needless to say, things did not work how we had anticipated them working. This is something we hope to address in a technical post mortem that discusses the details. I wish I could give you more details but it would be based on assumptions that are probably wrong at this point.
That said, if anyone has questions, I'd be happy to answer them if I know the definitive answer to it. If I don't know the answer I'll have to have you wait until we've posted the blog post with more details.
Again, I'm really sorry to all 1Password users who were impacted.
Hey all,
For anyone who is having trouble here please let me know.
For anyone who had trouble but isn't anymore, I'm really sorry. We really had no intention of putting our users through this trouble.
We are currently helping any users who are still encountering trouble today and then the rest of the week will be investigating what happened. Then working on a blog post that will discuss what happened, why it happened and what we'll be doing in the future to prevent it from happening again.
Needless to say, things did not work how we had anticipated them working. This is something we hope to address in a technical post mortem that discusses the details. I wish I could give you more details but it would be based on assumptions that are probably wrong at this point.
That said, if anyone has questions, I'd be happy to answer them if I know the definitive answer to it. If I don't know the answer I'll have to have you wait until we've posted the blog post with more details.
Again, I'm really sorry to all 1Password users who were impacted.
The applications are signed for identity purposes, not authorization purposes. Apple's mechanism isn't granular enough to disambiguate the two, which is a bug IMO.
If your identity was valid in the past and your identity expired, that does not mean that the app associated with that identity should be invalid if it had passed the validity check previously.
In the TLS world it may be different: what happens if you have a TLS connection active and the certificate behind it expires? I'm not sure, and I doubt anyone knows for sure.
I'm afraid this is yet another example of Apple's new management policy: The left hand has no idea what the right hand is doing.
Apple's code signing policies are archaic, poorly thought out, poorly implemented, poorly documented, and now poorly functioning. This is a bug, unless Apple's new policy is "Let's change stuff and not tell anyone about it," which is another procedure they seem to be following.
As an FYI, a developer can revoke their own cert and issue a new but different one if they change the system they're using to develop the software on. For example, if someone was using a 2010 iMac and they got a new one, they could easily install Xcode on the new system and have it generate certs for that system. In doing so, the previous certs are automatically revoked. Does anyone see a problem here? According to Apple's very own documentation, anything developed on the old system and installed while the original cert was valid should still work because it was valid at its time of installation. Adopting the new The left hand has no idea what the right hand is doing school of thought that Apple has embraced, now the once functioning application will become dysfunctional, thus making the developer look incompetent, crooked, suspicious (WHY was that certificate revoked?), or stupid. And what is the developer guilty of? Upgrading their system and not bothering to go through the certificate migration process, perhaps? Being dumb enough to think that Apple's own rules actually have merit?
This will encourage the following:
Apple's code signing policies are archaic, poorly thought out, poorly implemented, poorly documented, and now poorly functioning. This is a bug, unless Apple's new policy is "Let's change stuff and not tell anyone about it," which is another procedure they seem to be following.
As an FYI, a developer can revoke their own cert and issue a new but different one if they change the system they're using to develop the software on. For example, if someone was using a 2010 iMac and they got a new one, they could easily install Xcode on the new system and have it generate certs for that system. In doing so, the previous certs are automatically revoked. Does anyone see a problem here? According to Apple's very own documentation, anything developed on the old system and installed while the original cert was valid should still work because it was valid at its time of installation. Adopting the new The left hand has no idea what the right hand is doing school of thought that Apple has embraced, now the once functioning application will become dysfunctional, thus making the developer look incompetent, crooked, suspicious (WHY was that certificate revoked?), or stupid. And what is the developer guilty of? Upgrading their system and not bothering to go through the certificate migration process, perhaps? Being dumb enough to think that Apple's own rules actually have merit?
This will encourage the following:
- Developers will stop signing code because it's seen as buggy and a nuisance.
- Some companies, particularly those with a big Windows development base and a small Mac base will use it as yet another an excuse to finally kill off the less popular Mac versions of products (and Apple keeps providing them with more ammunition).
- Some companies will drop Mac support because they don't want to be seen as "buggy" or "un-certifiable" because of this.
This should never be allowed to happen.
Doesn't Apple have some kind of certificate notification escalation system to remind developers, then their managers, well in advance of expiration?
I understand that the developers should take responsibility for their products but when functionality or the experience suffers, then Apple needs to investigate remedies based on lessons learned from things like this.
Doesn't Apple have some kind of certificate notification escalation system to remind developers, then their managers, well in advance of expiration?
I understand that the developers should take responsibility for their products but when functionality or the experience suffers, then Apple needs to investigate remedies based on lessons learned from things like this.
That's no longer true, though it was once true back in the early days of crypto. These days, there's a fundamental difference between revocation and expiration when you're dealing with offline content:
- A revoked certificate is treated as untrusted, period, regardless of when content was signed.
- An expired certificate is trusted for data that was signed after the expiration date.
To support the ability to validate signed content after the expiration date (which is necessary for many reasons, not just app validation), Apple and others use timestamp servers, which essentially add an additional digital signature to prove (as long as you trust the timestamp server) that the content in question was signed prior to the certificate's expiration date. Any content signed using a certificate prior to its expiration is therefore supposed to be trusted after the expiration date.
https://en.wikipedia.org/wiki/Trusted_timestamping
What's happening here is one of two things:
- Apple broke something in El Capitan such that the timestamp isn't respected.
- The developer disabled timestamp support when running codesign.
Apple explicitly said what would happen after the certificate expires. Content signed prior to the expiration date is still trusted. That isn't happening. This is a bug. Period.
What a ridiculous thing to say. So if a developer dies my program should stop working??? Yes, it's their fault they're dead. (FACE PALM!) I have to admit it's an evil but simple way for the competition to get rid of a competitor's pesky competing program. Hey Vinnie, make it look like an accident and we won't even have to buy out the competition. Apple will delete it for us!
See above about death scenario or out of business. You're making assumptions about what a developer knew. He could have been on vacation for all you know or some other internal snafu. Should that punish the USER for something he/she's paid for and already had validated? There is NO EXCUSE for Apple causing already installed validated software to FAIL.
If you're going to blame developers for an expiring certificate anyway without knowing the circumstances then explain Apple's own expiring certificates last year that invalidated countless App Store programs. What a crock.
You got that right. It will be the end of OS X (oops I mean macOS) as we know it. Someone accused me of overreacting, but holy cow Batman, Apple is slowly turning OS X into iOS and denying while they do it.It will essentially be an iPhone in a box. You will not be allowed to run any software Apple doesn't approve of and hasn't paid its 30% Apple Tax or developer fees. The days of a user making his/her own choices and getting 3rd party free software will be over.
Time to move to Linux, I suppose. I'm not crazy about it, but I don't like Corporate Overlords telling me what I can and cannot run on my computer. We're sorry, but Huniepop is embarrassing for Apple Corporation (except in Japan). You are not allowed to run it anymore. We're considering revoking Steam's developer certificate in general as they act as their own gatekeeper and aren't paying us 30% royalties for just existing!
(Frack Windows 10 too, the freaking spyware that it is! Read the agreement. Everything you do is reported to the NSA/FBI/CIA on the company's whim. Look! He's playing an old abandoned C64 game on an emulator and encoding his own purchased Blurays to a convenient hard drive format which isn't technically allowed under the DMCA! He must pay for another digital copy not watch one he's already paid for! "Fair use" court rulings only apply to ANALOG video, according to the corporate masters even though video is video and a movie is a movie.)
Why throw logic into an argument full of angry fanatical arguments? Apple is never wrong, after all.
OMG.... I don't know whether to laugh or laugh harder at whom should be embarrassed.
That's got to be the saddest reply I've seen this year. Go blame the developers for Apple's BULLCRAP NONSENSE.
Software you have already installed and was already validated should NEVER STOP WORKING. PERIOD. There is NO EXCUSE for what Apple did as this will invalidate any software that authors stop updating.
This is nothing but a move to "Planned Obsolescence" for Apps. This is slippery slope that started with Mavericks. That's when all my Pro Apps refused to work and required to be updated to the latest version at over $1000 in cost.
Sadly, I fear this is the future. Apple will tell you when you can or have to stop using an app you purchased whether you like it or not.
Two words: Adobe Flash.
Still live in pre-internet era ? Just look at the Transmission 2.92 incident, the much beloved pirating software, being hijacked by OS x/Keydnap malware. And look at the iOS/WireLurker incident, the first widely spread iOS malware, spreading across devices by abusing Enterprise Provision Certificate.
If you haven't noticed that: people don't buy software installer on a disc anymore. Nowadays it has been an obligation for software developers to keep updating their software to prevent their customers from the threat of cyber-attacks. System wide certificate system is certainly not an welcomed method but there is no better alternatives, if you need to stop unidentified software being installed, and force invalidating already installed malicious software on all infected computers at once.
Not everybody is capable to calculate MD5 file hash. And not every software developer is so responsive to implement some kind of auto-patching mechanism and update their software on time. Remember that two words in the beginning of this post ?