Error: CAA JSON error: SSL handshake failed

MusicBrainz Picard
1

I know there are issues with CAA and no art is uploading but when in Picard everything I add has a red disc and the info says

CAA JSON error: SSL handshake failed

And no art work is showing up.

When I go into the debug log, I see it says index out of range for every song.

Unless you go into each song with something like Mp3tag and fix the tags, no album in Picard is not saving any songs.

I’m on the latest stable version and see old issues like this from 2016 and 2019.

Is the fix just to remove CAA as one of the corver art providers?

1 Like
2

Just started seeing this myself for the first time…I’m guessing API changes are to blame and Picard just needs to catch up maybe? No idea…that or a bad cert somewhere isn’t getting replaced?

Would like to know what can be done, I’ve been seeing it for a couple weeks now.

3

Still happening in late 2023, unfortunately. coverartarchive.org is serving an SSL chain containing LetsEncrypt’s old “DST Root CA X3”, which expired in September 2021.

[zlatko@disclosure:~]$ openssl s_client -connect coverartarchive.org:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=2:unable to get issuer certificate
issuer= O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
issuer= C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=0 CN = coverartarchive.org
issuer= C = US, O = Let's Encrypt, CN = R3
verify return:1
---
Certificate chain
 0 s:CN = coverartarchive.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
[...]

You won’t notice this in normal modern browsers, because they already have LetsEncrypt’s “ISRG Root X1” built into their certificate stores, so they stop verifying the chain at this point. You can simulate this on the CLI by adding the -partial_chain option:

[zlatko@disclosure:~]$ openssl s_client -partial_chain -connect coverartarchive.org:443
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = coverartarchive.org
verify return:1
---
Certificate chain
 0 s:CN = coverartarchive.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 work around this issue by applying the following local patch, which disables SSL verification, to picard:

[zlatko@disclosure:~]$ cat tmp/picard-2.10-ssl-verify.diff 
diff -pru picard-2.10-orig/picard/webservice/__init__.py picard-2.10/picard/webservice/__init__.py
--- picard-2.10-orig/picard/webservice/__init__.py	2023-10-12 08:54:36.000000000 +0200
+++ picard-2.10/picard/webservice/__init__.py	2023-11-14 14:59:39.548578751 +0100
@@ -174,6 +174,13 @@ class WSRequest(QNetworkRequest):
         # ssl.setCaCertificates(list())
         # self.setSslConfiguration(ssl)
 
+        # https://stackoverflow.com/questions/21636728/qt-ssl-handshake-failed
+        # https://doc.qt.io/qtforpython-5/PySide2/QtNetwork/QSslSocket.html#PySide2.QtNetwork.PySide2.QtNetwork.QSslSocket.PeerVerifyMode
+        # https://het.as.utexas.edu/HET/Software/PyQt/qsslsocket.html#PeerVerifyMode-enum
+        conf = self.sslConfiguration();
+        conf.setPeerVerifyMode(0);
+        self.setSslConfiguration(conf);
+
         # optional parameters
         self.parse_response_type = parse_response_type
         self.request_mimetype = request_mimetype
4

Thanks for the report. We are investigating possible solutions.

What is your openssl version (openssl version on command-line)?
Can you provide versions displayed in Picard About dialog?

2 Likes
5

We now only provide short chain for LE certificates, it breaks very old devices though (<=Android7.1) but it shouldn’t be much an issue now 6 years passed.
But it fixes OpenSSL 1.0.2 issue (and therefore your issue).

Can you confirm it works for you now without your workaround?

1 Like