FYI, the workaround was the WKWebViewDelegate equivalent of responding to a URLConnection challenge/response.
Once that was called, check the securityref and if it’s not nil, set the proper trust exceptions. If it is nil, skip that and pass nil to the callback. The webView ends up loading the URL if there is a challenge or not. Matt’s detail about the iOS 14 trusted cert root list piggybacks off of the iOS 13 changes which limit SSL certs to 1 year. These details really help narrow down the many reasons why the certs are no longer valid. Super helpful. I thank you again. Hopefully, this will also help out others who will run into this. Best, and thanks again. Alex Zavatone > On Apr 20, 2021, at 3:32 PM, Alex Zavatone via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > Thanks Matt. A world of good information in there. > > One thing that’s odd though is that we’re issuing an NSURL loadRequest to a > WKWebView. I’d expect that a simple blanket NSAppTransportSecurity allow > arbitrary loads or an allow arbtrary loads in web content would allow the > invalud cert to be bypassed, but the error -1202 is still being caught and > the error of “The certificate for this server is invalid” still gets caught > in a navigation error on the web delegate. > > Any ideas? > > Thanks in advance, > Alex Zavatone > >> On Apr 18, 2021, at 11:54 AM, Matt Eaton <agnostic...@gmail.com> wrote: >> >>> But I’d also like to see what’s wrong with the cert. >> >> If this a certificate that you control then I would recommend trying to take >> a look at how to fix your certificate rather than adding an ATS exception or >> overriding trust evaluation on the client side. This would provide the best >> long term solution. >> >> As to how to solve your problem; "Not Trusted," can stem from a variety of >> issues when a policy is evaluated on the client side. HT211025 and HT210176 >> provide an excellent outline for why a certificate can end up in this state. >> A few things to check: >> >> * Who is the issuer (CA) of the leaf certificate on the server side that is >> being evaluated? Is it an In-House CA or is it a CA that contains a root in >> the device's trust store? <https://support.apple.com/en-us/HT212140 >> <https://support.apple.com/en-us/HT212140>>. The reason why I mention this >> is because certificates that are issued from a CA that has a root in the >> trust store generally fulfill the requirements of outlined by HT211025 and >> HT210176. If the leaf is issued from an In-House CA then a chain of trust >> may not be able to be created during trust evaluation, or one of the other >> requirements may not be getting fulfilled from HT211025 and HT210176 and >> this could be the breakdown. >> >> * If the leaf comes from the CA that contains a root in the trust store then >> check the validity period of the certificate. This can be done by checking >> the "Not Valid Before," and "Not Valid After" time stamps on the certificate >> to see if they fit into the requirements outline by HT211025 and HT210176. >> >> * Is the certificate being trusted via an external CT (Certificate >> Transparency) log or an embedded SCT? This can usually be done with a SCT >> (Signed Certificate Timestamp) embedded in the certificate and then the >> certificate can be evaluated via a TLS extension. Other forms of validation >> include a client making a OCSP request to check the status of the >> certificate from a log operator. These details can be confirmed by looking >> at a packet trace with the certificate in question. >> >> The best way to see what is wrong with the certificate in question is to >> check the certificate details or take a packet trace and review the >> information being exchanged in the client hello / server hello during the >> TLS handshake. This should give you a baseline for what is happening. >> >> If you need to setup test cases for these scenarios, try using BadSSL, >> (<https://badssl.com <https://badssl.com/>>) to test out whether you are >> correctly handling many of the common failures that you can run into when >> evaluating trust. >> >> >>> On Apr 17, 2021, at 1:32 PM, Alex Zavatone via Cocoa-dev >>> <cocoa-dev@lists.apple.com <mailto:cocoa-dev@lists.apple.com>> wrote: >>> >>> I just came across this the other day and now need to do something about >>> it. Am looking to see if anyone else has had to handle this and profit off >>> of the wisdom of those who have suffered through it before. >>> >>> Currently, I’m planning on testing out an NSAPPTransportSecurity exception >>> in the plist on the offending domain. But I’d also like to see what’s >>> wrong with the cert. >>> >>> Will check out the recommendations here too. >>> https://support.apple.com/en-us/HT210176 >>> >>> And the discussion here. >>> https://developer.apple.com/forums/thread/655074?login=true >>> >>> >>> And the notice here. https://support.apple.com/en-us/HT211025 >>> >>> TLS server certificates issued on or after September 1, 2020 00:00 >>> GMT/UTC must not have a validity period greater than 398 days. >>> >>> Connections to TLS servers violating these new requirements will fail. >>> >>> >>> Another question, is there a way to make sure to get these announcements >>> from Apple in emails? Am I the only person who is constantly surprised by >>> these new policies? >>> >>> Thanks in advance. >>> Alex Zavatone >>> >>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> Please do not post admin requests or moderator comments to the list. >>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/agnosticdev%40gmail.com >>> <https://lists.apple.com/mailman/options/cocoa-dev/agnosticdev%40gmail.com> >>> >>> This email sent to agnostic...@gmail.com <mailto:agnostic...@gmail.com> > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
