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

Information on the certificates can be view within the KeyChain app. Line-by-line the System Roots Apple certificates in the SSD installation look the same as in the HDD installation. Specifically, Apple Root CA, Apple Root CA - 1, Apple Root CA - 2, Apple Root CA - 3, and Apple Root Certificate Authority.

First, it was necessary for me to upgrade to HS because of new versions of software I use that had to have it. Unfortunately there is no real "going back" prior to applying the last 2 security updates, because this all started when I updated to HS (and it took me an entire day to get it all straightened out just doing the update). Unfortunately, going back is something windows does but macOS can not do.

I was shocked, I made a customer service inquiry w/Cupertino, got back the usual kind of response at someone who just started using Macs, but I HAVE someone to send stuff to. It is possible I will get to tier 3 engineers, the couple of times I made it that far were helpful... although it seems to me what is needed is another "update" to fix what is in the last one causing this issue. I see all sorts of "hacky" ways to try and solve it, we users should not have to go through anything like that.

AND on a much lighter note I got 2 emails from the mothership. One saying I had reached Level two then another one showing me as level 1, saying I completed it... and it looks like they demoted me back to level 1.

Hmmm, we all seem to be focused on just the last security update, 006. Of note is the supposed full, 5G installer that I downloaded fresh last week that I THOUGHT was complete and up to date was odd. I know nVidia very carefully tracks every OS build number, their way seem to have each version of their drivers specific for a known build. BUT the build number of the "full" installer was way outside the range of their usual numbering schemes AND had no equivalent driver from nVidia. The App Store app said I needed to update to security 005. I did that, the "old" nVidia drivers led me to a working driver for that build. I thought I was in business BUT on reboot, same App Store app said I had to apply the 006 security update. I did that. nVidia also knew to get me drivers for THAT build.

I backtraced the sec. updates, 005 came 26 Sept 2019. 006 12 Nov 2020. Seems pretty clear, given there was no sustained outcry over 005 that all the issues are directly tied to 006.

While I certainly admire all the "doggedness" of Mac users trying to uncover the failure from Cupertino, WE have to live with that failure... crickets from Cupertino. This sure ain't the Apple I started with in May, 1984.

Interesting! I'm here because I just upgraded a client's Yosemite system to High Sierra. The old version of Pages she had wouldn't launch, so I updated Pages in the App Store (which was an ordeal in itself because it wouldn't download, and yes it was offering me an older version compatible with HS… I eventually got it to work in Safe Mode) . Now none of the iWorq Applications will launch; Pages throws up some sort of a complaint about a plug-in.

I think I'll go download some other free app and see if it exhibits the same problem. I spent two or three hours today doing things like clearing out cache and preference files, booting into safe mode, disk repair, etc. No joy.

After leaving my setup alone yesterday, out of frustration of not figuring out the issue, I decided to give it a shot again this morning before going back to work.

All MS Remote Desktop was still failing to launch, no change.

Then I messed around and things started to work again. Here are things that I believe could have an impact on getting things to work again:

1. I still had the two Apple WDRCA certificates manually added to the Systems keychain. I had added them two days ago. No idea on impact, but can't hurt.
2. One of those commands, and some delay afterwards (maybe a minute??) seems to have changed something

spctl --status

spctrl --master-disable

spctrl --add /Applications/Microsoft\ Remote\ Desktop.app

spctrl --assess /Applications/Microsoft\ Remote\ Desktop.app

spctrl --remove /Applications/Microsoft\ Remote\ Desktop.app

spctrl --master-enable

But yet again, the strange thing is that once I can get the app to start, I can no longer log in to the discussions.apple.com communities, as Safari then can't connect to the server I get redirected to for authentication!

The way this is starting to look is that High Sierra builds a CA Trust Chain with one CA or the other, allowing me to start an app (CA1) or allowing me to connect to the auth server (CA2).

Time to reboot, see if some caching gets cleared, and try to reproduce what allowed the app to start.

OK guys, which to try first?

• The spctl [spctrl is a typo, right?] from https://discussions.apple.com/thread/252037712?answerId=253962571022#253962571022

or

• The codesign from https://discussions.apple.com/thread/252037712?answerId=252037712021#252037712021

Which is what I suggested in my post in this thread just yesterday but a rare person might come across it. Go check it

https://discussions.apple.com/thread/252037712?answerId=253963482022#253963482022

It may only be happening to people who downloaded High Sierra installers in the last couple of weeks. I've had High Sierra on my laptop for a few months and I'm not having any trouble. However, I just upgraded a client's computer from Yosemite to High Sierra and it's experiencing this problem.

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?

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.

well, some bad news. I know for a fact I had been running on my workaround for a while (DB update)... this morning the CA is back to be revoked. So trustd's DB got updated again, re-adding the cert to be revoked.

The workaround still works, but it gets reverted after a few days...

And yes, it also causes this strange error when installing other apps.

softmusic wrote:

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.

The computer I was working on was a client's with a new install of High Sierra. My own computer was upgraded several months ago to High Sierra, and has not been exhibiting the problem (I have a lot of App Store apps). Here is the copy of the database from my computer.

https://www.dropbox.com/s/56nzoo5xpo9tcrw/valid.sqlite3.zip?dl=0

Arak911 wrote:

I've been following this thread as I've also had this problem. I have copies of all my OS since Mavericks. I don't know if it matters if I clean install a High Sierra from 2019 or not.

That's a good thought. Trouble is, saved installers have an expiration date. You might be able to use that older installer by changing your system clock but that kind of screws up the logs, at the very least.