Trust evaluate failure: [leaf TemporalValidity]

Question

Created Jan ’21

Replies 4

Boosts 0

Views 3.5k

Participants 2

We have a case where some users, within the same organization, report that our application does not start on macOS Catalina.
When this is the case, the error message in console is

Trust evaluate failure: [leaf TemporalValidity]

The same app works on other devices which seem to be equivalent (same macOS version...).
I'm trying to figure out what could be the issue and which log could help us understanding what's wrong.

I can see track of this error in a blog post from the Eclectic Light Company Blog (sounds like I can't post the link, but googling for "What happened when MRT was updated" should redirect to it) ; both running / not running devices have most up to date MRT Data.

The app is signed and notarized (and it's anyway the same app on both devices).

Any idea on what to look at to understand what fails ?

Answered by DTS Engineer in 658547022

Ah, I missed the point that this was a code signing certificate. That does change my answer somewhat. Specifically, the About upcoming limits on trusted certificates article applies to TLS certificates only.

Is this enough to run codesign -dv --verbose=4 … to track down the
issue ?

No. -d displays information about the code signature, which doesn’t give you any insight into what’s going wrong. You could use --extract-certificates to extract the certificates and then look for date-related validity issues. Or you could actually do a trust evaluation using codesign -v.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’21

[leaf TemporalValidity] suggests that the certificate has problems with its notBefore and notAfter values. I can see two possibilites here, one obvious and one less so:

For trust evaluation to work, the evaluation time (typically the current time) must be between these values. It’s possible that the clock is off or that these times are bogus.
It’s possible that the certificate is too long lived. See About upcoming limits on trusted certificates.

Have you been able to capture the certificate that’s failing in this way?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

1

Answer 2

sysedit OP

Jan ’21

Thanks for the answer.

Is this enough to run

Code Block  codesign -dv --verbose=4 /path/to/executable_or_dylib

to track down the issue ?
I'll check if device time is properly set and I'll try to get codesign output as well.

Thanks !

0

Answer 3

DTS Engineer OP

Apple

Jan ’21

Accepted Answer

Ah, I missed the point that this was a code signing certificate. That does change my answer somewhat. Specifically, the About upcoming limits on trusted certificates article applies to TLS certificates only.

Is this enough to run codesign -dv --verbose=4 … to track down the
issue ?

No. -d displays information about the code signature, which doesn’t give you any insight into what’s going wrong. You could use --extract-certificates to extract the certificates and then look for date-related validity issues. Or you could actually do a trust evaluation using codesign -v.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 4

sysedit OP

Jan ’21

So we finally figured out the root cause - on impacted devices there were left-overs from a former (more than a couple of years old) installation. Those dylibs would be picked before the most recent ones located in a different path.
And the signing of these dylibs was not correct anymore..

Thanks for the help !

0