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

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? ;-)

FrancoisQC wrote:

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.

Which solution would that be? ;-)

I talked about blocking specifically ocsp.apple.com. Blocking this host has nothing to do with your bank or any other organisation and institution using ocsp because ocsp itself is a protocol, not a host.

Also, answering your last question, the solution should be the one that works. At least, that's the philosophy of how I get things done. Security is commendable until it inhibits your workflows. It shouldn't be revered as the sacred cow. I prefer flexibility solving problems, so I don't understand why not try something that works if it does and is infinitely easier than manipulating SQLite databases with the shell scripting involved? Do you want your computer back or not? Sometimes, it's not possible to have everything at once and in perfect state.

You can't resolve this issue nor guarantee it won't return. Only Apple engineers can, but only if they'll be told. Until then it's all fuss about nothing.

I talked about blocking specifically ocsp.apple.com. Blocking this host has nothing to do with your bank or any other organisation and institution using ocsp because ocsp itself is a protocol, not a host.

Yeah you are right. My brain was stalled on "blocking OCSP altogether", not "blocking OCSP for Apple-issued certificates".

I guess both options are good, one completely disables OCSP checks for Apple-issued certificates, and one that "unrevokes" a certificate. The thing is, if a rogue app makes it way into the Apple Store and Apples decides to use OCSP to block that App, the first option will most likely not prevent the app from running.

Anyhow, it's all about cooperation, right? and I'm not here for Levels or Points. I will disapear once this issue is gone.

and that makes me wonder... what are those 45,000+ certificate serial numbers in the serials table of valid.sqlite3?

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!!

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?

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.

Personally I beleive it should be the same for all users. The folder it sits in, "crl", implies that it is a SQLite DB that contains some CRL-ish data. But valid.sqlite3 is NOT a CRL, it's just a simple database that High Sierra probably uses that for caching, for faster certificate checks rather than having to parse a CRL every time, or hit an OCSP server.

The fact that deleting the DB and that the CA serial number gets added back to this DB baffles me. Why is Apple pushing that cert as being revoked.

But that I write this, I'll need to check the other tables in the DB, as you just don't use a serial number to uniquely identify a cert. You need more than that. If Apple only keeps certificate serial numbers, then I could see the case where a certificate with the same serial number, but issued by a different CA, is getting revoked and High Sierra would incorrectly see its own certificate as being revoked. That would be a HUGE design mistake.

For the non-Terminal-savvy out there, those who prefers a "click and fix" solution, I created an Automator script that will do the work.

Get the .dmg file from https://gofile.io/d/ebWFWJ

A bit more user friendly..

And regarding the apps that fails, I looked at the certs of Display Menu. They look the same, but the install somewhat failed for me. Not sure what's going on for now.

"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.

The database file that I provided comes from an iMac that someone gave to me. If someone here have another old High Sierra installation, it would be interesting to compare it with my file.

Anyway, I prefer FrancoisQC's solution. I wanted to do a clean fresh High Sierra and avoid using any file from the old installation.

The new database (the one that is automatically rebuilt when deleted) has more elements in table "issuers" but less "serials". I don't know what it means.