With Let's Encrypt having completely dropped support for OCSP recently [1], I wanted to ask if macOS has a means of keeping up to date with their CRLs and if so, roughly how often this occurs? I first observed an issue where a revoked-certificate test site, "revoked.badssl.com" (cert signed by Let's Encrypt), was not getting blocked on any browser, when a revocation policy was set up using the SecPolicyCreateRevocation API, in tandem with the kSecRevocationUseAnyAvailableMethod and kSecRevocationPreferCRL flags. After further investigation, I noticed that even on a fresh install of macOS, Safari does not block this test website, while Chrome and Firefox (usually) do, due to its revoked certificate. Chrome and Firefox both have their own means of dealing with CRLs, while I assume Safari uses the system Keychain and APIs. I checked cert info for the site here [2]. It was issued on 2025-07-01 20:00 and revoked an hour later. [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=revoked.badssl.com

I was having a look through the documentation for NEPacketTunnelProvider, and wanted to know if it's possible for startTunnel(..) and stopTunnel(..) to run simultaneously, and thus require synchronization between resources they deal with? For example, if the VPN is toggled rapidly from system settings, could the setup that occurs in my startTunnel() definition (class instantiation and setTunnelNetworkSettings(value)) potentially occur after the tear-down logic (resource cleanup, setTunnelNetworkSettings(nil)), leaving the system in a state where the VPN is deactivated, but the configuration is in place?

I have an NEPacketTunnelProvider that's configured using NEPacketTunnelNetworkSettings. I'm using NEDNSSettings to configure the DNS resolver of the packet tunnel, and would like to specify the exact domains that should use this resolver using the matchDomains member variable. While it's not explicitly mentioned in the documentation [1], I've noticed that if a domain is present in matchDomains, then all subdomains of it will also be resolved using this resolver, as if a wildcard match rule is in place. I wanted to ask if this the intended behavior, and if so, is there any way to disable it so that only exact domain matches will be resolved? I.e., if "example.com" is in the matchDomains list, I would like requests for this domain be resolved using the configured DNS resolver, while ignoring requests to the subdomain"test.example.com". [1] https://developer.apple.com/documentation/networkextension/nednssettings/matchdomains

While analyzing iCloud Private Relay traffic using my App's content filter (based on NEFilterDataProvider), I noticed a couple of items that piqued my curiosity and wanted to see if I could get more information here. Namely, when accessing a HTTP site via iCloud Private Relay, there is an initial flow established to UDP port 80 and an unspecified IPv6 address (i.e, '::'). This seemed odd for a few reasons: IPv6 is disabled on the system and the site I'm connecting with only has an IPv4 address. Also, the unspecified IPv6 address seems strange in general. In the documentation, iCloud Private Relay claims to only use UDP port 443 [1][2]. Could you provide more clarity on how this works in the background? Would it also be possible to confirm whether UDP port 80 should be included in any filtering logic concerning iCloud Private Relay? Note: in case this isn't the general behavior for iCloud Private Relay, I wanted to further clarify that this is the behavior I've seen in Safari 17 on Sonoma and Sequoia, when accessing websites via HTTP, with Safari's "Use advanced tracking and fingerprinting protection" enabled. Thanks! [1] https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay [2] https://support.apple.com/en-ca/101555