<div dir="ltr"><div dir="ltr"><div>Complex indeed.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The idea as I understand it is that browsers should<br>see the ISRG Root X1 certificate, realize that it itself is already<br>trusted by the OS or browser, and not even look at the next expired<br><div>DST Root CA X3 certificate in the chain.</div></blockquote><div><br></div><div>This doesn't work sometimes on some clients.  I ran into a problem yesterday where a batch of Polycom VVX phones would no longer register SIP via TLS or pull provisioning via HTTPS, and the root cause (pun intended) was this issue.  Loading the ISRG Root X1 certificate alone didn't solve the problem; the phone still complained the server's cert was expired during the SSL handshake.  To move past it, I had to change the TLS profile on the Polycom to use only the manually loaded CA cert (Platform CA 1) and ignore anything built-in.  And then it was fine.</div><div><br></div><div>I found this site illustrative:  <a href="https://chainchecker.certifytheweb.com/">https://chainchecker.certifytheweb.com/</a>   Pointing it at <a href="http://ag-projects.com">ag-projects.com</a>, or any system using Let's Encrypt, yields the same results:</div><div><br></div><div style="margin-left:40px"><pre id="gmail-results"><p class="gmail-chain-summary"><a href="http://ag-projects.com">ag-projects.com</a> ▶▶ R3 ▶▶ ISRG Root X1 ▶▶ [DST Root CA X3]</p><div class="gmail-legacy-notice"><h3>Let's Encrypt Legacy Chain (Supports older devices)</h3><p>This Let's Encrypt chain includes the expired DST Root CA X3 in order to remain compatible with older operating system such as Android 7.0 and lower.</p></div></pre></div><div><br></div><div>I fear the [DST Root CA X3] cert listed there, the expired one, is going to do more harm than good on many devices, like it did on my Polycom VVXs.  It wouldn't surprise me if Let's Encrypt changes their policy in such a way that no longer includes it.<br></div><div><br></div><div><br></div><div>- Jeff</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 7:16 PM Adrian Georgescu <<a href="mailto:ag@ag-projects.com">ag@ag-projects.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">The complexity of the problem…<br><div><br><blockquote type="cite"><div>Begin forwarded message:</div><br><div style="margin:0px"><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif;color:rgb(0,0,0)"><b>From: </b></span><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif">raf <<a href="mailto:macports@raf.org" target="_blank">macports@raf.org</a>><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif;color:rgb(0,0,0)"><b>Subject: </b></span><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif"><b>Re: Let's Encrypt DST Root CA X3 Expiration</b><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif;color:rgb(0,0,0)"><b>Date: </b></span><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif">2 October 2021 at 23:32:45 GMT-3<br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif;color:rgb(0,0,0)"><b>To: </b></span><span style="font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif"><a href="mailto:macports-users@lists.macports.org" target="_blank">macports-users@lists.macports.org</a><br></span></div><br><div><div>On Sat, Oct 02, 2021 at 04:14:05AM -0500, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>> wrote:<br><br><blockquote type="cite"><a href="http://macports.org" target="_blank">macports.org</a> and other secure web sites that use Let's Encrypt may<br>no longer be accessible to you if you use older versions of macOS<br>or older browsers or user agents. For example, the libcurl in macOS<br>10.14 can't talk to many Let's Encrypt web sites now, including<br><a href="http://distfiles.macports.org" target="_blank">distfiles.macports.org</a> and <a href="http://packages.macports.org" target="_blank">packages.macports.org</a>, and MacPorts uses<br>macOS libcurl to download things. Safari and many browsers don't use<br>libcurl so they may be affected differently.<br><br>Let's Encrypt is a free certificate provider used by <a href="http://macports.org" target="_blank">macports.org</a><br>and many other web sites to provide https encryption. Certificates<br>they issue depend on their "ISRG Root X1" certificate which was<br>cross-signed by the "DST Root CA X3" certificate, because DST Root<br>CA X3 was more widely accepted by browsers when Let's Encrypt got<br>started years ago. Both of these root certificates are included in the<br>certificate chain served by web sites that use Let's Encrypt.<br><br>ISRG Root X1 itself has been trusted by browsers for some time<br>now and DST Root CA X3 expired a couple days ago on September 30,<br>2021. Apparently in order to provide the widest compatibility,<br>certificate chains continue to list the old expired root certificate<br>after the new one. The idea as I understand it is that browsers should<br>see the ISRG Root X1 certificate, realize that it itself is already<br>trusted by the OS or browser, and not even look at the next expired<br>DST Root CA X3 certificate in the chain.<br><br>They advertised this root certificate expiration as being a very minor<br>situation, but unfortunately it seems that a large portion of Apple<br>devices cannot deal with this change. On many Macs, it seems that the<br>entire certificate chain is being validated, and the expired extra<br>root certificate is causing the connection to be disallowed. What<br>alerted me to the problem in the first place was seeing many failed<br>builds on our Buildbot system due to fetch failures.<br><br>I'm not certain what to do to address this. On the web servers<br>we control, we can apparently remove the expired DST Root CA X3<br>certificate from the chain that we send. That will help those<br>systems that already trust ISRG Root X1. I'm not sure how far back<br>that is. For older systems, we can modify master_sites.tcl and<br>archive_sites.tcl to change which OS versions try to access our mirror<br>servers via https. None of this necessarily helps our build server be<br>able to mirror distfiles in the first place. If you have ideas, let me<br>know.<br><br><a href="https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/" target="_blank">https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/</a><br></blockquote><br>There is a discussion on the LetsEncrypt community site<br>with instructions for installing the ISRG Root X1<br>certificate on older versions of macOS:<br><br>  <a href="https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/16" target="_blank">https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/16</a><br><br>Here are instructions for 10.10 and 10.11:<br><br>  <a href="https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/25" target="_blank">https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/25</a><br><br>Here's another approach that worked on 10.9.5 and<br>10.11.6 (i.e., override the expiry by always trusting<br>DST Root CA X3:<br><br>  <a href="https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/28" target="_blank">https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/28</a><br><br>Here's my approach for 10.6.8 because the above didn't<br>work (i.e., export root certificates from a later macOS<br>and import them):<br><br>  <a href="https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/36" target="_blank">https://community.letsencrypt.org/t/connection-errors-on-apple-devices/161107/36</a><br><br>But these are all client-side fixes. The only<br>server-side fix seems to be to change to a different<br>certificate authority. I didn't see any mention of<br>removing the DST Root CA X3 certificate from the chain.<br>That would probably only work from macOS 10.12 onwards.<br>ISRG Root X1 is only trusted by macOS since 10.12.<br>Earlier than that, it needs to be added.<br><br>The rest is a bit rambly. It might be best to just<br>consult the LetsEncrypt community forum above.<br><br>I should mention that I didn't notice any problems with<br>macports on 10.6.8. curl has its own root certificates<br>and they are fine. And I was able to do an upgrade. But<br>I might have already installed the ISRG Root X1<br>certificate at least into my "local" keychain before<br>trying it (or maybe into the "System" and "System<br>Roots" keychains).<br><br>However, I still don't think that it's entirely OK.<br>Firefox on 10.6.8 can access <a href="http://macports.org" target="_blank">macports.org</a> with no<br>problem (but it certainly wasn't accessing my<br>LetsEncrypt-certified sites beforehand), but Sarafi<br>tells me that it can't verify <a href="http://macports.org" target="_blank">macports.org</a>'s identity,<br>but it still lets me access it. If I quit and restart<br>Safari, and visit <a href="http://macports.org" target="_blank">macports.org</a>, it does the same thing.<br>Firefox uses its own root certificates. Safari uses the<br>system ones. But I definitely have ISRG Root X1 in both<br>the "System" and "System Roots" keychains. So I don't<br>know why Safari has a problem. In Keychain Access, it's<br>marked as "Always Trust" but it also says "trusted for<br><a href="http://macports.org" target="_blank">macports.org</a>" (I don't know why it says that). That's<br>confusing. But in Safari, when viewing the certificate,<br>there was a checkbox labelled "Always trust". After<br>checking it, quitting and restarting Safari, it visited<br><a href="http://macports.org" target="_blank">macports.org</a> without complaint.<br><br>I should also mention that I can't find DST Root CA X3<br>in my 10.6.8 keychains. So that's wierd. Otherwise, I<br>probably should have set it to always trust (not that<br>having ISRG Root X1 set to always trust convinced<br>Safari to trust it immediately - I had to tell Safari<br>itself to trust it as well).<br><br>cheers,<br>raf<br><br></div></div></blockquote></div>
</div></blockquote></div></div>