local certificate error accessing the cloud

[Ulrich Bertl]

Hello,

I recently ran in to the problem getting a certificate error trying to sync with the cloud. (Windows 10 64bit, Subsurface 5.0.3) I did reset the Password but I'm now getting this error message

"Das Zertifikat des Ausstellers eines lokal gefundenen Zertifikats konnte nicht gefunden werden"

I have to mention that direct asscess over Webbrowser and access with the mobile version with the mobile phone (Android) does still work.

Since the error message states there is a local error with the certificate - Is there a way to delete/reset/refresh/renew the local certificate?

-> Thank you Dirk for your very quick answer and checking that it is not a server issue!

Thanks for your help

Uli

[Dirk Hohndel]

I wonder if you are being hit by the Let's Encrypt Root Certificate expiration.

Can you point a browser on your Windows machine to https://valid-isrgrootx1.letsencrypt.org/

does the certificate on that page get recognized?

Thanks

/D

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/2f27a105-29c4-4e72-a95f-afc21e7e71ecn%40googlegroups.com.

[Ulrich Bertl]

Yes, Let's Encrypt certificate is recognized on the machine

Thanks

Uli

[Dirk Hohndel]

Hmm - I almost never use Windows, I need to play with this some more in a VM to try to figure out where

that odd error actually comes from (it's not one of our error messages). It very much sounds like it is about

an issue in the certificate chain...

More things to add to the TODO list :(

/D

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/08414e27-6cdb-4163-b743-bf4b8664fe91n%40googlegroups.com.

[Jef Driesen]

Some browsers have their own CA certificates, instead of using the ones
available on the operating system. So the fact that a browser accepts the
certificate is maybe not the best test? I don't know whether Qt uses the OS
certificates on Windows or not.

[Dirk Hohndel]

That's my concern as well. I simply suggested what Lets Encrypt themselves suggest...

I'll try to prioritize this higher and get to it at some point today

/D

[ch...@oak-wood.co.uk]

I'm hitting a similar issue I think. And in both Windows 10 (Subsurface 5.03) and Ubuntu Xenial (Subsurface 4.9.3), although I haven't actually looked at the Ubuntu logs (not sure where they are), so it's possible it's a different issue manifesting with the same symptoms. This is from the W10 logs

returning cloud URL "https://ssrf-cloud-us.subsurface-divelog.org/git/chris@**k[chris@**k]"
Opening cloud storage from: "https://ssrf-cloud-us.subsurface-divelog.org/git/chris@**k[chris@**k]"
Received error response trying to set up https connection with cloud storage backend:
"The issuer certificate of a locally looked up certificate could not be found"
git storage: Waiting for cloud connection (2 second(s) passed)
git storage: Waiting for cloud connection (3 second(s) passed)
git storage: Waiting for cloud connection (4 second(s) passed)
connection test to cloud server https://ssrf-cloud-us.subsurface-divelog.org/ failed QNetworkReply::SslHandshakeFailedError "SSL handshake failed" 0 ""
failed to connect to any of the Subsurface cloud servers, giving up
git storage: Cloud connection failed

Both systems seem OK with the letsencrypt root on the whole. But I am also having an issue with the Owncloud client against a LetsEncrypt certificate, and that seems to consider the ISRG X1 cert to be issued by the now expired DST Root CA X3 certificate.

[Andreas Rosland]

I would have checked if the CAbundle here includes certs that has expired. As the testssl.sh script also reports chain of trust errors on this domain.

./testssl.sh -S cloud.subsurface-divelog.org | grep Chain
Chain of trust NOT ok (expired)

[Andreas Rosland]

This is definitely a client (as in your OS) problem.  But it seems that you can help some clients using the correct CA certs with making sure the old X3 cert (or R3 created by this) is not part of the CAbundle.  It should be very few clients that does not have the X1 CA cert at all. It most likely the client OS just choose the wrong one. 

[Dirk Hohndel]

I had only a couple of minutes to look into this, but it appears on Windows, in order to force it to update the OS cert chain, you have to use a Microsoft browser to go to https://valid-isrgrootx1.letsencrypt.org/

If you do this with Edge or (yuck) ie, that appears to trigger an update of the system cert chain. And at least with the one VM on which I was able to test this, I then had to reboot in order for Subsurface to see the new certs (which seems... odd)

Ulrich, which browser did you use to check the root cert?

/D 

-- 
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/e40993a5-7bb6-4caa-825e-def932c23190n%40googlegroups.com.

[ch...@oak-wood.co.uk]

I can confirm that this worked for me on Windows 10, and without the need to reboot.

There does seem to be a difference in server config though and I'm still struggling with Ubuntu.

openssl s_client -servername valid-isrgrootx1.letsencrypt.org -connect valid-isrgrootx1.letsencrypt.org:443 reports a short chain:

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = valid-isrgrootx1.letsencrypt.org
verify return:1
---
Certificate chain
 0 s:/CN=valid-isrgrootx1.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1

But on the same client

openssl s_client -servername ssrf-cloud-us.subsurface-divelog.org -connect ssrf-cloud-us.subsurface-divelog.org:443

Adds an extra level, ending in an expired certificate:

depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
---
Certificate chain
 0 s:/CN=ssrf-cloud-01.subsurface-divelog.org
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

I can't for the life of me work out why though :(

[Ulrich Bertl]

I actually tried it with all 4 browser - means Firefox (which I typically use), chrome, ie and edge getting everywhere the same positive result.

This is on a Laptop which I use already for quite some time productive for Subsurface.

I also tried it on a different Windows10 64bit machine (desktop), and got interestingly actually the same error message/behaviour.

I can test it on Wednesday also on a Linux/Ubuntu machine (if that helps)

[Ulrich Bertl]

OK, update - I just gave it another try to be sure through all 4 browsers and a reboot at the end and this time it fixed the problem ;-).

Thanks to everyone for the solution

[ch...@oak-wood.co.uk]

On my old Ubuntu Xenial the following sorted the problem:

Edit /etc/ca-certificates.conf and change the line

mozilla/DST_Root_CA_X3.crt

to

!mozilla/DST_Root_CA_X3.crt

then run update-ca-certificates

Seems the presence of the expired DST_Root_CA_X3 in the certificate store caused it to be looked at and validation to fail. Remove it and the system is happy to rely on the ISRG Root X1

[Dirk Hohndel]

Thank you so much for sharing that!

I wouldn't have thought of that solution (of course, Xenial is a bit old at this point...) :)

/D