crypto/x509: root_cgo_darwin and root_nocgo_darwin omit some system certs

[jdhenke]

Please answer these questions before submitting your issue. Thanks!

What did you do?

$ cat main.go

package main

import (
	"crypto/x509"
	"fmt"
	"log"
)

func main() {
	certs, err := x509.SystemCertPool()
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("Num System Certs: %d\n", len(certs.Subjects()))
}

$ CGO_ENABLED=0 go run main.go
Num System Certs: 188
$ CGO_ENABLED=1 go run main.go
Num System Certs: 168

What did you expect to see?

I expected to see the same number of certificates regardless of whether I used cgo.

What did you see instead?

The implementation using CGO resulted in fewer system certificates, which causes problems for our tooling that relies on one of those missing certificates to be in the SystemCertPool.

System details

go version go1.10.1 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jhenke/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/jhenke"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_b/gz_w_nfj0_33f5y3s_0pg8xs080pym/T/go-build925272903=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.10.1 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.10.1
uname -v: Darwin Kernel Version 16.7.0: Mon Nov 13 21:56:25 PST 2017; root:xnu-3789.72.11~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.6
BuildVersion:	16G1114
lldb --version: lldb-900.0.64
  Swift-4.0

[adamdecaf]

Could you tell us more about the certificates not found in the cgo path? Are they set with specific trust policies? Could you paste a certificate that isn't found, but should be?

[nmiyake]

Do you know of a way to print/examine the trust policies of a certificate? After some experimentation, we have found that the certificates that aren't showing up seem to say "This certificate has custom trust settings" in the Keychain UI. However, expanding the "Trust" section doesn't reveal any specifics:

I'm not sure how the certificate was added/got to this state. It seems that if we manually update the state to "Always Trust" in the Keychain UI, then the certificate is returned. However, we'd like to understand this further, since most apps seem to trust the certificate even with these "Custom" trust settings but Go with CGo does not, which is causing issues for us.

*To clarify, I suspect that the issue has to do with the trust settings marked for the certificate rather than with the certificate itself

[bcmills]

(CC: @FiloSottile)

[adamdecaf]

@jdhenke @nmiyake I've had to add the certificates into either the login keychain or /Library/Keychains/System.keychain. Doing this with the security tool looks like:

# One of these two should work
$ security add-trusted-cert -p ssl -k ~/Library/Keychains/login.keychain cert.pem
$ security add-trusted-cert -p ssl -k /Library/Keychains/System.keychain cert.pem

How are you adding the certs?

The Keychain UI is pretty much the easiest way to view trust, but it's not always clear. I've been working on better ways to parse the security tool output.

You can inspect the certs with the tool by running something like, which is what non-cgo Go does:

security find-certificate -c <name> -a ~/Library/Keychains/login.keychain /Library/Keychains/System.keychain /System/Library/Keychains/SystemRootCertificates.keychain 

I've talked about the inverse of this problem (explicit distrust of certificates) at #24084, which has the same confusion/problem.

[nmiyake]

Unfortunately, I'm not sure about the provenance of how the cert was added. However, I do suspect that how it was added/how it was upgraded from a previous add is at the root of the issue here.

I have a certificate in my System store called "MSCA-ROOT-01-CA". I'm not sure how it was added, but the screenshot earlier in the issue shows that it displays as "This certificate has custom trust settings", although the UI shows "Always Trust" for all the parts.

I added some debugging code to root_cgo_darwin.go (edits at the end of this post), and the resulting output for this cert is:

Processing cert: MSCA-ROOT-01-CA
getting domain 1 for trust settings
using domain 1 for trust settings
getting domain 2 for trust settings
trustSettings is not NULL
len of trustSettings: 0
done. untrusted: 0, trustAsRoot: 0, trustRoot: 0

Based my reading of the code, this certificate is in the "Admin" domain and has a non-NULL but empty trust setting. Because the trust setting is empty and it isn't a system cert, it decides not to trust it.

This logically makes sense to me, but I guess the resulting behavior isn't consistent with other applications (other applications seem willing to use this certificate for verification).

Modified FetchPEMRoots in crypto/x509/root_cgo_darwin.go:

int FetchPEMRoots(CFDataRef *pemRoots, CFDataRef *untrustedPemRoots) {
	if (useOldCode()) {
		return FetchPEMRoots_MountainLion(pemRoots);
	}

	// Get certificates from all domains, not just System, this lets
	// the user add CAs to their "login" keychain, and Admins to add
	// to the "System" keychain
	SecTrustSettingsDomain domains[] = { kSecTrustSettingsDomainSystem,
					     kSecTrustSettingsDomainAdmin,
					     kSecTrustSettingsDomainUser };

	int numDomains = sizeof(domains)/sizeof(SecTrustSettingsDomain);
	if (pemRoots == NULL) {
		return -1;
	}
	printf("numDomains: %d\n", numDomains);

	// kSecTrustSettingsResult is defined as CFSTR("kSecTrustSettingsResult"),
	// but the Go linker's internal linking mode can't handle CFSTR relocations.
	// Create our own dynamic string instead and release it below.
	CFStringRef policy = CFStringCreateWithCString(NULL, "kSecTrustSettingsResult", kCFStringEncodingUTF8);

	CFMutableDataRef combinedData = CFDataCreateMutable(kCFAllocatorDefault, 0);
	CFMutableDataRef combinedUntrustedData = CFDataCreateMutable(kCFAllocatorDefault, 0);
	for (int i = 0; i < numDomains; i++) {
		CFArrayRef certs = NULL;
		OSStatus err = SecTrustSettingsCopyCertificates(domains[i], &certs);
		if (err != noErr) {
			continue;
		}

		CFIndex numCerts = CFArrayGetCount(certs);
		for (int j = 0; j < numCerts; j++) {
			CFDataRef data = NULL;
			CFErrorRef errRef = NULL;
			CFArrayRef trustSettings = NULL;
			SecCertificateRef cert = (SecCertificateRef)CFArrayGetValueAtIndex(certs, j);
			if (cert == NULL) {
				continue;
			}
			// We only want trusted certs.
			int untrusted = 0;
			int trustAsRoot = 0;
			int trustRoot = 0;
			if (i == 0) {
				trustAsRoot = 1;
			} else {
			    CFStringRef commonNameRef = NULL;
				SecCertificateCopyCommonName(cert, &commonNameRef);
				printf("Processing cert: %s\n",  CFStringGetCStringPtr(commonNameRef, kCFStringEncodingMacRoman));

				// Certs found in the system domain are always trusted. If the user
				// configures "Never Trust" on such a cert, it will also be found in the
				// admin or user domain, causing it to be added to untrustedPemRoots. The
				// Go code will then clean this up.

				// Trust may be stored in any of the domains. According to Apple's
				// SecTrustServer.c, "user trust settings overrule admin trust settings",
				// so take the last trust settings array we find.
				// Skip the system domain since it is always trusted.
				for (int k = i; k < numDomains; k++) {
					printf("getting domain %d for trust settings\n", k);
					CFArrayRef domainTrustSettings = NULL;
					err = SecTrustSettingsCopyTrustSettings(cert, domains[k], &domainTrustSettings);
					if (err == errSecSuccess && domainTrustSettings != NULL) {
						if (trustSettings) {
							CFRelease(trustSettings);
						}
						printf("using domain %d for trust settings\n", k);
						trustSettings = domainTrustSettings;
					}
				}
				if (trustSettings == NULL) {
				    printf("this certificate must be verified to a known trusted certificate\n");
					// "this certificate must be verified to a known trusted certificate"; aka not a root.
					continue;
				}
				printf("trustSettings is not NULL\n");
				printf("len of trustSettings: %d\n", CFArrayGetCount(trustSettings));
				for (CFIndex k = 0; k < CFArrayGetCount(trustSettings); k++) {
					CFNumberRef cfNum;
					CFDictionaryRef tSetting = (CFDictionaryRef)CFArrayGetValueAtIndex(trustSettings, k);
					if (CFDictionaryGetValueIfPresent(tSetting, policy, (const void**)&cfNum)){
						SInt32 result = 0;
						CFNumberGetValue(cfNum, kCFNumberSInt32Type, &result);
						printf("resultNum: %d at index k=%d\n", result, k);
						// TODO: The rest of the dictionary specifies conditions for evaluation.
						if (result == kSecTrustSettingsResultDeny) {
							untrusted = 1;
						} else if (result == kSecTrustSettingsResultTrustAsRoot) {
							trustAsRoot = 1;
						} else if (result == kSecTrustSettingsResultTrustRoot) {
							trustRoot = 1;
						}
					}
				}
				printf("done. untrusted: %d, trustAsRoot: %d, trustRoot: %d\n", untrusted, trustAsRoot, trustRoot);
				CFRelease(trustSettings);
			}

			if (trustRoot) {
				// We only want to add Root CAs, so make sure Subject and Issuer Name match
				CFDataRef subjectName = SecCertificateCopyNormalizedSubjectContent(cert, &errRef);
				if (errRef != NULL) {
					CFRelease(errRef);
					continue;
				}
				CFDataRef issuerName = SecCertificateCopyNormalizedIssuerContent(cert, &errRef);
				if (errRef != NULL) {
					CFRelease(subjectName);
					CFRelease(errRef);
					continue;
				}
				Boolean equal = CFEqual(subjectName, issuerName);
				CFRelease(subjectName);
				CFRelease(issuerName);
				if (!equal) {
					continue;
				}
			}

			// Note: SecKeychainItemExport is deprecated as of 10.7 in favor of SecItemExport.
			// Once we support weak imports via cgo we should prefer that, and fall back to this
			// for older systems.
			err = SecKeychainItemExport(cert, kSecFormatX509Cert, kSecItemPemArmour, NULL, &data);
			if (err != noErr) {
				continue;
			}

			if (data != NULL) {
				if (!trustRoot && !trustAsRoot) {
					untrusted = 1;
				}
				CFMutableDataRef appendTo = untrusted ? combinedUntrustedData : combinedData;
				CFDataAppendBytes(appendTo, CFDataGetBytePtr(data), CFDataGetLength(data));
				CFRelease(data);
			}
		}
		CFRelease(certs);
	}
	CFRelease(policy);
	*pemRoots = combinedData;
	*untrustedPemRoots = combinedUntrustedData;
	return 0;
}

[adamdecaf]

@nmiyake Could you rebase that change off the latest commit on master? There's another change which mixes up the diff a bit.

I'm not sure if trusting a certificate without any policies from the user/admin domain would cause problems. If an attacker is modifying your trust policies they can already install a root CA.

There is a kSecTrustSettingsResultDeny policy I'd expect to be set (to explicitly distrust), but I don't know how widespread that's used. Keychain does use that.

[nmiyake]

Sure. Here's the modified code on master:

int FetchPEMRoots(CFDataRef *pemRoots, CFDataRef *untrustedPemRoots) {
	int i;

	if (useOldCode()) {
		return FetchPEMRoots_MountainLion(pemRoots);
	}

	// Get certificates from all domains, not just System, this lets
	// the user add CAs to their "login" keychain, and Admins to add
	// to the "System" keychain
	SecTrustSettingsDomain domains[] = { kSecTrustSettingsDomainSystem,
					     kSecTrustSettingsDomainAdmin,
					     kSecTrustSettingsDomainUser };

	int numDomains = sizeof(domains)/sizeof(SecTrustSettingsDomain);
	if (pemRoots == NULL) {
		return -1;
	}
	printf("numDomains: %d\n", numDomains);

	// kSecTrustSettingsResult is defined as CFSTR("kSecTrustSettingsResult"),
	// but the Go linker's internal linking mode can't handle CFSTR relocations.
	// Create our own dynamic string instead and release it below.
	CFStringRef policy = CFStringCreateWithCString(NULL, "kSecTrustSettingsResult", kCFStringEncodingUTF8);

	CFMutableDataRef combinedData = CFDataCreateMutable(kCFAllocatorDefault, 0);
	CFMutableDataRef combinedUntrustedData = CFDataCreateMutable(kCFAllocatorDefault, 0);
	for (i = 0; i < numDomains; i++) {
		int j;
		CFArrayRef certs = NULL;
		OSStatus err = SecTrustSettingsCopyCertificates(domains[i], &certs);
		if (err != noErr) {
			continue;
		}

		CFIndex numCerts = CFArrayGetCount(certs);
		for (j = 0; j < numCerts; j++) {
			CFDataRef data = NULL;
			CFErrorRef errRef = NULL;
			CFArrayRef trustSettings = NULL;
			SecCertificateRef cert = (SecCertificateRef)CFArrayGetValueAtIndex(certs, j);
			if (cert == NULL) {
				continue;
			}
			// We only want trusted certs.
			int untrusted = 0;
			int trustAsRoot = 0;
			int trustRoot = 0;
			if (i == 0) {
				trustAsRoot = 1;
			} else {
				CFStringRef commonNameRef = NULL;
				SecCertificateCopyCommonName(cert, &commonNameRef);
				printf("Processing cert: %s\n",  CFStringGetCStringPtr(commonNameRef, kCFStringEncodingMacRoman));

				int k;
				CFIndex m;

				// Certs found in the system domain are always trusted. If the user
				// configures "Never Trust" on such a cert, it will also be found in the
				// admin or user domain, causing it to be added to untrustedPemRoots. The
				// Go code will then clean this up.

				// Trust may be stored in any of the domains. According to Apple's
				// SecTrustServer.c, "user trust settings overrule admin trust settings",
				// so take the last trust settings array we find.
				// Skip the system domain since it is always trusted.
				for (k = i; k < numDomains; k++) {
					printf("getting domain %d for trust settings\n", k);
					CFArrayRef domainTrustSettings = NULL;
					err = SecTrustSettingsCopyTrustSettings(cert, domains[k], &domainTrustSettings);
					if (err == errSecSuccess && domainTrustSettings != NULL) {
						if (trustSettings) {
							CFRelease(trustSettings);
						}
						printf("using domain %d for trust settings\n", k);
						trustSettings = domainTrustSettings;
					}
				}
				if (trustSettings == NULL) {
					// "this certificate must be verified to a known trusted certificate"; aka not a root.
					printf("this certificate must be verified to a known trusted certificate\n");
					continue;
				}
				printf("trustSettings is not NULL\n");
				printf("len of trustSettings: %d\n", CFArrayGetCount(trustSettings));
				for (m = 0; m < CFArrayGetCount(trustSettings); m++) {
					CFNumberRef cfNum;
					CFDictionaryRef tSetting = (CFDictionaryRef)CFArrayGetValueAtIndex(trustSettings, m);
					if (CFDictionaryGetValueIfPresent(tSetting, policy, (const void**)&cfNum)){
						SInt32 result = 0;
						CFNumberGetValue(cfNum, kCFNumberSInt32Type, &result);
						printf("resultNum: %d at index k=%d\n", result, k);
						// TODO: The rest of the dictionary specifies conditions for evaluation.
						if (result == kSecTrustSettingsResultDeny) {
							untrusted = 1;
						} else if (result == kSecTrustSettingsResultTrustAsRoot) {
							trustAsRoot = 1;
						} else if (result == kSecTrustSettingsResultTrustRoot) {
							trustRoot = 1;
						}
					}
				}
				printf("done. untrusted: %d, trustAsRoot: %d, trustRoot: %d\n", untrusted, trustAsRoot, trustRoot);
				CFRelease(trustSettings);
			}

			if (trustRoot) {
				// We only want to add Root CAs, so make sure Subject and Issuer Name match
				CFDataRef subjectName = SecCertificateCopyNormalizedSubjectContent(cert, &errRef);
				if (errRef != NULL) {
					CFRelease(errRef);
					continue;
				}
				CFDataRef issuerName = SecCertificateCopyNormalizedIssuerContent(cert, &errRef);
				if (errRef != NULL) {
					CFRelease(subjectName);
					CFRelease(errRef);
					continue;
				}
				Boolean equal = CFEqual(subjectName, issuerName);
				CFRelease(subjectName);
				CFRelease(issuerName);
				if (!equal) {
					continue;
				}
			}

			// Note: SecKeychainItemExport is deprecated as of 10.7 in favor of SecItemExport.
			// Once we support weak imports via cgo we should prefer that, and fall back to this
			// for older systems.
			err = SecKeychainItemExport(cert, kSecFormatX509Cert, kSecItemPemArmour, NULL, &data);
			if (err != noErr) {
				continue;
			}

			if (data != NULL) {
				if (!trustRoot && !trustAsRoot) {
					untrusted = 1;
				}
				CFMutableDataRef appendTo = untrusted ? combinedUntrustedData : combinedData;
				CFDataAppendBytes(appendTo, CFDataGetBytePtr(data), CFDataGetLength(data));
				CFRelease(data);
			}
		}
		CFRelease(certs);
	}
	CFRelease(policy);
	*pemRoots = combinedData;
	*untrustedPemRoots = combinedUntrustedData;
	return 0;
}

Output was the same:

Processing cert: MSCA-ROOT-01-CA
getting domain 1 for trust settings
using domain 1 for trust settings
getting domain 2 for trust settings
trustSettings is not NULL
len of trustSettings: 0
done. untrusted: 0, trustAsRoot: 0, trustRoot: 0

From what I can tell, I have 3 certificates in my keychain that fit this criteria.

Adding this logic fixes the specific issue that we're seeing:

if (CFArrayGetCount(trustSettings) == 0) {
	trustAsRoot = 1;
}

(if this were to be done, I would presume it should probably be done for the case where trustSettings == NULL as well for consistency)

Interestingly, this doesn't fully resolve the diff for the number of certificates between CGO_ENABLED=0 and 1. My breakdown is:

• master, CGO_ENABLED=1: 172 certificates
• Trust certs with trustSettings ==0, CGO_ENABLED=1: 175 certificates
• master, CGO_ENABLED=0: 196 certificates

[adamdecaf]

@nmiyake Cool. If you want to submit that if (CFArrayGetCount(trustSettings) == 0) { change we can get it reviewed.

There's probably something up with the trust policies on those remaining certificates. Can you run the following?

$ security trust-settings-export user-trust.plist
$ security trust-settings-export -d admin-trust.plist

This dumps plist (xml) files of your certificate trust. The best way to find a specific cert is by the sha1 hash. It's the <key>...</key> in the following snippet.

Can you find a certificate that's added into a keychain, but isn't showing up in Go? I'm curious what <key>trustSettings</key> is saying.

The values there are mapped to SecTrustSettingsResult.

                <key>0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43</key>
                <dict>
                        <key>issuerName</key>
                        <data>
                        MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx
                        GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp
                        Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQQ==
                        </data>
                        <key>modDate</key>
                        <date>2018-02-24T19:37:04Z</date>
                        <key>serialNumber</key>
                        <data>
                        DOfg5RfYRv6P5WD8G/AwOQ==
                        </data>
                        <key>trustSettings</key>
                        <array>
                                <dict>
                                        <key>kSecTrustSettingsResult</key>
                                        <integer>4</integer>
                                </dict>
                        </array>
                </dict>

I'm building a quick tool to help debug these files. You can run it over the exported plist files and get something that's a bit easier to parse. https://github.com/adamdecaf/plist-parser

hash=0563B863 issuer="CN=DigiCert Assured ID Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US" trustSettings=map[string]string{"kSecTrustSettingsResult":"4"}

[nmiyake]

OK, performed more digging and diagnostics.

Here's the overview of my state with the current Go:

No CGo certs: 176
CGo certs: 161

0 CGo only, 15 non-CGo only, 161 common

After running with my modification proposed above, I get:

No CGo certs: 176
CGo certs: 164

1 CGo only, 13 non-CGo only, 163 common

I ran your parsing tool on my output, and indeed for some reason there are 3 certificates that explicitly have an empty trust settings set (only showing one here):

hash=00C337EA issuer="CN=MSCA-ROOT-01-CA" trustSettings=map[string]string{}

I'm not sure how this entry was created for me, but that's clearly the issue. Two of these certificates are valid and are added, and thus increment the "common" count by 2. One of these certificates is expired. This one appears only in the CGo code, which accounts for the "1 CGo only".

Here are some of the certificates that show up only for non-CGo (out of the 13):

        Apple Worldwide Developer Relations Certification Authority
        Developer ID Certification Authority
        DigiCert Assured ID CA-1
        DigiCert SHA2 Assured ID CA
        DigiCert SHA2 High Assurance Server CA

2 of these have an entry in my user-trust.plist with trustSettings=map[string]string{"kSecTrustSettingsResult":"-2147409654"}:

hash=20744DE6 issuer="CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US" trustSettings=map[string]string{"kSecTrustSettingsResult":"-2147409654"}

None of the other entries show up in my plist. In the keychain, these show up as "no value specified" for trust:

The one curious thing is the extra certificate that shows up for CGo only after the local modification. That certificate is an old CA certificate I have that is expired:

It's showing up because before the modification it was in my admin-trust.plist with map[string]string{} as the trustSettings, so the change now includes it. I'm guessing the non-CGo code automatically prunes it based on expiration.

I don't think this should be an issue since even if the cert is added as a root cert, any code that does validation should properly check the expiration status.

[gopherbot]

Change https://golang.org/cl/104735 mentions this issue: crypto/x509: add certs with empty trust settings for cgo_darwin

[adamdecaf]

@nmiyake Cool on that CL. You'll probably want to assign @FiloSottile as a reviewer.

As far as the certificates with "kSecTrustSettingsResult":"-2147409654". I think this is why they're not marked as trusted. -2147409654 is not a valid value. The relevant Go code only checks a couple of the values (see SecTrustSettingsResult).

if (CFDictionaryGetValueIfPresent(tSetting, policy, (const void**)&cfNum)){
	SInt32 result = 0;
	CFNumberGetValue(cfNum, kCFNumberSInt32Type, &result);
	printf("resultNum: %d at index k=%d\n", result, k);
	// TODO: The rest of the dictionary specifies conditions for evaluation.
	if (result == kSecTrustSettingsResultDeny) {
		untrusted = 1;
	} else if (result == kSecTrustSettingsResultTrustAsRoot) {
		trustAsRoot = 1;
	} else if (result == kSecTrustSettingsResultTrustRoot) {
		trustRoot = 1;
	}
}

Are your trust settings managed by an enterprise or tool by chance? It looks like some tool generated partially invalid policy settings.

I've had to work around this and seen it before. Here's an example plist I've seen in the wild. (Note: it's the same -2147409654 value)

				<dict>
					<key>kSecTrustSettingsAllowedError</key>
					<integer>-2147409654</integer>
					<key>kSecTrustSettingsPolicy</key>
					<data>
					KoZIhvdjZAEC
					</data>
					<key>kSecTrustSettingsPolicyName</key>
					<string>basicX509</string>
					<key>kSecTrustSettingsResult</key>
					<integer>3</integer>
				</dict>

On those 13-2 certificates I wonder again if the plist/trust policies were generated properly. Just search for DigiCert SHA2 High Assurance Server CA gives a different cert fingerprint than what your policy has. See: https://crt.sh/?id=2900424 (SHA1 prefix A031C467) https://crt.sh/?id=2900424.

Can you find any of those certificates on crt.sh? https://crt.sh/?a=1

[nmiyake]

Yes, this behavior is on a machine that's managed by a company and uses tools to do so -- something along the way there writing an invalid policy entry is definitely a possibility.

I guess the difference in observed behavior is that most macOS applications (or Apple's cert API itself?) are more lenient on their verification here? Even though strict validation may technically be correct, if it results in an observable difference in behavior between native macOS apps and Go apps with CGo enabled that stills seems like it could be an issue (and I don't really have any good way of knowing how common or uncommon this scenario may be more broadly).

[adamdecaf]

I guess the difference in observed behavior is that most macOS applications (or Apple's cert API itself?) are more lenient on their verification here?

I don't think we've determined that quite yet. Are any of those 13-2 certs not CA's?

I'm reading through the code paths and noticing only the cgo path checks the certificate is a Root CA (by checking Issuer == Subject).

Edit: Yep. I verified a non-ca certificate would show up in a non-cgo call to x509.SystemCertPool().