Certificate exceeds maximum temporal validity period

So I'm reminded I could inspect the CFError and set individual policies, for example we ignore Hostname policies when using custom certificates:

let sslWithoutHostnamePolicy = SecPolicyCreateSSL(true, nil)
SecTrustSetPolicies(secTrust, [sslWithoutHostnamePolicy] as CFArray)
SecTrustSetAnchorCertificates(secTrust, customCerts as CFArray)
SecTrustSetAnchorCertificatesOnly(secTrust, false)

So if there's a policy we could use for validity to disable that check, I'm definitely OK with that as a workaround.

AFAIK the limits described in About upcoming limits on trusted certificates still apply. You can see the code that applies this in Darwin [1].

I take it that you can reproduce this issue reliably. If so, do that while monitoring the system log for leaf validity period. What do you see?

If you’re unfamiliar with the system log, see Your Friend the System Log.

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

[1] With the usual caveat that the Darwin open source is not always 100% exactly the same as the code running in any given build of macOS, iOS, or whatever.

Thanks as always Quinn! In running Console I don't see any specific messages about leaf validity period, only these two messages.

I have opened a support request already that has the domain we're attaching to when experiencing the issue if that's helpful. As far as we can tell these certificates meet all of the requirements from that article - for example, it's only trusted for 394 days, not expired, etc. These aren't self-signed, but root-trusted certificates. Happy to dig in more if there's something else I can provide!

Here's the full code block where we're validating the certificates. Effectively we're given the certificate chain and we attempt initially to validate without it against the standard installed certs, and then add the custom ones and try again (ignoring hostname for custom certs). It's in the second verification that it's failing solely because of the temporal validity issue:

sec_protocol_options_set_verify_block(securityOptions, { (_, trust, completionHandler) in
    self.logger.debug("Entering Verify Block")
    
    let secTrust = sec_trust_copy_ref(trust).takeRetainedValue()
    isValidCertificate = SecTrustEvaluateWithError(secTrust, &error)
    
    if !isValidCertificate {
        self.logger.debug("Server not trusted with default certs, seeing if we have custom ones")
        var customCerts: [SecCertificate] = []
        
        let trustCerts = SettingsStore.global.serverCertificateTruststore
        self.logger.debug("Truststore contains \(trustCerts.count) cert(s)")
        if !trustCerts.isEmpty {
            self.logger.debug("Trusting Trust Store Certs")
            trustCerts.forEach { cert in
                if let convertedCert = SecCertificateCreateWithData(nil, cert as CFData) {
                    customCerts.append(convertedCert)
                }
            }
        }
        
        if !customCerts.isEmpty {
            // Disable hostname validation if using custom certs
            let sslWithoutHostnamePolicy = SecPolicyCreateSSL(true, nil)
            
            SecTrustSetPolicies(secTrust, [sslWithoutHostnamePolicy] as CFArray)
            SecTrustSetAnchorCertificates(secTrust, customCerts as CFArray)
        }
        
        // Make sure we still trust our normal root certificates
        SecTrustSetAnchorCertificatesOnly(secTrust, false)
        
        // Try again
        isValidCertificate = SecTrustEvaluateWithError(secTrust, &error)
        
        if let error {
            self.logger.error("SecTrustEvaluate failed with error: \(error)")
        }
    }

    completionHandler(isValidCertificate)
}, .global())

@DTS Engineer We're starting to run into this more and more as we're getting clients using root certs from after the 2020 cut-off date. What I'm baffled by is that in the Darwin code there's this: Don't check validity periods against maximums for user-anchored leafs

In the above code I've got the certificates I want to trust, which are for all intents and purposes self-signed certificates. Do I need to flag somehow that these aren't the system root certificates for this to work?

FWIW, if I do this I work around I can get it to pass, but I don't like it mainly because I don't know what other exceptions might be caught up in this

if error != nil && error.debugDescription.contains("not standards compliant") {
    let errDataRef = SecTrustCopyExceptions(secTrust)
    SecTrustSetExceptions(secTrust, errDataRef)
    isValidCertificate = SecTrustEvaluateWithError(secTrust, &error)
}

For those reading along at home, FT-cfoy shared their certificates with me via a code-level support request.

There are a number of issues with these certificates )-:

Your leaf certificate has a Basic Constraints extension where it doesn’t need one:

% dumpasn1 -p cert1.cer 
SEQUENCE {
  SEQUENCE {
    …
    [3] {
      SEQUENCE {
        SEQUENCE {
          OBJECT IDENTIFIER basicConstraints (2 5 29 19)
          BOOLEAN TRUE
          OCTET STRING, encapsulates {
            SEQUENCE {}
            }
          }
        …
        }
      }
    }
  …
  }

That’s not a showstopper, but it’s certainly weird.

Your leaf certificate Extended Key Usage supports both TLS client and server:

% dumpasn1 -p cert1.cer 
SEQUENCE {
  SEQUENCE {
    …
    [3] {
      SEQUENCE {
        …
        SEQUENCE {
          OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
          BOOLEAN TRUE
          OCTET STRING, encapsulates {
            SEQUENCE {
              OBJECT IDENTIFIER clientAuth (1 3 6 1 5 5 7 3 2)
              OBJECT IDENTIFIER serverAuth (1 3 6 1 5 5 7 3 1)
              }
            }
          }
        }
      }
    }
  …
  }

Again, not a showstopper, but almost never what you want.

Your certificate serial numbers don’t follow current recommendations:

% dumpasn1 -p cert1.cer 
SEQUENCE {
  SEQUENCE {
    …
    INTEGER 25864
    …
    }
  …
  }

These days serial numbers are meant to be large random values.

Again, not a showstopper.

Your leaf certificate is missing its Subject Alternative Name extension. This is a showstopper. Historically it was OK to put the server DNS name in the Common Name field of the Subject, but that’s not been recommended for decades [1] and Apple’s OSes now require that you list the server DNS name in a Subject Alternative Name extension.

This explains the SSL hostname does not match name(s) in certificate error you’re seeing.

And then there’s those Certificate exceeds maximum temporal validity period errors. And it’s not wrong:

% dumpasn1 -p cert1.cer 
SEQUENCE {
  SEQUENCE {
    …
    SEQUENCE {
      UTCTime 01/02/2023 21:24:11 GMT
      UTCTime 30/01/2030 21:24:11 GMT
      }
    …
    }
  …
  }

That’s roughly 7 years. Yowsers!

Earlier I pointed you at About upcoming limits on trusted certificates, which lists a 398 day limit. However, there’s also Requirements for trusted certificates in iOS 13 and macOS 10.15, which lists a 825 day limit. The first limit isn’t applied to custom CAs but the second limit it.

Note I link to both of these in Networking Resources, which is a good page to bookmark (-:

At this point I think you need to have a chat with the folks running your CA. They need to invest some time in updating their policies. You might want to introduce them to RFC 5280 and its more recent updates.

Note that iOS 13, where that 825 day limit was introduced, is now 5 years old.

As to a workaround that you can apply immediately, you wrote:

I don't like it mainly because I don't know what other exceptions might be caught up in this

I don’t like it either, for the same reasons.

What I suggest you do is:

1. Run a basic X.509 trust evaluation on the certificate just, to confirm that things are vaguely OK.

2. Pin that to your CA’s root, because you don’t want certificates issued by other CA’s taking advantage of your security exception.

3. Confirm the leaf name matches your expectations.

Here’s how I tested this with the certificates you sent me:

let leaf: SecCertificate = Bundle.main.certificateNamed("cert1")!
let intermediate: SecCertificate = Bundle.main.certificateNamed("cert2")!
let root: SecCertificate = Bundle.main.certificateNamed("cert3")!

let leafName = try secCall { SecCertificateCopyCommonName(leaf, $0) } as String

let policy = SecPolicyCreateBasicX509()
let trust = try secCall { SecTrustCreateWithCertificates([leaf, intermediate] as NSArray, policy, $0) }
try secCall { SecTrustSetAnchorCertificates(trust, [root] as NSArray) }
// The following is redundant given the documentation semantics of
// `SecTrustSetAnchorCertificates`, but we’re making a point here.
try secCall { SecTrustSetAnchorCertificatesOnly(trust, true) }
SecTrustEvaluateAsyncWithError(trust, .main) { trust, isTrusted, errorCF in
    guard isTrusted else {
        print("NG, basic X.509")
        return
    }
    guard leafName == "… host name redacted …" else {
        print("NG, leaf name")
        return
    }
    print("OK")
}

This is using the secCall(…) helpers from here and the bundle extension shown below.

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

[1] See RFC 2818.

extension Bundle {
    
    func certificateNamed(_ name: String) -> SecCertificate? {
        guard
            let certURL = self.url(forResource: name, withExtension: "cer"),
            let certData = try? Data(contentsOf: certURL),
            let cert = SecCertificateCreateWithData(nil, certData as NSData)
        else {
            return nil
        }
        return cert
    }
}