On Sat, May 30, 2020 at 11:40 PM Duncan Murdoch <murdoch.duncan at gmail.com> wrote:> > On 30/05/2020 5:23 p.m., Bob Rudis wrote: > > I've updated the dashboard (https://rud.is/r-project-cert-status/) > > script and my notifier script to account for the entire chain in each > > cert. > > You never posted which certificate has expired. Your dashboard shows > they're all valid, but the download still fails, presumably because > something not shown has expired.To see the problem in R: certs <- openssl::download_ssl_cert('cran.r-project.org') as.list(certs[[3]]) Shows the root cert expires today.> Hopefully someone who can actually act on this can figure out what needs > doing.The apache server will have a config entry SSLCertificateFile which points to a cert bundle (in nginx servers this is called "ssl_certificate"). If you open this in a text editor it contains the 3 certs, in PEM format, so 3 entires like this: -----BEGIN CERTIFICATE----- [base64 cert] -----END CERTIFICATE----- What you need to do is replace the final certificate with this one (just copy-paste the base64 cert): https://crt.sh/?d=1720081 .Then restart the server. See here for details: https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 . This site talks about "For business processes that depend on very old systems...." but the reality is that this affects everything that uses openssl for https, including curl, svn, etc.
On Sat, May 30, 2020 at 11:02 PM Jeroen Ooms <jeroen at berkeley.edu> wrote: [...]> > What you need to do is replace the final certificate with this one > (just copy-paste the base64 cert): https://crt.sh/?d=1720081 .Then > restart the server.You can also export this from Keychain Access on macOS, btw. find "COMODO RSA Certification Authority" and right click, export, PEM format.> See here for details: > https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 > . This site talks about "For business processes that depend on very > old systems...." but the reality is that this affects everything that > uses openssl for https, including curl, svn, etc.Btw. why does this affect openssl? That root cert was published in 2010, surely openssl should know about it? Maybe libcurl / openssl only uses the chain provided by the server? Without trying to use an alternate chain? Gabor
On Sat, May 30, 2020 at 11:32 PM G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: [...]> Btw. why does this affect openssl? That root cert was published in > 2010, surely openssl should know about it? Maybe libcurl / openssl > only uses the chain provided by the server? Without trying to use an > alternate chain?Yes, indeed it seems that old OpenSSL versions cannot handle alternative certificate chains. This has been fixed in OpenSSL in 2015, so modern Linux systems should be fine. However, macOS uses LibreSSL, and LibreSSL never fixed this issue. E.g. https://github.com/libressl-portable/portable/issues/595 r-project.org can be updated to send the new root certificate, which will solve most of our problems, but we'll probably have issues with other web sites that'll update slower or never. FWIW I built macOS binaries for the curl package, using a static libcurl and macOS Secure Transport, so these binaries does not have this issue. They are at https://files.r-hub.io/curl-macos-static and they can be installed with install.packages("curl", repos "https://files.r-hub.io/curl-macos-static", type = "binary") They support R 3.2 and up, including R 4.1, and should work on all macOS versions that the given R release supports. Gabor