App Store apps do not install properly on a fresh install of High Sierra on internal SSD or HDD

Also, please export the public certificates from the app using "codesign -dvvvv --extract-certificates /Applications/AppStore app.app".

Convert the DER-encoded (binary) certificate to PEM using openssl, and post the content here.

I used this command

sudo codesign --depp -fs - /Appications/iMovie.app

successfully for iMovie and Garageband...

for Keynote and Numbers worked:

spctl --assess -v /Applications/keynote.app

But none of them works vor Pages... Strange

@FrancoisQC

I instead ran this command

sudo mv /Library/Keychains/crls/valid.sqlite3 /Library/Keychains/crls/valid-***.sqlite3

and a new 0 byte valid.sqlite3 file was immediately created.

ls -l /Library/Keychains/crls/

shows

-rw-r--r-- 1 root wheel 17293312 Nov 24 20:17 valid-***.sqlite3

-rw-r--r-- 1 root wheel 0 Nov 26 07:58 valid.sqlite3

Now we'll see what happens tomorrow morning.

EDIT

lol

The forum won't post the three letters which are doubleyou Tee Eff

FrancoisQC wrote:

I don't want to block OCSP requests by modifying /etc/hosts, this is a bad security practice and does not address the real issue.

Have you tried doing that and disabling SIP like I suggested? It maybe a "bad security practice" but a good practical measure, at least for now. If that proves to be a temporary workaround that works until Apple fixes the issue then what's the grief of having your apps up and running? If it doesn't that's understandable.

Also, modifying hosts by blocking OCSP is not going to do any harm. This protocol is used by the "trustd" process which makes queries every time you open Mac App Store. You may experience issues with MAS connectivity at best but it's not going to compromise your computer and invite hackers to steel your bank account info immediately after you modify hosts and disable SIP.

And here is a bit more.

• The SN of "Apple Mac OS Application Signing" is present in version 42
• The SN of "Apple Mac OS Application Signing" is not present in version 137
• The SN of "Apple Mac OS Application Signing" is present in version 145 and 146 upgraded from version 42, with respective issuer flag of 0 and 16
• The SN of "Apple Mac OS Application Signing" is not present in in version 146 upgraded from version 137

So the assumpion of DB upgrade issues seems to be the most probable issue.

It would be nice if Apple could just push a complete copy of a "clean" DB rather than pushing upgrade scripts to it...

johnno_uk wrote:

Will Yosemite versions of those two time machine files be compatible with High Sierra? If so, I can transplant her older ones from Time Machine into her current system. 

I'd be reluctant to offer solutions that block updates or run regularly to either clear keys or keep putting a donor database in place automatically as I don't really think it's a good idea to modify a machine in that way, especially somebody else's machine. ... As a get out of jail free card though the App I've been using to get serials easily hasn't failed so far to make a non running app run again just by loading it and dragging the app onto it. https://brockerhoff.net/RB/AppCheckerLite/

It works because this app shows both code signing certificates and App Store receipts and whether they are valid or not plus crucially the way it does that is to call APIs that make trustd make an OCSP request to Apple (this is a online check for just one certificate vs getting a set of bundled updates proactively) which will find the certificates to be good. That good state will hang about for up to 3 hours and so apps can be launched again.

I also don't like those solutions that block updates or run regularly. I've done that to my own machine in the past but then weeks later have to spend an hour doing research to remember how to undo it. No way will I do that to somebody else's computer.

Your explanation of why AppChecker will temporarily fix a non-launching app explains why the same thing happens with What's Your Sign. I'll point out again that WYS also allowed the App Store to download something when I ran it on the App Store app. People who are having trouble with downloads might give that a try.

Thank you so much for your suggestions.

I'll watch that video and I do back your theory.

By nature, PKI and its rules, the AIA extension containing an OCSP responder is THE authority to know if a cert has been revoked or not.

If you build an OS that relies on its own mechanism to check for certificate revocation (trustd) rather than having your OS follow PKI rules and hit the OSCP server, then you are walking on eggshells and vulnerable to this type of issue.

This of it. Assuming HS was to rely on OCSP, and OCSP only, if a cert is revoked by mistake one day, the OCSP responder will respond with GOOD the other day and life will go on. Small glitch, small hiccup.

But then if trustd builds and maintains its own source of trustyness rather than looking up the OCSP server, then this home-made source of trustyness can become, well, corrupted.

And maybe Johnno_uk is right, maybe they haven't thought of a use case where a cert could be accidently marked as revoked by an OCSP server one day, and marked as valid the next day.

oops....

Hi all,

So I have this same issue on an old iMac late 2009 (been trying to fix for couple weeks before reading this thread doh!) - I recently did a clean install when the issue was introduced - I've done multiple clean installs since all with the same result.

One thing I did try today was to install High Sierra in a Virtual Machine (Parallels) - I used the same USB Bootable High Sierra key I previously used on the iMac above. It worked perfectly in the VM using the same Apple ID - all apps downloaded, installed and opened perfectly!

This got me thinking if the issue is Apple somehow links the certificates (via iCloud/keychain) to the hardware? I wonder if removing the iMac from the apple account and doing a clean install again would fix it? (I tried removing the machine from iCloud account and re-signing in but this did not work).

Interesting that it works in the VM but not on the physical machine - any thoughts?

Thanks so much to everyone who has worked so hard on this and helped find solutions -- you are amazing!

I posted yesterday before I realized how extensive the thread was, and that there were some solutions (even if temporary) floating around. I was able to get my App Store apps working by replacing the valid.sqlite3 file with the older one, which was very exciting! As of today (day 2) the apps are still launching.

A few questions I'm wondering about:

1. If I've replaced the valid.sqlite3 file with the older version (as posted by softmusic on p.13 of this thread), is this just temporary -- will it go back to the way it was at some point? Also, will it cause any other problems on the computer?
2. Does it matter if the hard drive is formatted with HFS+ or APFS? I'm running it on an internal SSD, but I first installed High Sierra on it using a SATA/USB adapter, so it ended up with the HFS+ format. Hope this is okay.
3. So far I haven't installed the Security Updates from the App Store. With this solution, does it matter if I install those or not?

Many thanks again!

That's a sensible question. The answer is that No, the mechanism of phoning home is to ask primarily for news of certificates that have become considered bad. So all apps and their certificates will be considered innocent until proven guilty locally meaning they will keep working at least until they expire which is years away.

The only reason phoning home was needed (to make apps work again) this time was to correct an update where Apple had said their own certificates were bad which was clearly an error.

If you were to have never connected the machine to the Internet then apstore apps copied from a backup say would have worked too because you'd never have gotten the erroneous update.

It was really just the worst time to install High Sierra since it conincided with Apple's blunder.

I have just run the following command to lock the file, let's see how it goes.

sudo chflags uchg /Library/Keychains/crls/valid.sqlite3

I just finished a clean installation without connecting to the internet during the initial setup. The first thing I did once I logged into the desktop was disabling automatic updates. Then I connected the computer to the internet and installed iMove, Pixelmator, Tweetbot and they all worked. I restarted the computer several times to check if the downloaded apps would still work and they worked. Then I downloaded Keynote and it didn’t work and when I tried the previously downloaded apps (Pixelmator, iMovie, Tweetbot) they stopped working and gave me the same error again.

Don’t waste your time trying another clean install. We made everything we can and the only solution is Apple fixing this.

Same problem here. Had to run the command again today and click Signing Info.

spctl --assess -v /Applications/Numbers.app

The command has to be run for each user account.

I hope someone will find a more definitive solution.