Skipping requirements for trusted certificates for manual CRL check?

Question

brucefromfortitude valley OP

Created Sep ’21

Replies 2

Boosts 0

Participants 2

Hi,

I am developing an app that requires manually checking if a certificate has been revoked via a CRL (certificate revocation list).

However, I'm running into an issue where my revocation check fails due to my root certificate "not meeting pinning requirements". After some searching I found this article: https://support.apple.com/en-us/HT210176

That article indicates that iOS requires certificates to have certain key sizes, etc. which my root certificate seemingly does not.

Is there any way to get around that when you are performing a trust evaluation manually? (i.e. via SecTrustEvaluateWithError). Note that the certificates I am working with are NOT used for TLS connections, which is why I was hoping there was a workaround for this.

For reference, I am using code similar to the following:

// Create policies
let basicPolicy = SecPolicyCreateBasicX509()
let crlPolicy = SecPolicyCreateRevocation(kSecRevocationOCSPMethod | kSecRevocationCRLMethod | kSecRevocationRequirePositiveResponse)

// Create trust
var trust: SecTrust?
SecTrustCreateWithCertificates(cert, [basicPolicy, crlPolicy] as CFArray, &trust)

SecTrustSetAnchorCertificates(trust, [rootCert] as CFArray)
SecTrustSetNetworkFetchAllowed(trust, true)

// Evaluate trust
var error: CFError?
guard SecTrustEvaluateWithError(trust, &error) else {
  // Handle error
}

In the above code cert is the certificate I'm checking and rootCert is the root certificate that contains the CRL distribution points.

The error I am getting is:

Error Domain=NSOSStatusErrorDomain Code=-67635 ""<redacted>","<redacted>" certificates do not meet pinning requirements"

Thanks!

Boost

Answer 1

Systems Engineer OP

Apple

Sep ’21

I am developing an app that requires manually checking if a certificate has been revoked via a CRL (certificate revocation list).

My recollection on using kSecRevocationCRLMethod is that it is recommended to use OCSP instead because defining a CRL URL via a server is no longer supported as of 10.15 and it was never supported on iOS.

Now, I suspect that this is not the issue at hand, so regarding:

Is there any way to get around that when you are performing a trust evaluation manually?

When you are performing trust evaluation manually you are asking the system to determine if a set of assets is trusted based on a set of system policies. These policies are documented in articles like the one you are referencing. So if you are asking for the system to loosen their policies here to run SecTrustEvaluateWithError then that is not going to happen. If you need to adhere to requirements that are less strict than the ones the system enforces then you must build this logic yourself.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

0

Answer 2

brucefromfortitude valley OP

Sep ’21

Hi Matt,

Thanks for the reply. For reasons outside of our control we need to use CRLs instead of OCSP unfortunately. Just wanted to check if there was an easy way to do this using the Apple-provided APIs.

We've already implemented an offline file-based CRL check, so implementing a CRL downloading mechanism using the CRL urls embedded in the certificate should be straightforward.

Thanks!

0