Re: [Rd] r-project.org SSL certificate issues
Translation subdomain is also expired.
https://rud.is/r-project-cert-status/
> On Aug 19, 2020, at 13:35, Toby Hocking wrote:
>
> Hi win-builder certificate expired on Aug 15. My student on the other side
> of the world is also seeing this problem so I think it needs to be fixed...
>> download.file("https://win-builder.r-project.org;, "/tmp/wb.html")
> trying URL 'https://win-builder.r-project.org'
> Error in download.file("https://win-builder.r-project.org;, "/tmp/wb.html")
> :
> cannot open URL 'https://win-builder.r-project.org'
> In addition: Warning message:
> In download.file("https://win-builder.r-project.org;, "/tmp/wb.html") :
> URL 'https://win-builder.r-project.org/': status was 'Peer certificate
> cannot be authenticated with given CA certificates'
>>
>
> On Wed, Jun 10, 2020 at 2:40 AM Gábor Csárdi wrote:
>
>> My (also not expert) understanding is that there is nothing insecure about
>> alternative certificate chains at all. All browsers and macOS's built in
>> SSL library (secure transport) support them properly. OpenSSL and LibreSSL
>> were/are simply broken. This was not such a big issue so far, but now that
>> some old long lived certificates are expiring, it is increasingly an issue.
>>
>> FWIW it is possible to build libcurl on macOS without any external SSL
>> library, so OpenSSL and LibreSSL are not needed at all. (Unfortunately the
>> libcurl build that comes with most (all?) macOS versions does use
>> LibreSSL.) The R installer could link to such a static libcurl library on
>> macOS, and that would solve the issue for macOS. Whether it should, that's
>> another question.
>>
>> Gabor
>>
>> On Wed, Jun 10, 2020 at 9:56 AM peter dalgaard wrote:
>>
>>> As I said, there is stuff that I don't understand in here (including
>>> why browsers apparently do trust alternative chains)
>>>
>>> -pd
>>>
On 10 Jun 2020, at 01:53 , Simon Urbanek
>>> wrote:
You are making a very strong assumption that finding an alternative
>>> chain of trust is safe. I'd argue it's not - it means that an adversary
>>> could manipulate the chain in a way to trust it instead of the declared
>>> chain and thus subverting it. In fact switching to OpenSSL would create a
>>> serious security hole here - in particular since it installs a separate
>>> trust store which it is far more easily attacked and subverted. By your
>>> argument we should disable all SSL checks as that produces error with
>>> incorrectly configured servers so not performing checks is better. It is
>>> true that R is likely not used for sensitive transactions, but I would
>>> rather it warned me about situations where the communication may be
>>> compromised instead of just silently going along.
Cheers,
Simon
> On Jun 10, 2020, at 11:39 AM, peter dalgaard
>> wrote:
>
> Yes and no... At least as I understand it (Disclaimer: There are
>> things
>>> I am pretty sure that I don't understand properly, somewhere in the
>> Bermuda
>>> triangle beween CA bundles, TLS protocols, and Server-side settings),
>> there
>>> are two sided to this:
>
> One is that various *.r-project.org servers got hit by a fumble where
>>> a higher-up certificate in the chain of trust expired before the *.
>>> r-project.org one. This was fixed by changing the certificate chain on
>>> each server.
>
> The other side is that this situation hit Mac users harder than
>> others,
>>> because Apple's LibreSSL doesn't have the same feature that openSSL has
>> to
>>> detect a secondary chain of trust when the primary one expired. This was
>>> not unique to R - svn also failed from the command line - but it did
>> affect
>>> download.file() inside R.
>
> The upshot is that there might be 3rd party servers with a similar
>>> certificate setup which have not been updated like *.r-project.org. This
>>> is not too unlikely since web browsers do not have trouble accessing
>> them,
>>> and the whole matter may go undetected. For such servers, download.file()
>>> would still fail.
>
> I.e., there is a case to be made that we might want to link openSSL
>>> rather than LibreSSL. On the other hand, I gather that newer versions of
>>> LibreSSL contain the relevant protocol upgrade, so maybe one can just
>> wait
>>> for Apple to update it. Or maybe we do want to link R against openSSL,
>> but
>>> almost certainly not for a hotfix release.
>
> Best
> -pd
>
>> On 10 Jun 2020, at 00:50 , Simon Urbanek >>
>>> wrote:
>>
>> To be clear, this not an issue in the libraries nor R, the
>>> certificates on the server were simply wrong. So, no, this has nothing to
>>> do with R.
>>
>> Cheers,
>> Simon
>>
>>
>>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson <
>>> henrik.bengts...@gmail.com> wrote:
>>>
>>> Was this resolved upstream or is this something that R should/could
>>> fix? If the latter, could this also go into the
Re: [Rd] r-project.org SSL certificate issues
Hi win-builder certificate expired on Aug 15. My student on the other side
of the world is also seeing this problem so I think it needs to be fixed...
> download.file("https://win-builder.r-project.org;, "/tmp/wb.html")
trying URL 'https://win-builder.r-project.org'
Error in download.file("https://win-builder.r-project.org;, "/tmp/wb.html")
:
cannot open URL 'https://win-builder.r-project.org'
In addition: Warning message:
In download.file("https://win-builder.r-project.org;, "/tmp/wb.html") :
URL 'https://win-builder.r-project.org/': status was 'Peer certificate
cannot be authenticated with given CA certificates'
>
On Wed, Jun 10, 2020 at 2:40 AM Gábor Csárdi wrote:
> My (also not expert) understanding is that there is nothing insecure about
> alternative certificate chains at all. All browsers and macOS's built in
> SSL library (secure transport) support them properly. OpenSSL and LibreSSL
> were/are simply broken. This was not such a big issue so far, but now that
> some old long lived certificates are expiring, it is increasingly an issue.
>
> FWIW it is possible to build libcurl on macOS without any external SSL
> library, so OpenSSL and LibreSSL are not needed at all. (Unfortunately the
> libcurl build that comes with most (all?) macOS versions does use
> LibreSSL.) The R installer could link to such a static libcurl library on
> macOS, and that would solve the issue for macOS. Whether it should, that's
> another question.
>
> Gabor
>
> On Wed, Jun 10, 2020 at 9:56 AM peter dalgaard wrote:
>
> > As I said, there is stuff that I don't understand in here (including
> > why browsers apparently do trust alternative chains)
> >
> > -pd
> >
> > > On 10 Jun 2020, at 01:53 , Simon Urbanek
> > wrote:
> > >
> > > You are making a very strong assumption that finding an alternative
> > chain of trust is safe. I'd argue it's not - it means that an adversary
> > could manipulate the chain in a way to trust it instead of the declared
> > chain and thus subverting it. In fact switching to OpenSSL would create a
> > serious security hole here - in particular since it installs a separate
> > trust store which it is far more easily attacked and subverted. By your
> > argument we should disable all SSL checks as that produces error with
> > incorrectly configured servers so not performing checks is better. It is
> > true that R is likely not used for sensitive transactions, but I would
> > rather it warned me about situations where the communication may be
> > compromised instead of just silently going along.
> > >
> > > Cheers,
> > > Simon
> > >
> > >
> > >
> > >> On Jun 10, 2020, at 11:39 AM, peter dalgaard
> wrote:
> > >>
> > >> Yes and no... At least as I understand it (Disclaimer: There are
> things
> > I am pretty sure that I don't understand properly, somewhere in the
> Bermuda
> > triangle beween CA bundles, TLS protocols, and Server-side settings),
> there
> > are two sided to this:
> > >>
> > >> One is that various *.r-project.org servers got hit by a fumble where
> > a higher-up certificate in the chain of trust expired before the *.
> > r-project.org one. This was fixed by changing the certificate chain on
> > each server.
> > >>
> > >> The other side is that this situation hit Mac users harder than
> others,
> > because Apple's LibreSSL doesn't have the same feature that openSSL has
> to
> > detect a secondary chain of trust when the primary one expired. This was
> > not unique to R - svn also failed from the command line - but it did
> affect
> > download.file() inside R.
> > >>
> > >> The upshot is that there might be 3rd party servers with a similar
> > certificate setup which have not been updated like *.r-project.org. This
> > is not too unlikely since web browsers do not have trouble accessing
> them,
> > and the whole matter may go undetected. For such servers, download.file()
> > would still fail.
> > >>
> > >> I.e., there is a case to be made that we might want to link openSSL
> > rather than LibreSSL. On the other hand, I gather that newer versions of
> > LibreSSL contain the relevant protocol upgrade, so maybe one can just
> wait
> > for Apple to update it. Or maybe we do want to link R against openSSL,
> but
> > almost certainly not for a hotfix release.
> > >>
> > >> Best
> > >> -pd
> > >>
> > >>> On 10 Jun 2020, at 00:50 , Simon Urbanek >
> > wrote:
> > >>>
> > >>> To be clear, this not an issue in the libraries nor R, the
> > certificates on the server were simply wrong. So, no, this has nothing to
> > do with R.
> > >>>
> > >>> Cheers,
> > >>> Simon
> > >>>
> > >>>
> > On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson <
> > henrik.bengts...@gmail.com> wrote:
> >
> > Was this resolved upstream or is this something that R should/could
> > fix? If the latter, could this also go into the "emergency release"
> R
> > 4.0.2 that is scheduled for 2020-06-22?
> >
> > My $.02
> >
> > /Henrik
> >
> >
> > On Sun, May 31, 2020 at
Re: [Rd] r-project.org SSL certificate issues
My (also not expert) understanding is that there is nothing insecure about alternative certificate chains at all. All browsers and macOS's built in SSL library (secure transport) support them properly. OpenSSL and LibreSSL were/are simply broken. This was not such a big issue so far, but now that some old long lived certificates are expiring, it is increasingly an issue. FWIW it is possible to build libcurl on macOS without any external SSL library, so OpenSSL and LibreSSL are not needed at all. (Unfortunately the libcurl build that comes with most (all?) macOS versions does use LibreSSL.) The R installer could link to such a static libcurl library on macOS, and that would solve the issue for macOS. Whether it should, that's another question. Gabor On Wed, Jun 10, 2020 at 9:56 AM peter dalgaard wrote: > As I said, there is stuff that I don't understand in here (including > why browsers apparently do trust alternative chains) > > -pd > > > On 10 Jun 2020, at 01:53 , Simon Urbanek > wrote: > > > > You are making a very strong assumption that finding an alternative > chain of trust is safe. I'd argue it's not - it means that an adversary > could manipulate the chain in a way to trust it instead of the declared > chain and thus subverting it. In fact switching to OpenSSL would create a > serious security hole here - in particular since it installs a separate > trust store which it is far more easily attacked and subverted. By your > argument we should disable all SSL checks as that produces error with > incorrectly configured servers so not performing checks is better. It is > true that R is likely not used for sensitive transactions, but I would > rather it warned me about situations where the communication may be > compromised instead of just silently going along. > > > > Cheers, > > Simon > > > > > > > >> On Jun 10, 2020, at 11:39 AM, peter dalgaard wrote: > >> > >> Yes and no... At least as I understand it (Disclaimer: There are things > I am pretty sure that I don't understand properly, somewhere in the Bermuda > triangle beween CA bundles, TLS protocols, and Server-side settings), there > are two sided to this: > >> > >> One is that various *.r-project.org servers got hit by a fumble where > a higher-up certificate in the chain of trust expired before the *. > r-project.org one. This was fixed by changing the certificate chain on > each server. > >> > >> The other side is that this situation hit Mac users harder than others, > because Apple's LibreSSL doesn't have the same feature that openSSL has to > detect a secondary chain of trust when the primary one expired. This was > not unique to R - svn also failed from the command line - but it did affect > download.file() inside R. > >> > >> The upshot is that there might be 3rd party servers with a similar > certificate setup which have not been updated like *.r-project.org. This > is not too unlikely since web browsers do not have trouble accessing them, > and the whole matter may go undetected. For such servers, download.file() > would still fail. > >> > >> I.e., there is a case to be made that we might want to link openSSL > rather than LibreSSL. On the other hand, I gather that newer versions of > LibreSSL contain the relevant protocol upgrade, so maybe one can just wait > for Apple to update it. Or maybe we do want to link R against openSSL, but > almost certainly not for a hotfix release. > >> > >> Best > >> -pd > >> > >>> On 10 Jun 2020, at 00:50 , Simon Urbanek > wrote: > >>> > >>> To be clear, this not an issue in the libraries nor R, the > certificates on the server were simply wrong. So, no, this has nothing to > do with R. > >>> > >>> Cheers, > >>> Simon > >>> > >>> > On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson < > henrik.bengts...@gmail.com> wrote: > > Was this resolved upstream or is this something that R should/could > fix? If the latter, could this also go into the "emergency release" R > 4.0.2 that is scheduled for 2020-06-22? > > My $.02 > > /Henrik > > > On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi > wrote: > > > > Btw. it would be also possible to create a macOS R installer that > > embeds a static or dynamic libcurl with Secure Transport, instead of > > the Apple default LibreSSL. > > > > This might be too late for R 4.0.1, I don't know. > > > > Gabor > > > > On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi > wrote: > >> > >> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi < > csardi.ga...@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
Re: [Rd] r-project.org SSL certificate issues
As I said, there is stuff that I don't understand in here (including why
browsers apparently do trust alternative chains)
-pd
> On 10 Jun 2020, at 01:53 , Simon Urbanek wrote:
>
> You are making a very strong assumption that finding an alternative chain of
> trust is safe. I'd argue it's not - it means that an adversary could
> manipulate the chain in a way to trust it instead of the declared chain and
> thus subverting it. In fact switching to OpenSSL would create a serious
> security hole here - in particular since it installs a separate trust store
> which it is far more easily attacked and subverted. By your argument we
> should disable all SSL checks as that produces error with incorrectly
> configured servers so not performing checks is better. It is true that R is
> likely not used for sensitive transactions, but I would rather it warned me
> about situations where the communication may be compromised instead of just
> silently going along.
>
> Cheers,
> Simon
>
>
>
>> On Jun 10, 2020, at 11:39 AM, peter dalgaard wrote:
>>
>> Yes and no... At least as I understand it (Disclaimer: There are things I am
>> pretty sure that I don't understand properly, somewhere in the Bermuda
>> triangle beween CA bundles, TLS protocols, and Server-side settings), there
>> are two sided to this:
>>
>> One is that various *.r-project.org servers got hit by a fumble where a
>> higher-up certificate in the chain of trust expired before the
>> *.r-project.org one. This was fixed by changing the certificate chain on
>> each server.
>>
>> The other side is that this situation hit Mac users harder than others,
>> because Apple's LibreSSL doesn't have the same feature that openSSL has to
>> detect a secondary chain of trust when the primary one expired. This was not
>> unique to R - svn also failed from the command line - but it did affect
>> download.file() inside R.
>>
>> The upshot is that there might be 3rd party servers with a similar
>> certificate setup which have not been updated like *.r-project.org. This is
>> not too unlikely since web browsers do not have trouble accessing them, and
>> the whole matter may go undetected. For such servers, download.file() would
>> still fail.
>>
>> I.e., there is a case to be made that we might want to link openSSL rather
>> than LibreSSL. On the other hand, I gather that newer versions of LibreSSL
>> contain the relevant protocol upgrade, so maybe one can just wait for Apple
>> to update it. Or maybe we do want to link R against openSSL, but almost
>> certainly not for a hotfix release.
>>
>> Best
>> -pd
>>
>>> On 10 Jun 2020, at 00:50 , Simon Urbanek
>>> wrote:
>>>
>>> To be clear, this not an issue in the libraries nor R, the certificates on
>>> the server were simply wrong. So, no, this has nothing to do with R.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson
wrote:
Was this resolved upstream or is this something that R should/could
fix? If the latter, could this also go into the "emergency release" R
4.0.2 that is scheduled for 2020-06-22?
My $.02
/Henrik
On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi
wrote:
>
> Btw. it would be also possible to create a macOS R installer that
> embeds a static or dynamic libcurl with Secure Transport, instead of
> the Apple default LibreSSL.
>
> This might be too late for R 4.0.1, I don't know.
>
> Gabor
>
> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi
> wrote:
>>
>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi
>> 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
Re: [Rd] r-project.org SSL certificate issues
On 10/06/2020 00:39, peter dalgaard wrote: Yes and no... At least as I understand it (Disclaimer: There are things I am pretty sure that I don't understand properly, somewhere in the Bermuda triangle beween CA bundles, TLS protocols, and Server-side settings), there are two sided to this: One is that various *.r-project.org servers got hit by a fumble where a higher-up certificate in the chain of trust expired before the *.r-project.org one. This was fixed by changing the certificate chain on each server. The other side is that this situation hit Mac users harder than others, because Apple's LibreSSL doesn't have the same feature that openSSL has to detect a secondary chain of trust when the primary one expired. This was not unique to R - svn also failed from the command line - but it did affect download.file() inside R. The upshot is that there might be 3rd party servers with a similar certificate setup which have not been updated like *.r-project.org. This is not too unlikely since web browsers do not have trouble accessing them, and the whole matter may go undetected. For such servers, download.file() would still fail. A dozen or so packages fail their CRAN checks because of this. The most common problematic site has been reported to its web admins, but not resolved. I.e., there is a case to be made that we might want to link openSSL rather than LibreSSL. On the other hand, I gather that newer versions of LibreSSL contain the relevant protocol upgrade, so maybe one can just wait for Apple to update it. Or maybe we do want to link R against openSSL, but almost certainly not for a hotfix release. This is not just a macOS issue: most CRAN failures are seen on Debian and Solaris as well as macOS (but not Fedora). And a different one (3 packages by the same author misusing RCurl to set a <= 2014 root certificate bundle) is seen only on Fedora. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
You are making a very strong assumption that finding an alternative chain of
trust is safe. I'd argue it's not - it means that an adversary could manipulate
the chain in a way to trust it instead of the declared chain and thus
subverting it. In fact switching to OpenSSL would create a serious security
hole here - in particular since it installs a separate trust store which it is
far more easily attacked and subverted. By your argument we should disable all
SSL checks as that produces error with incorrectly configured servers so not
performing checks is better. It is true that R is likely not used for sensitive
transactions, but I would rather it warned me about situations where the
communication may be compromised instead of just silently going along.
Cheers,
Simon
> On Jun 10, 2020, at 11:39 AM, peter dalgaard wrote:
>
> Yes and no... At least as I understand it (Disclaimer: There are things I am
> pretty sure that I don't understand properly, somewhere in the Bermuda
> triangle beween CA bundles, TLS protocols, and Server-side settings), there
> are two sided to this:
>
> One is that various *.r-project.org servers got hit by a fumble where a
> higher-up certificate in the chain of trust expired before the
> *.r-project.org one. This was fixed by changing the certificate chain on each
> server.
>
> The other side is that this situation hit Mac users harder than others,
> because Apple's LibreSSL doesn't have the same feature that openSSL has to
> detect a secondary chain of trust when the primary one expired. This was not
> unique to R - svn also failed from the command line - but it did affect
> download.file() inside R.
>
> The upshot is that there might be 3rd party servers with a similar
> certificate setup which have not been updated like *.r-project.org. This is
> not too unlikely since web browsers do not have trouble accessing them, and
> the whole matter may go undetected. For such servers, download.file() would
> still fail.
>
> I.e., there is a case to be made that we might want to link openSSL rather
> than LibreSSL. On the other hand, I gather that newer versions of LibreSSL
> contain the relevant protocol upgrade, so maybe one can just wait for Apple
> to update it. Or maybe we do want to link R against openSSL, but almost
> certainly not for a hotfix release.
>
> Best
> -pd
>
>> On 10 Jun 2020, at 00:50 , Simon Urbanek wrote:
>>
>> To be clear, this not an issue in the libraries nor R, the certificates on
>> the server were simply wrong. So, no, this has nothing to do with R.
>>
>> Cheers,
>> Simon
>>
>>
>>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson
>>> wrote:
>>>
>>> Was this resolved upstream or is this something that R should/could
>>> fix? If the latter, could this also go into the "emergency release" R
>>> 4.0.2 that is scheduled for 2020-06-22?
>>>
>>> My $.02
>>>
>>> /Henrik
>>>
>>>
>>> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi wrote:
Btw. it would be also possible to create a macOS R installer that
embeds a static or dynamic libcurl with Secure Transport, instead of
the Apple default LibreSSL.
This might be too late for R 4.0.1, I don't know.
Gabor
On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi
wrote:
>
> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>>
Re: [Rd] r-project.org SSL certificate issues
Yes and no... At least as I understand it (Disclaimer: There are things I am
pretty sure that I don't understand properly, somewhere in the Bermuda triangle
beween CA bundles, TLS protocols, and Server-side settings), there are two
sided to this:
One is that various *.r-project.org servers got hit by a fumble where a
higher-up certificate in the chain of trust expired before the *.r-project.org
one. This was fixed by changing the certificate chain on each server.
The other side is that this situation hit Mac users harder than others, because
Apple's LibreSSL doesn't have the same feature that openSSL has to detect a
secondary chain of trust when the primary one expired. This was not unique to R
- svn also failed from the command line - but it did affect download.file()
inside R.
The upshot is that there might be 3rd party servers with a similar certificate
setup which have not been updated like *.r-project.org. This is not too
unlikely since web browsers do not have trouble accessing them, and the whole
matter may go undetected. For such servers, download.file() would still fail.
I.e., there is a case to be made that we might want to link openSSL rather than
LibreSSL. On the other hand, I gather that newer versions of LibreSSL contain
the relevant protocol upgrade, so maybe one can just wait for Apple to update
it. Or maybe we do want to link R against openSSL, but almost certainly not for
a hotfix release.
Best
-pd
> On 10 Jun 2020, at 00:50 , Simon Urbanek wrote:
>
> To be clear, this not an issue in the libraries nor R, the certificates on
> the server were simply wrong. So, no, this has nothing to do with R.
>
> Cheers,
> Simon
>
>
>> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson
>> wrote:
>>
>> Was this resolved upstream or is this something that R should/could
>> fix? If the latter, could this also go into the "emergency release" R
>> 4.0.2 that is scheduled for 2020-06-22?
>>
>> My $.02
>>
>> /Henrik
>>
>>
>> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi wrote:
>>>
>>> Btw. it would be also possible to create a macOS R installer that
>>> embeds a static or dynamic libcurl with Secure Transport, instead of
>>> the Apple default LibreSSL.
>>>
>>> This might be too late for R 4.0.1, I don't know.
>>>
>>> Gabor
>>>
>>> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi wrote:
On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi
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
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
To be clear, this not an issue in the libraries nor R, the certificates on the
server were simply wrong. So, no, this has nothing to do with R.
Cheers,
Simon
> On Jun 10, 2020, at 10:45 AM, Henrik Bengtsson
> wrote:
>
> Was this resolved upstream or is this something that R should/could
> fix? If the latter, could this also go into the "emergency release" R
> 4.0.2 that is scheduled for 2020-06-22?
>
> My $.02
>
> /Henrik
>
>
> On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi wrote:
>>
>> Btw. it would be also possible to create a macOS R installer that
>> embeds a static or dynamic libcurl with Secure Transport, instead of
>> the Apple default LibreSSL.
>>
>> This might be too late for R 4.0.1, I don't know.
>>
>> Gabor
>>
>> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi wrote:
>>>
>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi
>>> 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
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
Was this resolved upstream or is this something that R should/could
fix? If the latter, could this also go into the "emergency release" R
4.0.2 that is scheduled for 2020-06-22?
My $.02
/Henrik
On Sun, May 31, 2020 at 8:13 AM Gábor Csárdi wrote:
>
> Btw. it would be also possible to create a macOS R installer that
> embeds a static or dynamic libcurl with Secure Transport, instead of
> the Apple default LibreSSL.
>
> This might be too late for R 4.0.1, I don't know.
>
> Gabor
>
> On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi wrote:
> >
> > On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi
> > 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
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
Btw. it would be also possible to create a macOS R installer that
embeds a static or dynamic libcurl with Secure Transport, instead of
the Apple default LibreSSL.
This might be too late for R 4.0.1, I don't know.
Gabor
On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi wrote:
>
> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
The expired cert was in my initial email. This is a CA cert. If you go
to https://www.ssllabs.com/ssltest/analyze.html?d=svn.r-project.org
and wait for the analysis, and then expand the certification paths,
then you'll see three possible paths. (For most simulated clients.)
Two are trusted, one is not. The browsers can use a trusted one, e.g.
my Chrome uses the first, you can see this if you click on the lock
before the URL, and then on "Certificate". You'll see a chain of three
certs, just like on the ssllabs page.
Apparently, R / libcurl / openssl cannot use them, I am not entirely sure why.
Gabor
On Sat, May 30, 2020 at 10:40 PM Duncan Murdoch
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.
>
> Hopefully someone who can actually act on this can figure out what needs
> doing.
>
> Duncan Murdoch
>
> >
> > On Sat, May 30, 2020 at 5:16 PM Bob Rudis wrote:
> >>
> >> # A tibble: 13 x 1
> >> site
> >>
> >> 1 beta.r-project.org
> >> 2 bugs.r-project.org
> >> 3 cran-archive.r-project.org
> >> 4 cran.r-project.org
> >> 5 developer.r-project.org
> >> 6 ess.r-project.org
> >> 7 ftp.cran.r-project.org
> >> 8 journal.r-project.org
> >> 9 r-project.org
> >> 10 svn.r-project.org
> >> 11 user2011.r-project.org
> >> 12 www.cran.r-project.org
> >> 13 www.r-project.org
> >>
> >> is the whole list b/c of the wildcard cert.
> >>
> >> On Sat, May 30, 2020 at 5:07 PM Bob Rudis wrote:
> >>>
> >>> It's the top of chain CA cert, so browsers are being lazy and helpful
> >>> to humans by (incorrectly, albeit) relying on the existing trust
> >>> relationship.
> >>>
> >>> libcurl (et al) is not nearly as forgiving.
> >>>
> >>> On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
>
> Odd. Safari has no problem and says certificate expires August 16 2020,
> but I also see the download.file issue with 4.0.1 beta:
>
> > download.file("https://www.r-project.org;, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("https://www.r-project.org;, tempfile()) :
> cannot open URL 'https://www.r-project.org'
> In addition: Warning message:
> In download.file("https://www.r-project.org;, tempfile()) :
> URL 'https://www.r-project.org/': status was 'Peer certificate cannot
> be authenticated with given CA certificates'
>
> (note slightly different error message).
>
> svn is also affected:
>
> Peters-MacBook-Air:R pd$ svn up
> Updating '.':
> Error validating server certificate for 'https://svn.r-project.org:443':
> - The certificate has expired.
> Certificate information:
> - Hostname: *.r-project.org
> - Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
> - Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA
> Limited, Salford, Greater Manchester, GB
> - Fingerprint:
> 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
> (R)eject, accept (t)emporarily or accept (p)ermanently? t
> Usrc/library/grid/R/grob.R
>
>
> ssltest shows two certificates of which only one is expired?
>
> -pd
>
>
>
> > On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
> >
> > On macOS 10.15.5 and R-devel:
> >
> >> download.file("https://www.r-project.org;, tempfile())
> > trying URL 'https://www.r-project.org'
> > Error in download.file("https://www.r-project.org;, tempfile()) :
> > cannot open URL 'https://www.r-project.org'
> > In addition: Warning message:
> > In download.file("https://www.r-project.org;, tempfile()) :
> > URL 'https://www.r-project.org': status was 'SSL peer certificate or
> > SSH remote key was not OK'
> >
> > https://www.ssllabs.com/ssltest says:
> >
> > COMODO RSA Certification Authority
> > Fingerprint SHA256:
> > 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> > Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> > Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> > minutes ago) EXPIRED
> >
> > AFAICT this is the reason:
> > https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
> >
> > FYI,
> > Gabor
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
>
Re: [Rd] r-project.org SSL certificate issues
On Sat, May 30, 2020 at 11:02 PM Jeroen Ooms 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
On Sat, May 30, 2020 at 11:40 PM Duncan Murdoch
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.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
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.
Hopefully someone who can actually act on this can figure out what needs
doing.
Duncan Murdoch
On Sat, May 30, 2020 at 5:16 PM Bob Rudis wrote:
# A tibble: 13 x 1
site
1 beta.r-project.org
2 bugs.r-project.org
3 cran-archive.r-project.org
4 cran.r-project.org
5 developer.r-project.org
6 ess.r-project.org
7 ftp.cran.r-project.org
8 journal.r-project.org
9 r-project.org
10 svn.r-project.org
11 user2011.r-project.org
12 www.cran.r-project.org
13 www.r-project.org
is the whole list b/c of the wildcard cert.
On Sat, May 30, 2020 at 5:07 PM Bob Rudis wrote:
It's the top of chain CA cert, so browsers are being lazy and helpful
to humans by (incorrectly, albeit) relying on the existing trust
relationship.
libcurl (et al) is not nearly as forgiving.
On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
Odd. Safari has no problem and says certificate expires August 16 2020, but I
also see the download.file issue with 4.0.1 beta:
download.file("https://www.r-project.org;, tempfile())
trying URL 'https://www.r-project.org'
Error in download.file("https://www.r-project.org;, tempfile()) :
cannot open URL 'https://www.r-project.org'
In addition: Warning message:
In download.file("https://www.r-project.org;, tempfile()) :
URL 'https://www.r-project.org/': status was 'Peer certificate cannot be
authenticated with given CA certificates'
(note slightly different error message).
svn is also affected:
Peters-MacBook-Air:R pd$ svn up
Updating '.':
Error validating server certificate for 'https://svn.r-project.org:443':
- The certificate has expired.
Certificate information:
- Hostname: *.r-project.org
- Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
- Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA Limited,
Salford, Greater Manchester, GB
- Fingerprint: 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
(R)eject, accept (t)emporarily or accept (p)ermanently? t
Usrc/library/grid/R/grob.R
ssltest shows two certificates of which only one is expired?
-pd
On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
On macOS 10.15.5 and R-devel:
download.file("https://www.r-project.org;, tempfile())
trying URL 'https://www.r-project.org'
Error in download.file("https://www.r-project.org;, tempfile()) :
cannot open URL 'https://www.r-project.org'
In addition: Warning message:
In download.file("https://www.r-project.org;, tempfile()) :
URL 'https://www.r-project.org': status was 'SSL peer certificate or
SSH remote key was not OK'
https://www.ssllabs.com/ssltest says:
COMODO RSA Certification Authority
Fingerprint SHA256:
4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
minutes ago) EXPIRED
AFAICT this is the reason:
https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
FYI,
Gabor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
The browsers still shouldn't trust it. The CA cert is expired.
On Sat, May 30, 2020 at 5:23 PM 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.
>
> On Sat, May 30, 2020 at 5:16 PM Bob Rudis wrote:
> >
> > # A tibble: 13 x 1
> >site
> >
> > 1 beta.r-project.org
> > 2 bugs.r-project.org
> > 3 cran-archive.r-project.org
> > 4 cran.r-project.org
> > 5 developer.r-project.org
> > 6 ess.r-project.org
> > 7 ftp.cran.r-project.org
> > 8 journal.r-project.org
> > 9 r-project.org
> > 10 svn.r-project.org
> > 11 user2011.r-project.org
> > 12 www.cran.r-project.org
> > 13 www.r-project.org
> >
> > is the whole list b/c of the wildcard cert.
> >
> > On Sat, May 30, 2020 at 5:07 PM Bob Rudis wrote:
> > >
> > > It's the top of chain CA cert, so browsers are being lazy and helpful
> > > to humans by (incorrectly, albeit) relying on the existing trust
> > > relationship.
> > >
> > > libcurl (et al) is not nearly as forgiving.
> > >
> > > On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
> > > >
> > > > Odd. Safari has no problem and says certificate expires August 16 2020,
> > > > but I also see the download.file issue with 4.0.1 beta:
> > > >
> > > > > download.file("https://www.r-project.org;, tempfile())
> > > > trying URL 'https://www.r-project.org'
> > > > Error in download.file("https://www.r-project.org;, tempfile()) :
> > > > cannot open URL 'https://www.r-project.org'
> > > > In addition: Warning message:
> > > > In download.file("https://www.r-project.org;, tempfile()) :
> > > > URL 'https://www.r-project.org/': status was 'Peer certificate cannot
> > > > be authenticated with given CA certificates'
> > > >
> > > > (note slightly different error message).
> > > >
> > > > svn is also affected:
> > > >
> > > > Peters-MacBook-Air:R pd$ svn up
> > > > Updating '.':
> > > > Error validating server certificate for 'https://svn.r-project.org:443':
> > > > - The certificate has expired.
> > > > Certificate information:
> > > > - Hostname: *.r-project.org
> > > > - Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
> > > > - Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA
> > > > Limited, Salford, Greater Manchester, GB
> > > > - Fingerprint:
> > > > 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
> > > > (R)eject, accept (t)emporarily or accept (p)ermanently? t
> > > > Usrc/library/grid/R/grob.R
> > > >
> > > >
> > > > ssltest shows two certificates of which only one is expired?
> > > >
> > > > -pd
> > > >
> > > >
> > > >
> > > > > On 30 May 2020, at 22:17 , Gábor Csárdi
> > > > > wrote:
> > > > >
> > > > > On macOS 10.15.5 and R-devel:
> > > > >
> > > > >> download.file("https://www.r-project.org;, tempfile())
> > > > > trying URL 'https://www.r-project.org'
> > > > > Error in download.file("https://www.r-project.org;, tempfile()) :
> > > > > cannot open URL 'https://www.r-project.org'
> > > > > In addition: Warning message:
> > > > > In download.file("https://www.r-project.org;, tempfile()) :
> > > > > URL 'https://www.r-project.org': status was 'SSL peer certificate or
> > > > > SSH remote key was not OK'
> > > > >
> > > > > https://www.ssllabs.com/ssltest says:
> > > > >
> > > > > COMODO RSA Certification Authority
> > > > > Fingerprint SHA256:
> > > > > 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> > > > > Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> > > > > Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> > > > > minutes ago) EXPIRED
> > > > >
> > > > > AFAICT this is the reason:
> > > > > https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
> > > > >
> > > > > FYI,
> > > > > Gabor
> > > > >
> > > > > __
> > > > > R-devel@r-project.org mailing list
> > > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > > >
> > > > --
> > > > Peter Dalgaard, Professor,
> > > > Center for Statistics, Copenhagen Business School
> > > > Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > > > Phone: (+45)38153501
> > > > Office: A 4.23
> > > > Email: pd@cbs.dk Priv: pda...@gmail.com
> > > >
> > > > __
> > > > R-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
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.
On Sat, May 30, 2020 at 5:16 PM Bob Rudis wrote:
>
> # A tibble: 13 x 1
>site
>
> 1 beta.r-project.org
> 2 bugs.r-project.org
> 3 cran-archive.r-project.org
> 4 cran.r-project.org
> 5 developer.r-project.org
> 6 ess.r-project.org
> 7 ftp.cran.r-project.org
> 8 journal.r-project.org
> 9 r-project.org
> 10 svn.r-project.org
> 11 user2011.r-project.org
> 12 www.cran.r-project.org
> 13 www.r-project.org
>
> is the whole list b/c of the wildcard cert.
>
> On Sat, May 30, 2020 at 5:07 PM Bob Rudis wrote:
> >
> > It's the top of chain CA cert, so browsers are being lazy and helpful
> > to humans by (incorrectly, albeit) relying on the existing trust
> > relationship.
> >
> > libcurl (et al) is not nearly as forgiving.
> >
> > On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
> > >
> > > Odd. Safari has no problem and says certificate expires August 16 2020,
> > > but I also see the download.file issue with 4.0.1 beta:
> > >
> > > > download.file("https://www.r-project.org;, tempfile())
> > > trying URL 'https://www.r-project.org'
> > > Error in download.file("https://www.r-project.org;, tempfile()) :
> > > cannot open URL 'https://www.r-project.org'
> > > In addition: Warning message:
> > > In download.file("https://www.r-project.org;, tempfile()) :
> > > URL 'https://www.r-project.org/': status was 'Peer certificate cannot
> > > be authenticated with given CA certificates'
> > >
> > > (note slightly different error message).
> > >
> > > svn is also affected:
> > >
> > > Peters-MacBook-Air:R pd$ svn up
> > > Updating '.':
> > > Error validating server certificate for 'https://svn.r-project.org:443':
> > > - The certificate has expired.
> > > Certificate information:
> > > - Hostname: *.r-project.org
> > > - Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
> > > - Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA
> > > Limited, Salford, Greater Manchester, GB
> > > - Fingerprint:
> > > 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
> > > (R)eject, accept (t)emporarily or accept (p)ermanently? t
> > > Usrc/library/grid/R/grob.R
> > >
> > >
> > > ssltest shows two certificates of which only one is expired?
> > >
> > > -pd
> > >
> > >
> > >
> > > > On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
> > > >
> > > > On macOS 10.15.5 and R-devel:
> > > >
> > > >> download.file("https://www.r-project.org;, tempfile())
> > > > trying URL 'https://www.r-project.org'
> > > > Error in download.file("https://www.r-project.org;, tempfile()) :
> > > > cannot open URL 'https://www.r-project.org'
> > > > In addition: Warning message:
> > > > In download.file("https://www.r-project.org;, tempfile()) :
> > > > URL 'https://www.r-project.org': status was 'SSL peer certificate or
> > > > SSH remote key was not OK'
> > > >
> > > > https://www.ssllabs.com/ssltest says:
> > > >
> > > > COMODO RSA Certification Authority
> > > > Fingerprint SHA256:
> > > > 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> > > > Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> > > > Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> > > > minutes ago) EXPIRED
> > > >
> > > > AFAICT this is the reason:
> > > > https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
> > > >
> > > > FYI,
> > > > Gabor
> > > >
> > > > __
> > > > R-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> > > --
> > > Peter Dalgaard, Professor,
> > > Center for Statistics, Copenhagen Business School
> > > Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > > Phone: (+45)38153501
> > > Office: A 4.23
> > > Email: pd@cbs.dk Priv: pda...@gmail.com
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
It's the top of chain CA cert, so browsers are being lazy and helpful
to humans by (incorrectly, albeit) relying on the existing trust
relationship.
libcurl (et al) is not nearly as forgiving.
On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
>
> Odd. Safari has no problem and says certificate expires August 16 2020, but I
> also see the download.file issue with 4.0.1 beta:
>
> > download.file("https://www.r-project.org;, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("https://www.r-project.org;, tempfile()) :
> cannot open URL 'https://www.r-project.org'
> In addition: Warning message:
> In download.file("https://www.r-project.org;, tempfile()) :
> URL 'https://www.r-project.org/': status was 'Peer certificate cannot be
> authenticated with given CA certificates'
>
> (note slightly different error message).
>
> svn is also affected:
>
> Peters-MacBook-Air:R pd$ svn up
> Updating '.':
> Error validating server certificate for 'https://svn.r-project.org:443':
> - The certificate has expired.
> Certificate information:
> - Hostname: *.r-project.org
> - Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
> - Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA Limited,
> Salford, Greater Manchester, GB
> - Fingerprint: 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
> (R)eject, accept (t)emporarily or accept (p)ermanently? t
> Usrc/library/grid/R/grob.R
>
>
> ssltest shows two certificates of which only one is expired?
>
> -pd
>
>
>
> > On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
> >
> > On macOS 10.15.5 and R-devel:
> >
> >> download.file("https://www.r-project.org;, tempfile())
> > trying URL 'https://www.r-project.org'
> > Error in download.file("https://www.r-project.org;, tempfile()) :
> > cannot open URL 'https://www.r-project.org'
> > In addition: Warning message:
> > In download.file("https://www.r-project.org;, tempfile()) :
> > URL 'https://www.r-project.org': status was 'SSL peer certificate or
> > SSH remote key was not OK'
> >
> > https://www.ssllabs.com/ssltest says:
> >
> > COMODO RSA Certification Authority
> > Fingerprint SHA256:
> > 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> > Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> > Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> > minutes ago) EXPIRED
> >
> > AFAICT this is the reason:
> > https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
> >
> > FYI,
> > Gabor
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
# A tibble: 13 x 1
site
1 beta.r-project.org
2 bugs.r-project.org
3 cran-archive.r-project.org
4 cran.r-project.org
5 developer.r-project.org
6 ess.r-project.org
7 ftp.cran.r-project.org
8 journal.r-project.org
9 r-project.org
10 svn.r-project.org
11 user2011.r-project.org
12 www.cran.r-project.org
13 www.r-project.org
is the whole list b/c of the wildcard cert.
On Sat, May 30, 2020 at 5:07 PM Bob Rudis wrote:
>
> It's the top of chain CA cert, so browsers are being lazy and helpful
> to humans by (incorrectly, albeit) relying on the existing trust
> relationship.
>
> libcurl (et al) is not nearly as forgiving.
>
> On Sat, May 30, 2020 at 5:01 PM peter dalgaard wrote:
> >
> > Odd. Safari has no problem and says certificate expires August 16 2020, but
> > I also see the download.file issue with 4.0.1 beta:
> >
> > > download.file("https://www.r-project.org;, tempfile())
> > trying URL 'https://www.r-project.org'
> > Error in download.file("https://www.r-project.org;, tempfile()) :
> > cannot open URL 'https://www.r-project.org'
> > In addition: Warning message:
> > In download.file("https://www.r-project.org;, tempfile()) :
> > URL 'https://www.r-project.org/': status was 'Peer certificate cannot be
> > authenticated with given CA certificates'
> >
> > (note slightly different error message).
> >
> > svn is also affected:
> >
> > Peters-MacBook-Air:R pd$ svn up
> > Updating '.':
> > Error validating server certificate for 'https://svn.r-project.org:443':
> > - The certificate has expired.
> > Certificate information:
> > - Hostname: *.r-project.org
> > - Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
> > - Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA
> > Limited, Salford, Greater Manchester, GB
> > - Fingerprint: 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
> > (R)eject, accept (t)emporarily or accept (p)ermanently? t
> > Usrc/library/grid/R/grob.R
> >
> >
> > ssltest shows two certificates of which only one is expired?
> >
> > -pd
> >
> >
> >
> > > On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
> > >
> > > On macOS 10.15.5 and R-devel:
> > >
> > >> download.file("https://www.r-project.org;, tempfile())
> > > trying URL 'https://www.r-project.org'
> > > Error in download.file("https://www.r-project.org;, tempfile()) :
> > > cannot open URL 'https://www.r-project.org'
> > > In addition: Warning message:
> > > In download.file("https://www.r-project.org;, tempfile()) :
> > > URL 'https://www.r-project.org': status was 'SSL peer certificate or
> > > SSH remote key was not OK'
> > >
> > > https://www.ssllabs.com/ssltest says:
> > >
> > > COMODO RSA Certification Authority
> > > Fingerprint SHA256:
> > > 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> > > Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> > > Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> > > minutes ago) EXPIRED
> > >
> > > AFAICT this is the reason:
> > > https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
> > >
> > > FYI,
> > > Gabor
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > --
> > Peter Dalgaard, Professor,
> > Center for Statistics, Copenhagen Business School
> > Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > Phone: (+45)38153501
> > Office: A 4.23
> > Email: pd@cbs.dk Priv: pda...@gmail.com
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
The certificate itself is ok, but some other certificate higher up in
the chain is not. It is possible to have multiple certificate chains,
and only one needs to be successful for to accept the certificate.
Some clients are able to use an alternate chain, so they are fine, but
other clients do not accept some cert(s) for the alternate chain to
work. This is why you get errors only with some clients.
Even Safari works on the same machine, but R does not, probably
because libcurl uses openssl which uses a different set of CA certs.
Gabor
On Sat, May 30, 2020 at 10:01 PM peter dalgaard wrote:
>
> Odd. Safari has no problem and says certificate expires August 16 2020, but I
> also see the download.file issue with 4.0.1 beta:
>
> > download.file("https://www.r-project.org;, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("https://www.r-project.org;, tempfile()) :
> cannot open URL 'https://www.r-project.org'
> In addition: Warning message:
> In download.file("https://www.r-project.org;, tempfile()) :
> URL 'https://www.r-project.org/': status was 'Peer certificate cannot be
> authenticated with given CA certificates'
>
> (note slightly different error message).
>
> svn is also affected:
>
> Peters-MacBook-Air:R pd$ svn up
> Updating '.':
> Error validating server certificate for 'https://svn.r-project.org:443':
> - The certificate has expired.
> Certificate information:
> - Hostname: *.r-project.org
> - Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
> - Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA Limited,
> Salford, Greater Manchester, GB
> - Fingerprint: 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
> (R)eject, accept (t)emporarily or accept (p)ermanently? t
> Usrc/library/grid/R/grob.R
>
>
> ssltest shows two certificates of which only one is expired?
>
> -pd
>
>
>
> > On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
> >
> > On macOS 10.15.5 and R-devel:
> >
> >> download.file("https://www.r-project.org;, tempfile())
> > trying URL 'https://www.r-project.org'
> > Error in download.file("https://www.r-project.org;, tempfile()) :
> > cannot open URL 'https://www.r-project.org'
> > In addition: Warning message:
> > In download.file("https://www.r-project.org;, tempfile()) :
> > URL 'https://www.r-project.org': status was 'SSL peer certificate or
> > SSH remote key was not OK'
> >
> > https://www.ssllabs.com/ssltest says:
> >
> > COMODO RSA Certification Authority
> > Fingerprint SHA256:
> > 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> > Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> > Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> > minutes ago) EXPIRED
> >
> > AFAICT this is the reason:
> > https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
> >
> > FYI,
> > Gabor
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk Priv: pda...@gmail.com
>
>
>
>
>
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
Odd. Safari has no problem and says certificate expires August 16 2020, but I
also see the download.file issue with 4.0.1 beta:
> download.file("https://www.r-project.org;, tempfile())
trying URL 'https://www.r-project.org'
Error in download.file("https://www.r-project.org;, tempfile()) :
cannot open URL 'https://www.r-project.org'
In addition: Warning message:
In download.file("https://www.r-project.org;, tempfile()) :
URL 'https://www.r-project.org/': status was 'Peer certificate cannot be
authenticated with given CA certificates'
(note slightly different error message).
svn is also affected:
Peters-MacBook-Air:R pd$ svn up
Updating '.':
Error validating server certificate for 'https://svn.r-project.org:443':
- The certificate has expired.
Certificate information:
- Hostname: *.r-project.org
- Valid: from Aug 16 00:00:00 2018 GMT until Aug 15 23:59:59 2020 GMT
- Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA Limited,
Salford, Greater Manchester, GB
- Fingerprint: 93:B8:AF:9F:0A:67:2F:3A:C9:BA:FF:86:BB:2C:08:47:02:7F:1D:8D
(R)eject, accept (t)emporarily or accept (p)ermanently? t
Usrc/library/grid/R/grob.R
ssltest shows two certificates of which only one is expired?
-pd
> On 30 May 2020, at 22:17 , Gábor Csárdi wrote:
>
> On macOS 10.15.5 and R-devel:
>
>> download.file("https://www.r-project.org;, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("https://www.r-project.org;, tempfile()) :
> cannot open URL 'https://www.r-project.org'
> In addition: Warning message:
> In download.file("https://www.r-project.org;, tempfile()) :
> URL 'https://www.r-project.org': status was 'SSL peer certificate or
> SSH remote key was not OK'
>
> https://www.ssllabs.com/ssltest says:
>
> COMODO RSA Certification Authority
> Fingerprint SHA256:
> 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> minutes ago) EXPIRED
>
> AFAICT this is the reason:
> https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
>
> FYI,
> Gabor
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
Yep. It should switch to Let's Encrypt with the automated cert renewals ASAP.
On Sat, May 30, 2020 at 4:17 PM Gábor Csárdi wrote:
>
> On macOS 10.15.5 and R-devel:
>
> > download.file("https://www.r-project.org;, tempfile())
> trying URL 'https://www.r-project.org'
> Error in download.file("https://www.r-project.org;, tempfile()) :
> cannot open URL 'https://www.r-project.org'
> In addition: Warning message:
> In download.file("https://www.r-project.org;, tempfile()) :
> URL 'https://www.r-project.org': status was 'SSL peer certificate or
> SSH remote key was not OK'
>
> https://www.ssllabs.com/ssltest says:
>
> COMODO RSA Certification Authority
> Fingerprint SHA256:
> 4f32d5dc00f715250abcc486511e37f501a899deb3bf7ea8adbbd3aef1c412da
> Pin SHA256: grX4Ta9HpZx6tSHkmCrvpApTQGo67CYDnvprLg5yRME=
> Valid untilSat, 30 May 2020 10:48:38 UTC (expired 8 hours and 51
> minutes ago) EXPIRED
>
> AFAICT this is the reason:
> https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020
>
> FYI,
> Gabor
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
