r-project.org SSL certificate issues

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

r-project.org SSL certificate issues

Gábor Csárdi
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Bob Rudis
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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Peter Dalgaard-2
In reply to this post by Gábor Csárdi
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 '<a href="https://svn.r-project.org:443':">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
U    src/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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] 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: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Bob Rudis
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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
> U    src/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 <[hidden email]> 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
> >
> > ______________________________________________
> > [hidden email] 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: [hidden email]  Priv: [hidden email]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Gábor Csárdi
In reply to this post by Peter Dalgaard-2
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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
> U    src/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 <[hidden email]> 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
> >
> > ______________________________________________
> > [hidden email] 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: [hidden email]  Priv: [hidden email]
>
>
>
>
>
>
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Bob Rudis
In reply to this post by Bob Rudis
# A tibble: 13 x 1
   site
   <chr>
 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 <[hidden email]> 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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
> > U    src/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 <[hidden email]> 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
> > >
> > > ______________________________________________
> > > [hidden email] 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: [hidden email]  Priv: [hidden email]
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Bob Rudis
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 <[hidden email]> wrote:

>
> # A tibble: 13 x 1
>    site
>    <chr>
>  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 <[hidden email]> 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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
> > > U    src/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 <[hidden email]> 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
> > > >
> > > > ______________________________________________
> > > > [hidden email] 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: [hidden email]  Priv: [hidden email]
> > >
> > > ______________________________________________
> > > [hidden email] mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Bob Rudis
The browsers still shouldn't trust it. The CA cert is expired.

On Sat, May 30, 2020 at 5:23 PM Bob Rudis <[hidden email]> 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 <[hidden email]> wrote:
> >
> > # A tibble: 13 x 1
> >    site
> >    <chr>
> >  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 <[hidden email]> 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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
> > > > U    src/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 <[hidden email]> 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
> > > > >
> > > > > ______________________________________________
> > > > > [hidden email] 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: [hidden email]  Priv: [hidden email]
> > > >
> > > > ______________________________________________
> > > > [hidden email] mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Duncan Murdoch-2
In reply to this post by Bob Rudis
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 <[hidden email]> wrote:
>>
>> # A tibble: 13 x 1
>>     site
>>     <chr>
>>   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 <[hidden email]> 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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
>>>> U    src/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 <[hidden email]> 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
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] 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: [hidden email]  Priv: [hidden email]
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Jeroen Ooms-2
On Sat, May 30, 2020 at 11:40 PM Duncan Murdoch
<[hidden email]> 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.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Gábor Csárdi
In reply to this post by Duncan Murdoch-2
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
<[hidden email]> 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 <[hidden email]> wrote:
> >>
> >> # A tibble: 13 x 1
> >>     site
> >>     <chr>
> >>   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 <[hidden email]> 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 <[hidden email]> 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 '<a href="https://svn.r-project.org:443':">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
> >>>> U    src/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 <[hidden email]> 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
> >>>>>
> >>>>> ______________________________________________
> >>>>> [hidden email] 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: [hidden email]  Priv: [hidden email]
> >>>>
> >>>> ______________________________________________
> >>>> [hidden email] mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Gábor Csárdi
In reply to this post by Jeroen Ooms-2
On Sat, May 30, 2020 at 11:02 PM Jeroen Ooms <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Gábor Csárdi
On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Gábor Csárdi
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 <[hidden email]> wrote:

>
> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Henrik Bengtsson-5
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 <[hidden email]> 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 <[hidden email]> wrote:
> >
> > On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Simon Urbanek
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>
>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Peter Dalgaard-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] 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: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Simon Urbanek
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>
>>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> [hidden email] 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: [hidden email]  Priv: [hidden email]
>
>
>
>
>
>
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Prof Brian Ripley
In reply to this post by Peter Dalgaard-2
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,                  [hidden email]
Emeritus Professor of Applied Statistics, University of Oxford

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: r-project.org SSL certificate issues

Peter Dalgaard-2
In reply to this post by Simon Urbanek
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>>>>
>>>>>> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi <[hidden email]> 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
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>> ______________________________________________
>>> [hidden email] 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: [hidden email]  Priv: [hidden email]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
12