Changes between Version 155 and Version 156 of ProblemHotlist


Ignore:
Timestamp:
Oct 3, 2021, 2:38:50 AM (3 weeks ago)
Author:
ryandesign (Ryan Schmidt)
Comment:

Add info about Let's Encrypt root certificate expiration

Legend:

Unmodified
Added
Removed
Modified
  • ProblemHotlist

    v155 v156  
    22
    33[[PageOutline(1-3,Table of Contents,inline)]]
     4
     5== Certificate expired messages when accessing web sites encrypted by Let's Encrypt certificates == #letsencrypt
     6
     7[https://letsencrypt.org Let's Encrypt] is a popular free service that MacPorts and others use to obtain certificates to encrypt their web sites. Certificates they issue are signed by the ISRG Root X1 certificate authority. When the service got started in 2015, no web browser or operating system knew about it and would not have trusted these certificates, so they cross-signed the ISRG Root X1 certificate using DST Root CA X3, a trusted certificate authority already preinstalled in operating systems and browsers at that time. In the meantime, a version of the ISRG Root X1 certificate that has not been cross-signed by DST Root CA X3 has been included in modern browsers and operating systems. On September 30, 2021, DST Root CA X3 expired. As a result, older operating systems and browsers (and other user agents that use networking facilities provided by the OS, such as MacPorts when it downloads files) can no longer verify the trust of sites encrypted using Let's Encrypt.
     8
     9Users of older software can and probably should manually fix their computers to allow access to Let's Encrypt web sites by downloading the new ISRG Root X1 certificate and installing it in their certificate bundle.
     10
     11/usr/bin/curl and Safari use the operating system's keychain as their certificate bundle, and on macOS 10.15 and later and on macOS 10.12, no fixes appear to be needed. On OS X 10.11 and earlier, perform these steps:
     12
     13* Visit this URL which will download the ISRG Root X1 certificate: http://x1.i.lencr.org
     14* Open the Keychain Access app by searching for it using Spotlight or LaunchPad or use the Finder to navigate to the Utilities folder of your disk's Applications folder.
     15* From the list of keychains in the upper left pane of that window, select System.
     16* Drag the x1.i.lencr.org file (from your Downloads folder, Desktop, or wherever your browser downloaded it to) anywhere into the list of certificates at the right of the Keychain Access window.
     17* On Mac OS X 10.7 and earlier:
     18 * A sheet drops down asking if you would like to trust the certificate.
     19 * Click the Always Trust button.
     20 * Enter your administrator username and password.
     21* On OS X 10.8 and later:
     22 * Enter your administrator username and password to allow the certificate to be added to the keychain.
     23 * Locate the certificate in the list of certificates. If you can't see it, type x1 into the search box at the upper right of the Keychain Access window.
     24 * Double-click the certificate in the list to open its window.
     25 * It will show that "This certificate is not trusted."
     26 * Disclose the Trust section by clicking the disclosure triangle next to the word Trust so that the triangle points down.
     27 * On the first line item which reads "When using this certificate", change "Use System Defaults" to "Always Trust".
     28 * Close the window and enter your administrator username and password to allow the change to be made.
     29 * If the certificate still shows as untrusted in the main Keychain Access window, that's just because the list hasn't refreshed. If you'd like to confirm that the certificate is now trusted, re-enter x1 into the search box.
     30* Quit Keychain Access.
     31* Open Safari and verify that you can now access https://build.macports.org
     32
     33The above seems to fix /usr/bin/curl and Safari on OS X 10.8, 10.9, 10.10, and 10.11.
     34
     35With /usr/bin/curl on macOS 10.13 and 10.14, and with /usr/bin/curl and Safari Mac OS X 10.7 and earlier, there is an additional problem. Let's Encrypt currently recommends that web server administrators serve a full certificate chain containing three certificates: the web site's own certificate issued by Let's Encrypt (R3), the R3 certificate issued by ISRG Root X1, and the ISRG Root X1 certificate issued by DST Root CA X3, and the certbot software by default produces this kind of full chain. The intention is that browsers evaluating this chain will stop at the second certificate, recognizing that it is signed by ISRG Root X1 which is already in the trusted certificate bundle. But on these OS versions, the entire chain gets evaluated, including the ISRG Root X1 certificate cross-signed by DST Root CA X3, and the expiration of DST Root CA X3 causes certificate validation to fail. To fix this, web server administrators should edit the full chain file and remove the third (last) entry: the one for DST Root CA X3, and when they renew their certificate with certbot in the future, they should use the flag `--preferred-chain "ISRG Root X1"`. We'll be making this change on the MacPorts servers that we control, but you might have to contact the owners of other web sites and ask them to make this change.
     36
     37If you use other software (such as Chrome, Firefox, or other third party web browsers) that uses its own certificate bundle rather than the keychain, check for an updated version of that software. [https://support.mozilla.org/en-US/kb/switch-to-firefox-extended-support-release-esr Firefox offers an Extended Support Release]. If no update is available for your OS version, you'll have to install the new ISRG Root X1 certificate in that software's certificate bundle, wherever it might be.
     38
     39/opt/local/bin/curl and some other software installed by MacPorts uses a certificate bundle provided by the curl-ca-bundle port which is already fixed.
    440
    541== Incorrect version of Xcode selected == #xcode-select