> 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>. 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>) 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> 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 > > This email sent to 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
