For testing purposes we have code that calls SecTrustEvaluateAsyncWithError()
with a trust object containing a hardcoded leaf certificate and the corresponding intermediate certificate required to form a valid chain. Because the leaf certificate has since expired we pass a date in the past via SecTrustSetVerifyDate()
at wich the certificate was still valid, but trust evaluation fails:
Error Domain=NSOSStatusErrorDomain Code=-67825 "“<redacted>” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“<redacted>” certificate is not standards compliant, NSUnderlyingError=0x600000c282a0 {Error Domain=NSOSStatusErrorDomain Code=-67825 "Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;" UserInfo={NSLocalizedDescription=Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;}}}
I know that App Transport Security enforces Certificate Transparency by default, but is there a way around that here?
So, the code under test takes a trust object (SecTrust
) and returns an allow / deny decision based on the public keys in the certificates in the chain?
If so, you could solve this problem by having you test hardness create the trust object using the basic X.509 policy (SecPolicyCreateBasicX509()
) rather than TLS policy (SecPolicyCreateSSL(_:_:)
).
ps You’re probably aware of this, but ATS supports public key pinning via the NSPinnedDomains
property. If that works for you, it’s a lot easier than doing this in code.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"