Command CodeSign fails because of two Apple Worldwide Developer certificates

We have the same problem.

Weird. The presence of the older intermediate should not cause prevent the system from forming a chain of trust via the newer one.

You tagged your thread with Xcode. Does that mean you’re seeing this in Xcode? If so, the next time this happens, just for diagnostic purposes, try signing some code outside of Xcode using the codesign tool. Does that reproduce the problem?

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

Yes, the problem is not with Xcode. Codesign tool also fails. If you look in Keychain, it shows that Apple Development certificate is not trusted. If I touch something in keychain, for example, add/remove any certificate, it becomes Trusted. Apparently there is something wrong with the MacOS 13.0 system.

Apparently there is something wrong with the MacOS 13.0 system.

Indeed.

For diagnostic purposes only, create a new user account on that machine and add the Apple Development signing identity [1] and both the WWDR intermediates to that account’s login keychain. Does that have the same problem?

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

[1] You’ll need to export this as a PKCS#12 (.p12) files.

I have the same issue. It survives multiple devices, accounts and OS updates! Fix it!

As for now I use the following walk-around. You need to UNTRUST the following certificates:

• Apple Worldwide Developer Relations Certification Authority (exp. 2023)
• Developer ID Certification Authority (exp. 2027)

However, it doesn’t work all the time, so I just delete them (xcode will eventually generates them again) :/

It survives multiple devices, accounts and OS updates

So, to be clear, you ran the test I described in my previous post and the problem persists?

If so, I have some new tests for you to run. While the system is in the broken state, try to sign something with codesign. For example:

% cp /usr/bin/true MyTrue                                               
% codesign -s "Apple Development: UUU" -f -vvv MyTrue
MyTrue: replacing existing signature
MyTrue: signed Mach-O universal (x86_64 arm64e) [MyTrue]

replacing Apple Development: UUU with the name of your signing identity. Presumably this will fail. What does it print?

Then use Keychain Access to export your signing identity’s certificate to a .cer file and run this command:

% security verify-cert -c "Apple Development- UUU.cer" -p codeSign -vvv

where Apple Development: UUU.cer is the name of the .cer file. What does it print?

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

@eskimo, here you go:

> % codesign -s "Apple Development ***" -f -vvv MyTrue

MyTrue: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development ***"
MyTrue: errSecInternalComponent

> % security verify-cert -c "Apple Development ***.cer" -p codeSign -vvv

...certificate verification successful.
---
Certificate chain
 0: Apple Development ***
    <cert(0x12301a200) s: Apple Development *** i: Apple Worldwide Developer Relations Certification Authority>
 1: Apple Worldwide Developer Relations Certification Authority
    <cert(0x12301ac00) s: Apple Worldwide Developer Relations Certification Authority i: Apple Root CA>
 2: Apple Root CA
    <cert(0x123016e00) s: Apple Root CA i: Apple Root CA>
---
Certificate chain properties
(
        {
        error = "No error.";
        title = "Apple Development ***";
    },
        {
        title = "Apple Worldwide Developer Relations Certification Authority";
    },
        {
        title = "Apple Root CA";
    }
)
---
Trust evaluation results
{
    TrustEvaluationDate = "2022-12-15 09:30:41 +0000";
    TrustExpirationDate = "2022-12-15 13:35:57 +0000";
    TrustResultDetails =     (
                {
        },
                {
        },
                {
        }
    );
    TrustResultValue = 4;
    TrustRevocationChecked = 1;
}

> % codesign -s "Apple Development ***" -f -vvv MyTrue

MyTrue: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development ***"
MyTrue: errSecInternalComponent

When I remove duplicated certificates:

> % codesign -s "Apple Development ***" -f -vvv MyTrue

MyTrue: replacing existing signature
MyTrue: signed Mach-O universal (x86_64 arm64e) [MyTrue]

Same here

codesign -s "Apple Development: UUU" -f -vvv MyTrue

MyTrue: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Apple Development: UUU"
MyTrue: errSecInternalComponent

% security verify-cert -c "Apple Development- UUU.cer" -p codeSign -vvv

...certificate verification successful.
---
Certificate chain
 0: Apple Development: UUU
    <cert(0x13f016400) s: Apple Development: UUU i: Apple Worldwide Developer Relations Certification Authority>
 1: Apple Worldwide Developer Relations Certification Authority
    <cert(0x13f016e00) s: Apple Worldwide Developer Relations Certification Authority i: Apple Root CA>
 2: Apple Root CA
    <cert(0x13f017600) s: Apple Root CA i: Apple Root CA>
---
Certificate chain properties
(
        {
        error = "No error.";
        title = "Apple Development: UUU";
    },
        {
        title = "Apple Worldwide Developer Relations Certification Authority";
    },
        {
        title = "Apple Root CA";
    }
)
---
Trust evaluation results
{
    TrustEvaluationDate = "2022-12-15 17:41:28 +0000";
    TrustResultDetails =     (
                {
        },
                {
        },
                {
        }
    );
    TrustResultValue = 4;
}

After I add/remove any certificate in Keychain it signs normal

MyTrue: replacing existing signature
MyTrue: signed Mach-O universal (x86_64 arm64e) [MyTrue]

This just gets weirder. codesign and security verify-cert use the same system infrastructure to build the chain of trust, so it’s very surprising that the first fails and the second works.

Way back at the beginning Cuddy wrote:

One is valid until 2030 and the other is valid until 2023

I’d like to get a better handle on exactly which certificates are involved here. Unfortunately the output from security verify-cert only includes the Common Name, which is not enough to identify them. Moreover, there are two different intermediates that expire in 2030 )-:

Note For a list of all those intermediates, see the Apple PKI page.

So:

1. Open Keychain Access.

2. Find the two WWDR intermediates.

3. For each one, double click it and look at the Subject Name > Organizational Unit field.

4. What values do you see?

Also:

1. Still in Keychain Access.

2. Find the Apple Development: UUU certificate from the digital identity you’re trying to sign with.

3. Double click it and look at the Issuer Name > Organizational Unit field.

4. What value do you see?

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

@eskimo, All info in Subject Name section of two WWDR:

Apple Worldwide Developer Relations Certification Authority Expires: Wednesday, 20 February 2030

Common Name Apple Worldwide Developer Relations Certification Authority
Organisational Unit G3
Organisation Apple Inc.
Other Name US

Apple Worldwide Developer Relations Certification Authority Expires: Wednesday, 8 February 2023

Other Name US
Organisation Apple Inc.
Organisational Unit Apple Worldwide Developer Relations
Common Name Apple Worldwide Developer Relations Certification Authority

Also Issuer Name: for Apple Development: UUU

Common Name Apple Worldwide Developer Relations Certification Authority
Organisational Unit G3
Organisation Apple Inc.
Other Name US

So for the first certificate it's Organisational Unit G3 for second it's Organisational Unit Apple Worldwide Developer Relations. My developer certificate based on Organisational Unit G3.

But in my case it's working with these 2 certificate in Keychain. For me сodesign fixes itself for a while after any Keychain modification (e.g. I add any new generated certificate in Keychain). So i don't know how it's connected to the issue.

I have exactly the same info :)

Thanks for the info. I used that to install the right two intermediates and an appropriate Apple Development signing identity on a test machine here in my office. It worked as expected. Given the lack of wider complaints about this issue, I suspect that there’s something specific about your system, or your environment, that’s causing it. However, I’m at a loss as to explain what that might be.

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

Did you find a solution to this problem ?

I'm facing a similar issue described here