I am working on code for the iOS platform to handle connections to servers, handle the trust evaluation, policy management, and general authentication.
During the authentication process, a certificate is evaluated to verify all the certificates are valid back to the anchor certificate. If this passes, the contents of the certificate can be trusted. Next, the trust object checks the certificate against a policy. The two policies I use are the basicX509 and sslServer policies.
( You can generate the policy's keys/values by setting a breakpoint on the following code:
NSString *hostname = @"your.dNS.name";
SecPolicyRef secPolicyRefSSL = SecPolicyCreateSSL(TRUE,(__bridge CFStringRef)hostname);
OSStatus osStatus = SecTrustSetPolicies(secTrustRef, secPolicyRefSSL)
--> if (osStatus != errSecSuccess)
then in the debugger, issue "po secPolicyRefSSL" which displays the description containing oid, name, and options.
The Apple SSL Policy = x509Policy + a few more key value pairs. You can create the basic x509 policy instead of SSL policy to see them.
)
The Apple SSL Policy key value pairs ('options') are as follows:
BasicConstraints = 1;
BlackListedLeaf = 1;
CriticalExtensions = 1;
ExtendedKeyUsage = ( ... )
GrayListedLeaf = 1;
IdLinkage = 1;
KeySize = {42 = 2048;73 = 256;};
NonEmptySubject = 1;
SSLHostname = "hostname";
ServerAuthEKU = 1;
SignatureHashAlgorithms = (SignatureDigestMD2,SignatureDigestMD4,SignatureDigestMD5,SignatureDigestSHA1);
SystemTrustedCTRequired = 1;
TemporalValidity = 1;
ValidityPeriodMaximums = 1;
WeakKeySize = 1;
WeakSignature = 1;
The policy check looks at the key value pairs in the policy and runs those policy requirement checks. If any do not pass, they appear in the SecTrustResultDetails key of the SecTrust object.
So for example, I created a certificate that uses an RSA key size of 512 bits. The policy states it expects a weak key size test to pass as seen with the "WeakKeySize=1" key value pair. This had better fail. And it does, by failing the trust's policy requirements and returning 'WeakKeySize=0".
As another example, I created an 'SSL Server' certificate with a validity period of 5000 days. But, since the policy has 'ValidityPeriodMaximums = 1', the policy runs a test that checks that the maximum of 825 days is not exceeded. It too will fail and return 'ValidityPeriodMaximums = 0'.
I figured out the meaning of and tested most of these with the following exceptions:
IdLinkage
BlackListedLeaf
GrayListedLeaf
SystemTrustedCTRequired
CriticalExtensions
BasicConstraints
Assuming the 'CT' in SystemTrustedCTRequired is for 'Certificate Transparency', I know for a fact that a test server I am using with in-house anchor certificates do not participate in Certifcate Transparency protocols. How can my iOS clients connect to a server when SystemTrustedCTRequired policy is required to pass? It must be doing something else.
Anybody know the meanings of these policy requirements? Any API documentation out there or iOS/macOS header files with these details?
References:
Policy OID definitions
https://opensource.apple.com/source/libsecurity_asn1/libsecurity_asn1-29908/asn1/appleoids.asn
Requirements for trusted certificates in iOS13 and macOS 10.15 (This is the human readable form for some of the key value policy pairs above)
https://support.apple.com/en-us/HT210176
Why does the hostname need to match the dNSName in the certificate? (this is the SSLHostname policy requirement)
from https://tools.ietf.org/html/rfc2818
"Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."
from https://support.apple.com/en-us/HT210176
"TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted."
