SSL certificate problem: certificate has expired

[saezlab]

SSL certificate problem: certificate has expired

[deeenes]

Hi,

This is a new error, as new as today's day. Somehow old certificates stuck in the server cache, sorry about that. Now it should be fine.

Best,
Denes

[deeenes]

Hi, I am not experiencing this issue at the moment. However around 30-31 Oct there might have been a delay in the renewal of our server's certificates, I got an email notice about it. Currently our certificates are valid until December. Does the problem still persist for you? If so, what is your operating system? What is the output from this:

library(httr)
i <- GET('https://omnipathdb.org/queries/interactions', verbose(info = TRUE))

[gl-007]

Output from your lines of code is:

*  Connection 11 seems to be dead!
*  Closing connection 11
*    Trying 178.62.7.222...
*  TCP_NODELAY set
*  Connected to omnipathdb.org (178.62.7.222) port 443 (#12)
*  ALPN, offering http/1.1
*  Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
*  successfully set certificate verify locations:
*    CAfile: /etc/ssl/cert.pem
*    CApath: none
*  TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  TLSv1.2 (IN), TLS handshake, Server hello (2):
*  TLSv1.2 (IN), TLS handshake, Certificate (11):
*  TLSv1.2 (OUT), TLS alert, Server hello (2):
*  SSL certificate problem: certificate has expired
*  stopped the pause stream!
*  Closing connection 12
Error in curl::curl_fetch_memory(url, handle = handle) : 
  SSL certificate problem: certificate has expired

Running R 4.1 on Mojave

R version 4.1.0 (2021-05-18)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib

[deeenes]

I think the operating system or some other software might have cached the old certificate. This kind of issue is discussed for example here: https://discussions.apple.com/thread/7833017. They suggest to manually delete the expired certificate, forcing the system to obtain the new one:

if you want to delete the certificate , open keychain access via spotlight under category click on view > show expired certificates , take cursor on top menu bar > click on edit > delete

I would recommend to delete all expired certificates. Alternatively, you can always disable SSL from your side for these specific requests: https://stackoverflow.com/a/62154211/854988

[ajwilk]

Experiencing same issue as described in OP. Manually deleting all expired certifications and disabling SSL has not resolved the issue.

> library(httr)
> i <- GET('https://omnipathdb.org/queries/interactions', verbose(info = TRUE))
*    Trying 178.62.7.222...
*  TCP_NODELAY set
*  Connected to omnipathdb.org (178.62.7.222) port 443 (#0)
*  ALPN, offering http/1.1
*  Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
*  successfully set certificate verify locations:
*    CAfile: /etc/ssl/cert.pem
*    CApath: none
*  TLSv1.2 (OUT), TLS handshake, Client hello (1):
*  TLSv1.2 (IN), TLS handshake, Server hello (2):
*  TLSv1.2 (IN), TLS handshake, Certificate (11):
*  TLSv1.2 (OUT), TLS alert, Server hello (2):
*  SSL certificate problem: certificate has expired
*  stopped the pause stream!
*  Closing connection 0
Error in curl::curl_fetch_memory(url, handle = handle) : 
  SSL certificate problem: certificate has expired

R 4.0.3 on Mojave

[deeenes]

In between, was there a period when it worked, and then the issue returned again? Or was it broken all along?

[al2na]

i also have this issue, any help is appreciated. Just updated the package from the github as well, which did not resolve the issue.

[deeenes]

Hi Altuna,

This issue is not OmniPath or OmnipathR specific, the ultimate reason is the expired root certificates in your machine's operating system. Assuming that the curl R package uses the OS certificates – I couldn't find information either confirming or refuting this.

The SSL certificate of omnipathdb.org is valid and renewed every couple of months:

echo | openssl s_client -showcerts -servername omnipathdb.org -connect omnipathdb.org:443 2>/dev/null | openssl x509 -inform pem -noout -enddate
notAfter=Feb  8 01:12:45 2022 GMT

We can check whether other applications and other servers manifest the same issue. What if you open https://omnipathdb.org/ in Safari? What if you try to access it by curl?

curl -Lo /dev/null 'https://omnipathdb.org/'

What if you do the same with a different webpage using the same certificate provider authority as omnipathdb.org? There is actually a webpage exactly for testing this: https://valid-isrgrootx1.letsencrypt.org/ You could try to open it in Safari, and download by curl:

curl -Lo /dev/null 'https://valid-isrgrootx1.letsencrypt.org/'

We know that one root certificate of the Let's Encrypt authority expired and has been renewed around last September (https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/). Apparently certain OSX systems did not update their root certificates since then.

I doubt that the curl R package has anything to do with it, but you could also try updating that:

install.packages('curl')

I believe the most likely solution could be to add manually the valid root certificate (ISRG Root X1) to your OS list of trusted certificates. Here the certificate is available in self-signed pem format: https://letsencrypt.org/certificates/. This answer describes how to update a single certificate: https://apple.stackexchange.com/a/429778/129946 Actually here the instructions seem to be clear and simple: https://docs.certifytheweb.com/docs/kb/kb-202109-letsencrypt/#macos-ios-etc

Another possibility that libcurl built software in OSX do not use the root certificates from the OS, but the ones in /etc/ssl/cert.pem. I've just found a resource suggesting this: https://security.stackexchange.com/a/232446, and I think the solutions suggested there are likely to work for you. You can also check if you have the valid and the expired certificate in that file:

grep 'ISRG Root X1' /etc/ssl/cert.pem # (valid)
grep 'DST Root CA X3' /etc/ssl/cert.pem # (expired)

Note, a comment below the above linked post tells that the solution is as simple as deleting the expired certificate from /etc/ssl/cert.pem.

I hope this helps, I would be very glad to see this issue tackled.

Best,

Denes

[deeenes]

Now it's already clear that all SSL related issues are due to missing the ISRG Root X1 certificate (which means that the certificate store of your OS is older than 6 years). The solution is to update the OS or add the certificate manually.

[al2na]

Great!! Thanks for the help!!

On Thu, Apr 21, 2022 at 4:21 PM deeenes ***@***.***> wrote: Now it's already clear that all SSL related issues are due to missing the ISRG Root X1 <https://letsencrypt.org/certificates/> certificate (which means that the certificate store of your OS is older than 6 years). The solution is to update the OS or add the certificate manually. — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE32ENEKTVNRT6H7XPVHRLVGFP7ZANCNFSM5HEEEKXQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Sent from mobile, excuse the brevity

[sigven]

Now it's already clear that all SSL related issues are due to missing the ISRG Root X1 certificate (which means that the certificate store of your OS is older than 6 years). The solution is to update the OS or add the certificate manually.

Hi,

I have tried to resolve this for my client/OS today, but even after adding the ISRG Root X1, i still struggle to get the certificate right. Accessing https://omnipathdb.org gives me the following messsage:

Is this still something on my side, or could it be server-related?

Accessing https://valid-isrgrootx1.letsencrypt.org/ works fine for my client.

kind regards,
Sigve