[quote='802048022, DTS Engineer, /thread/751750?answerId=802048022#802048022'] Please reply as a reply, rather than in the comments. [/quote] Understood, thanks for the reminder! I'll give this scenario a shot with URLSession. Actually pgalisz1 will be taking over in this area for me, so he'll be updating the prototype. I'm happy to remain the POC for this issue to keep things consistent, but Piotr may be chiming in with details.

Hi Quinn, thanks for the reply. I tried it on an iPhone SE 3rd gen running iOS 17.6.1 and got the same results. Specifically these log messages: -[ViewController viewDidLoad] -[ViewController webView:didStartProvisionalNavigation:] 0x152019018 - [pageProxyID=7, webPageID=8, PID=865] WebPageProxy::didFailProvisionalLoadForFrame: frameID=1, isMainFrame=1, domain=NSURLErrorDomain, code=-1206, isMainFrame=1, willInternallyHandleFailure=0 -[ViewController webView:didFailProvisionalNavigation:withError:]. Error Error Domain=NSURLErrorDomain Code=-1206 "The server “api.ipify.org” requires a client certificate." UserInfo={NSErrorFailingURLKey=https://api.ipify.org/, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <93E83F6C-8958-44A7-9F3D-A9BBBE4585E7>.<2>, _kCFStreamErrorDomainKey=3, networkTaskMetricsPrivacyStance=Unknown, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <93E83F6C-8958-44A7-9F3D-A9BBBE4585E7>.<2>" ), NSLocalizedDescription=The server “api.ipify.org” requires a client certificate., _WKRecoveryAttempterErrorKey=<WKReloadFrameErrorRecoveryAttempter: 0x3004dc080>, networkTaskDescription=LocalDataTask <93E83F6C-8958-44A7-9F3D-A9BBBE4585E7>.<2>, NSErrorFailingURLStringKey=https://api.ipify.org/, NSUnderlyingError=0x300af5020 {Error Domain=kCFErrorDomainCFNetwork Code=-1206 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9829, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9829}}, _kCFStreamErrorCodeKey=-9829} If I try again without using a proxy (instead navigating directly to a site that requires mTLS), I see the expected log output: -[ViewController viewDidLoad] -[ViewController webView:didStartProvisionalNavigation:] -[ViewController webView:didReceiveAuthenticationChallenge:completionHandler:] protection space: NSURLAuthenticationMethodServerTrust -[ViewController webView:didReceiveAuthenticationChallenge:completionHandler:] protection space: NSURLAuthenticationMethodClientCertificate

I'm having the same issue with the sec_protocol_options_set_challenge_block API as well. It seems the provided block does not run.

Thank you for your help Quinn, your most recent reply put me on the right path. While the code is in the main executable, something is going wrong during the signing process. I found this article which shares some Swift code that lets you query for entitlements at runtime: https://developer.apple.com/documentation/Xcode/signing-a-daemon-with-a-restricted-entitlement Once converted to Obj-C, I could see that I didn't have any entitlements at all. Even in the main function of the app, there were no entitlements. It's odd to me that codesign reports the correct entitlements for the .app file, but they aren't present at runtime. I'm fiddling with our signing script now, and am finally seeing success. Thanks again for your help!

I'm signing using a modified version of a script that comes with Chromium which uses codesign for signing. Is there some configuration that was missed that should cause this entitlement to be included? I tried to add the entitlement manually, but it didn't seem to have an effect (still seeing -34018). As for the local test app, not much seems different, it does have the team-identifier entitlement you mentioned. This is from the exported, notarized archive of my test app, which shares the same name as the Browser app, so the same provisioning profile would work: [Dict] [Key] com.apple.application-identifier [Value] [String] TL6P21MQR.com.contoso.browser [Key] com.apple.developer.team-identifier [Value] [String] TL6P21MQR [Key] keychain-access-groups [Value] [Array] [String] TL6P21MQR.keychain

Thanks for the response, Quinn. I believe my app has the com.apple.application-identifier entitlement, and so does the provisioning profile, but I could be wrong as the code works in a small test app in Xcode. Is there a way to check that this entitlement is present in the signed and notarized app? I've been running the following commands, which lead me to believe that we have the entitlement and proper authorization. % codesign -d --entitlements - Browser.app returns Executable=/Applications/Browser.app/Contents/MacOS/Browser [Dict] [Key] com.apple.application-identifier [Value] [String] TL6P21MQR.com.contoso.browser [Key] keychain-access-groups [Value] [Array] [String] TL6P21MQR.com.contoso.browser.devicetrust [String] TL6P21MQR.com.contoso.browser.webauthn Inside of Browser.app I see the embedded.provisionprofile and looking in the DER encoded profile with these commands % security cms -D -i embedded.provisionprofile -o Browser-payload.plist % plutil -extract DER-Encoded-Profile raw -o - Browser-payload.plist | base64 -D > Browser.der % security cms -D -i Browser.der -o Browser-payload.der % openssl asn1parse -in Browser-payload.der -inform der -i | cut -c 30- Shows that the application-identifer entitlement is authorized by the provision profile, here are the seemingly relevant pieces of the output: SET SEQUENCE UTF8STRING :Version INTEGER :01 ... SEQUENCE UTF8STRING :TeamIdentifier SEQUENCE UTF8STRING :TL6P21MQR ... SEQUENCE UTF8STRING :ApplicationIdentifierPrefix SEQUENCE UTF8STRING :TL6P21MQR ... SEQUENCE UTF8STRING :Entitlements appl [ 16 ] INTEGER :01 cont [ 16 ] SEQUENCE UTF8STRING :com.apple.application-identifier UTF8STRING :TL6P21MQR.com.contoso.browser SEQUENCE UTF8STRING :com.apple.developer.team-identifier UTF8STRING :TL6P21MQR SEQUENCE UTF8STRING :keychain-access-groups SEQUENCE UTF8STRING :TL6P21MQR.* It seems to me like everything is in order, or am I missing something? Let me know if I left out any important details, and thanks again for your help.