I'm working on a project that says it's to be based on the QNE2TransparentProxyMac sample code but don't have the original sample code. Can I get a pointer to the sample code and documentation please? Google search didn't find it for some reason. Thanks! Peter

With my UDP Flow Copier working as demonstrated by the fact that it is proxying DNS traffic successfully, I am finally writing tests to verify UDP packet filtering. I'm sending packets to a public UDP echo server and reading the response successfully. In my initial testing however the TransparentProxyProvider System Extension is not intercepting my UDP traffic. handleNewUDPFlow() is being called for DNS but not for my test case UDP echo sends and receives. I've tried sending UDP with both GCDAsyncSocket and NWConnection as: connection = NWConnection(host: host, port: port, using: .udp) Is there some other criteria for UDP datagrams to be intercepted? Google search suggests this might be a known issue for connected or async UDP sockets.

I’m working on a product that includes TLS inspection capability. TLS inspection using a local MitM requires installing a trusted root certificate which is then used to create masquerade certificates to intercept and forward TLS traffic through the proxy. For manual installation the end user is required to authenticate as an administrator to modify the trust settings on our internal CA’s root certificate. My question concerns the options for enterprise deployment using an MDM. We want the generated root certificate to be unique to each endpoint so that if a private key is compromised it can’t be used to intercept traffic anywhere else. We can install a “certificate trust” configuration profile from the MDM but this requires a base64 encoded string of the root certificate. In effect the MDM needs to obtain the certificate from the endpoint and then send it back in the form of a configuration profile. I’m not aware that MDMs like Jamf can be configured to do this directly so we’re looking for any other mechanism to have macOS trust a locally generated certificate via MDM based on some non endpoint-unique criteria? One option might be to use an external CA with a trusted certificate to sign an intermediate endpoint certificate but this creates a significant risk if the external trusted certificate were ever compromised. Is this a common industry practice? So my question remains is there a better way to trust our per endpoint root certificate via MDM without needing to install a unique per endpoint configuration profile?

I’m facing the dreaded codesign command fails with 'errSecInternalComponent' and looking for some guidance. I have removed the “Apple World Wide Developer Relations Authority” certificate that expired in 2023 from both the Login and System Keychain and have downloaded the latest intermediate certificates I found. I have verified all the Trust Settings are configured to “Use System Default”. I did the basic codesign check suggested in an earlier post [https://forums.developer.apple.com/forums/thread/712005]: % security find-identity -p codesigning Policy: Code Signing Matching identities 675CE18312BFBE2735918BA897908D20DB0A774D "Apple Development: Peter Sichel (537G2NTM55)" 1 identities found Valid identities only 675CE18312BFBE2735918BA897908D20DB0A774D "Apple Development: Peter Sichel (537G2NTM55)" 1 valid identities found % cp "/usr/bin/true" "MyTrue" % codesign -s "Apple Development" -f "MyTrue" MyTrue: replacing existing signature MyTrue: errSecInternalComponent —— It seems I’m still missing something. What else can I check to debug the problem?