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.

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) }

2025-06-09_18-48-03.1721_-0600-43bc27c538c2f93348a83e5380b5f016cc859f71.crash Thanks Quinn! I'm attaching one of the crash logs here. However your pointer got me to the issue - it's a race condition when the device is getting lots of messages over UDP from lots of other disparate devices and those messages are getting split over multiple packets. The completion handler is spinning up a new thread, but working off of the same instance of an underlying class which is where I think the issue is. I was able to replicate it by flooding the device with a bunch of partial messages randomly and could easily reproduce.

Ah yes, great point! I think that's exactly what it was. I had fixed the issue initially by processing in a serial queue, but your comment made me go back and realize the connection group was getting started like this: connectionGroup.start(queue: .global()) Which is, of course, a concurrent queue. With the serial queue in place I was able to flood the device with thousands of UDP messages without issue. Thanks so much!

(For posterity and web searches) One can create a serial queue by using the default initializer for DispatchQueue: private let serialQueue = DispatchQueue(label: "some.custom.label") I'm then initializing the Connection Group like: connectionGroup = NWConnectionGroup(with: multicastGroup!, using: params) and finally starting it with: connectionGroup.start(queue: serialQueue) It's that last line that's super important because the default global() queue will give you a concurrent queue rather than a serial one.

(The code block above in my post is also showing inline completely, so I'm guessing something bigger is going on here with code blocks?)

Thanks Quinn! Glad you all are at least aware of it.