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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
