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

softmusic, I think you're on to something, but here is a twist.

I have 2 machines that both have High Sierra. Neither one is a recent install of High Sierra, but the problem occurred with an update to 10.13.6. On the Macbook Pro (that doesn't have this problem) I updated to 10.13.6 using the app store updates. With the desktop machine (that has this problem) I downloaded the combo installer/updater and used that to update from an earlier version of High Sierra to 10.13.6.

you're on the safe side, keeping a backup. I was troubleshooting on a Mac that I didn't mind breaking. If someone wants to come up with THE clean solution, here is what you need to do:

• use sqlite3 to edit this small SQLite DB
• Find and remove the serial number of the certificate "wrongfully" marked as revoked.

I don't have time for that, and I'm sure this CRL DB will get recreated in a clean way by trustd anyway...

arg! @Softmusic is right, the CRL file gets rebuilt and still marks the certificate as revoked.

So, Apple is pushing this CRL file to new High Sierra installs. But @cavenewt gave me an idea, which is now giving me some progress and some real strane results..

By default, with the file valid.sqlite3 in place, from the App Store using High Sierra, I can only see and download version 8.0 of MS Remote Desktop, and of course it fails to launch because of the revoked certificate.

Now if I delete valid.sqlite3, search again on the App Store for MS Remote Desktop, I can now see and download version 10.4.1. The install acted strange (had to try 2-3 times), but it eventually did. But the app is in its own "Microsoft Remote Desktop" folder in Applications.

and strangely, this new version of Remote Desktop does not embed certificates. Using --extract-certificates extracts no files.

So, assuming Apple has revoked the signing cert because of a legitimate reason, I now see two things happening:

1. 1. They have broken older apps and we can't run them anymore. Bad for users, good for security.
   2. They are not revoking new apps. Good for users, bad for security.

I am really at lost.

For now, I'm running with the newer app, which is only available if you delete valid.sqlite3.

OK, I'm not a terminal jockey so could you explain this a little more? What does it do?—as long as you leave Terminal open it repeatedly deletes that database?

I need to find some solution for my client, who is non-technical, and which won't require undoing something when Apple finally fixes this. That's why I haven't wanted to try any solutions that involve turning off SIP, or messing with the Hosts file.

@cavenewt: ok. ok. that was just to have a bit of fun.

After I took upon myself to not be lazy, here is the command that will remove the offending revoked certificate from the trustd database:

sudo sqlite3 /Library/Keychains/crls/valid.sqlite3 'delete from serials where hex(serial) = "04CA81F77D5E33F7"'

Now what is left to see is if the certificate serial number will be added back after a reboot.

I'll know soon.

I didn't have any luck with the terminal command (later: my fault, typo). So instead, I opened up the folder using command-shift-G and just dragged the new file into there (after prefixing the old file's name with a couple of xx so it would remain as a backup).

Applications are now launching even after a reboot. Cross fingers.

I am curious what might happen the next time that database is written to — if Apple makes a change, or if another application is downloaded from the App Store…?

But my client wants her computer back so we'll go with this for now! Thank you guys for all your hard work.

scrutinizer82 wrote:

Have you tried doing that and disabling SIP like I suggested?

nah. I prefer the workaround I posted about removing the rogue entry using sqlite3.

Also, modifying hosts by blocking OCSP is not going to do any harm.

well, OCSP exists for a reason. Yes it has its shares of privacy drawbacks like it was recently discussed, but I prefer this privacy drawback than not being made aware that my bank TLS certificate has been revoked because its private key was disclosed and a MITM now gets my credentials.

I don't have the confirmation, but I would betcha that Safari heavily relies on OCSP. So by blocking OCSP requests, you make people more vulnerable when browsing. And with the amount of people reading this thread now, and everyone who provided "a workaround", the experts here should be recommending the safer solution.

Which solution would that be? ;-)

Thank you FrancoisQC, your workaround is much nicer than replacing with an old database. I will try it.

Does it means that an old High Sierra install is not as safe as a fresh one ? Is it another security flaw from Apple ?

I have MacBook Pro late 2011 and apps not opening, on black magic speed test I get Dyld error library not loaded message. Is it likely Apple will resolve? I have read they are making HS obsolete at the end of Jan!!

M-Ibrahim wrote:

Sorry for the stupid question, but what’s the difference between this solution

sudo sqlite3 /Library/Keychains/crls/valid.sqlite3 'delete from serials where hex(serial) = "04CA81F77D5E33F7"'

and replacing the database with an old one?

There are no stupid questions, just people answering stupid answers...

The first one edits the current database, removing one entry.

The second uses a database that does not contain the entry.

To answer Softmusic

Does it means that an old High Sierra install is not as safe as a fresh one ? Is it another security flaw from Apple ?

I'd have to say something is shady, as old installs should provide the same CRLs as fresh installs. Even if Apple is pushing some rogue data, the CRL data for old and new installs should be the same.

Unless we know why Apple is marking it as revoked I don't have an answer.

"Finally, with this fix applied we noticed that in the App Store all installed apps do not indicate their installed status correctly. They show a button saying 'open' but even if we install it again the button only shows 'installed' until there is a page refresh, then it's back to 'install'."

I noticed that, too.

By "old" database I mean the one that's broken. I think it was about 17 MB…? I don't have that computer here anymore so I can't check. I replaced that with the one provided by softmusic at https://discussions.apple.com/thread/252037712?answerId=253982289022#253982289022 which is about half the size.

I now see why you asked the question. The smaller database that works is actually the one that predates November 11. The larger broken database is the one that showed up in installs of High Sierra after that. My bad, sorry.