search

gbif / gbif-api

GBIF API
Apache License 2.0
27 stars 5 forks source link

Image API: Certificate issue with Agouti images #90

Closed peterdesmet closed 2 years ago

peterdesmet commented 2 years ago

The Agouti multimedia serves images for camera trap observations. Not all seem to be handled well by the GBIF Image API:

I originally reported this to @timrobertson100 and @MattBlissett and it seemed to be SSL handshake failure. There was indeed an issue in the certificate chain and have since removed a root certificate, put the issue persists. Is there some caching happening at the GBIF Image API that makes it difficult to debug or is there still an issue at Agouti's side?

peterdesmet commented 2 years ago

Report: https://www.ssllabs.com/ssltest/analyze.html?d=multimedia.agouti.eu&latest

MattBlissett commented 2 years ago

I think there's still an issue at Agouti's side, although I haven't seen this situation before so I'm not sure what the fix would be.

If you look in the Handshake Simulation section of the SSL Labs report, many of the entries are red with handshake_failure.

We're probably using OpenSSL 1.0.2k-fips (CentOS 7), which is one of the red lines.

It's possible the problem is the second (irrelevant and invalid, cameratrapping.net) certificate included, see under "Certificate ♯2".

yliefting commented 2 years ago

I will investigate further. It may have to do with the strict encryption settings (cipher suits) enforced by nginx on Agouti's side. Is there any chance you could test with OpenSSL 1.1.0 on your side?

The 2nd certificate will be removed in the near future, but that should not cause a handshake failure i think.

MattBlissett commented 2 years ago

I was testing from the CentOS 7 machine running our image caching/resizing server. Equivalent should be:

docker run -it --rm centos:7
yum install -y openssl
openssl s_client -connect multimedia.agouti.eu:443 -servername multimedia.agouti.eu -showcerts

It fails with an error there, but it works on my Ubuntu desktop with version 1.1.1f.

yliefting commented 2 years ago

Looks like openssl 1.0.2 is out of support since January 2020. Are you sure that's the version you're using? If 1.1.0 is working perhaps an upgrade on your side is the way to go?

I'm hesitant to downgrade the settings on our server, but if upgrading is not an option we can look for a combination of protocol and cipher suite that works for 1.0.2 and is secure.

MattBlissett commented 2 years ago

1.0.2k is the version supported by Red Hat / CentOS, presumably until CentOS EoL in 2024.

I'm not yet planning to upgrade our systems from CentOS 7, so I'd look for a workaround -- at least as long as SSL Labs reports so many handshake simulation failures.

Compare https://www.ssllabs.com/ssltest/analyze.html?d=www.gbif.org, which still has an A grade.

yliefting commented 2 years ago

Should be fixed now. I changed the setup a bit and the handshake should no longer fail.

MattBlissett commented 2 years ago

Thanks Yorick! Looks fine now.