Not sure, after what MP3Tag update that happened: When searching for an album on MusicBrainz, I get this error: >0: SSL Error: WINHTTP_CALLBACK_STATUS_FLAG_SECURITY_CHANNEL_ERROR internal error
Strangely enough, I can search for and download cover art on MusicBrainz.
I tried even to upgrade to the Beta-Version 3.35-beta.3 (Win 64bit) to no avail.
Any suggestions on what to try?
Thanks!
It’s working fine here, can you please try again.
Thanks for your answer, Florian. This has been going on for a few weeks now, and I just checked - it’s still happening.
As for SSL: TLS 1.2 is the maximum I can provide.
Maybe installing an older version helps - how can I get one from half a year and one year ago (or two with major stepstones)?
Thanks!
I don't think that it's related to a change in Mp3tag. Here is v3.32 from Nov 2025 for you to try.
Are you using a VPN?
Hi Florian
No VPN, just plain and simple direct connection to my FritzBox.
Thanks for the previous version - unfortunately, it did not solve the issue: still the error with MusicBrainz album search, whilst MusicBrainz cover search works flawlessly.
I'm using Windows Home Server 2011 with all updates, that had been available - that's where my music resides, where I run Asset UPnP and MinimServer and where I tag everything with MP3Tag (via remote desktop from my MacBook), if this info is if any importance.
I just hope, that I get it working again. MusicBrainz has been a most valuable tagging ressourcen!
Thanks for your continued help & support!
The script for musicbrainz uses HTTPS, the script for Cover art uses HTTP.
Is the certificate still valid?
Is the PC's time correct?
Thanks Florian
Yes, time and date are correct, I even set the clock to another time-server, just in case.
As for the certificate: I don’t know, how to check. Is there a way to renew it?
Open cmd as administrator:
certutil -store root
Hi Florian
Thank you, I entered the command as advised.
This found 14 certificates, they all look similar to this, with different "Aussteller" values
And: there are 3 certificats, whose "Nicht nach"-Value show earlier dates like 1999 or 2004
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Windows\system32>certutil -store root
root
================ Zertifikat 0 ================
Seriennummer: xxxxxxxxxxxxxxxxxxx
Aussteller: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
Nicht vor: 18.03.2009 12:00
Nicht nach: 18.03.2029 12:00
Antragsteller: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
Signatur stimmt mit dem öffentlichen Schlüssel überein.
Stammzertifikat: Antragsteller stimmt mit Aussteller ĂĽberein
Vorlage:
Zertifikathash(sha1): xxxxxxxxxxxxxxxxxxxxxx
Keine Informationen ĂĽber den SchlĂĽsselanbieter
Das Zertifikat und der private SchlĂĽssel fĂĽr die EntschlĂĽsselung wurden nicht ge
funden.
There's no change to the MusicBrainz album query.
So, what do I do now to renew or update certificates, in case that is the culprit?
Just a quick note: I am not Florian; I am just another MP3tag user.
I mentioned HTTP and certificates because you specifically pointed out the differing behavior between various scripts, and the "secure connection" factor was clearly the distinguishing element.
However, I am far from being an expert on all the technical nuances involved; I simply listed a few of the usual suspects.
Normally, Windows automatically renews root certificates. However, you are using a version of Windows that Microsoft stopped supporting with updates back in 2016. In my opinion, connecting such an operating system to the internet is too risky anyway.
Otherwise, you should try to narrow down the problem:
Have you tested whether secure sites (HTTPS) - independent of MusicBrainz - can be accessed successfully at all? For example, you could try Discogs, or simply visit the MusicBrainz website or other sites via HTTPS in your browser to see if the same problem occurs there.
The fact that this doesn't appear to be an MP3tag-specific issue is supported by the fact that I, for instance, have absolutely no trouble using the official MP3tag MusicBrainz script.
By the way, have you checked if TLS 1.2 is enabled for the client? To my knowledge, MusicBrainz requires TLS 1.2 for client access.
I’ll bow out of further troubleshooting here, as my limited knowledge isn't sufficient for a detailed technical discussion - especially since I’m not familiar with your home server setup at all. Once you’ve confirmed that it is indeed an HTTPS-related issue, you should look for information outside of this forum.
For the browser, you'd have to use one that ships with your version of Windows, not sure if this would be Edge or still Internet Explorer in your case. Other browsers often come with their own SSL implementation and are not relying on WinHTTP.
@poster Thanks for the explanation and sorry for addressing you wrongly!
I know, that WHS2011 has not been supported anymore for a longer time - and that it's not really advisable to continue using it. Unfortunately, right now, some of the software (f.e. the automation for batch ripping CDs with an older CD Robot model) only works on that machine. So I am in a bit of a pickle.
As for the tipps checking Internet Explorer's https capabilities:
I can reach the https page of discogs, but not musicbrainz. Some other normal https sites also can't be accessed via IE, despite having TLS 1.2 activated.
That might explain, that dbpoweramp since a few weeks ago does not provide the complete variety of results from the wide selection of META-providers (even the ones I paid for) I had activated and I was used to receive. Need to doublecheck that, again.
Since this is just a recent behaviour, I am not sure, what had changed on my WHS2011 machine that caused that and whether there's a way back - or a correction.
Thanks again for trying to help me in the matter!
Did you change to the 64 Bit Version recently?
@poster No, I have always been on 64bit.
But, just this very moment I can provide an update how I got it to work!
Since I regularly do system backups, I just tried, what happens, if I restore my C-Drive to the December 2025 backup. I could make MusicBrainz work, again!
The installed MP3Tag Version at that date was 3.30.
Then I installed V3.32, that @Florian had provided: MusicBrainz produced the https error, again.
From my backup, I could restore the V3.30 program folder: no more https-errors.
So, there must have been a change between V3.30 and V3.32, that causes that https-error on my old WHS2011 system.
I will now restore my C-Drive back to the current backup, and then just try to get it working with V3.30 of MP3Tag.
@Florian If you would like to do me a big favour, could you please provide me with the 64bit downloads of 3.30 and 3.31? I will happily try to install those and give feedback about the outcome. Maybe, this helps other users with older systems, as well...
P.S.: I'm a step further - there is a musicbrainz.src configuration file in the data/sources subfolder. Even if I update MP3Tag to the current V3.35 of MP3Tag and replace its musicbrainz configuration file with the one from V3.30, then I don't get https errors.
I don't know, what changes have been made, and if I can use that old configuration file with the current version without causing errors, though. Just thougt, I'd mention that...
It's most likely related to this change:
[2025-11-05] CHG: MusicBrainz Tag Source: complete rewrite to use JSON input instead of XML.
I've switched from using http://... URLs to https://... URLs with the rewrite. You can try replacing those in the current MusicBrainz.src and see if it works for you.
I replaced all 3 instances of https with http and now MusicBrainz works with your new json rewrite!
Thanks a lot!