This is a strange one. Over roughly about the past week my Outlook access to my ISP email, which uses SSL, has intermittently been failing on a security certificate problem, and has now gone solid in that it always fails to either send or receive messages on any of my accounts unless I bypass the certificate warning and tell it to go ahead anyway, then it works.
What makes it strange is that Gmail still works fine, suggesting it’s a problem with my ISP’s email. OTOH, when I set up Outlook on my laptop, it works fine, which suggests it’s a problem with my computer. The evidence is contradictory!!
But I think I finally figured out what is probably going on, though I don’t know what to do about it.
The specific error that occurs if I delve into the details is “The integrity of this certificate cannot be guaranteed” and the problem is indicated as a nonvalid digital signature. But, again, it works with Gmail and it works on my laptop.
But here is the clue: the certificate in question has a valid date of 11/5/2014 to 11/6/2016. So it was enabled about a week ago and that is precisely when the problem started happening.
The second clue is that this machine is still running Windows XP (SP2) and I now suspect that the problem is an outdated root certificate that isn’t validating the new one. And that Gmail, which also uses SSL, still works because Google is using a different certificate.
I understand all the issues with sticking with XP but there are important and valid reasons that I need to keep running this machine a while longer before migrating everything, so a lot of snark about an obsolete OS wouldn’t be helpful. My question to the brilliant minds on this board is, if this theory is right, how can I fix this? Is it reasonable to just try to update the appropriate root certificate? The one that the email server is using that I can’t authenticate is a Symantec Class 3 Secure Server CA - G4. There must surely be a relatively simple update somewhere that I can install for this?
I saw that, thanks, and I may indeed have to try it. I’m just a little worried that it apparently adds hundreds of new certificates and I really only need one, and that it could cause problems. I was hoping there might be a less drastic solution.
You can probably find that particular certificate online somewhere and import it with the instructions on this page or similar. If you tell me exactly which certificate it is you need, I may be able to export it from my Win8 machine (or maybe not; not sure if it’s backwards-compatible with XP).
But I don’t recommend that because the problem could pop up again in the future. You really SHOULD be keeping your certificate stores up to date anyway, because they get hacked every so often and CAs come and go. You want the latest certificates for safety. It’s not overkill, it’s a best practice.
Actually, don’t let me export it for you. You shouldn’t accept random root certificates from strangers online, even if it’s me. If you’re going to download that specific certificate, look for it from the issuer, Microsoft, Mozilla, or some other big giant company that you trust… not some random website.
No need to search online or for you to export anything, as the required certificate must obviously exist on my Windows 7 laptop since there are no problems there. I’ve enabled the certificates snap-in in MMC in Windows XP and I’m sure I can do the same in Windows 7, so all I have to do is figure out which certificate it is and I should be able to move it to the XP machine per your link. The only information I have is from Avast which complains about “Symantec Class 3 Secure Server CA - G4”, and I note from browsing the certificate store that there is a Symantec Root CA that expired several years ago, but there must be more than a hundred of them there in total.
This is turning somewhat nightmarish. I did confirm that my other newer XP machine with a fairly fresh installation of the OS has the same issue so it’s definitely related to the root certificate store. The annoying thing is that I found what should have been exactly the root cert I needed on the Symantec site here, and when I import the .cer file for “VeriSign Class 3 Public Primary CA - G4” and look at the details, the root certificate itself produces the same error “the integrity of this certificate cannot be guaranteed …” and “invalid digital signature”. This occurs on both machines, and it occurs with both the .cer file and the .pem file!!
I tried importing a different certificate at random from the same site, and that one installs and is deemed valid, but it doesn’t help as it’s not the one I need. Obviously the Win 7 system is using some other root cert because I can’t find that one or anything even similar in its cert store, but I have no idea which one it is. Sigh!!
Is there a reason you’d reluctant to try the Microsoft-packaged update?
And can you import the new root cert to your stores anyway? It can’t vouch for itself because it doesn’t know your public key to authenticate with, but maybe after you forcibly import it Outlook will shut up about the other cert.
Lastly, you can make Gmail fetch your ISP mail directly and that way Google deals with the certificates behind the scenes and you don’t have to.
Only because I was interested in understanding the problem rather than just getting it fixed. Anyway, I tried it on the fast computer downstairs on which I had created a quick restore point. It’s just a little 448 KB .exe that ran without any confirmations, messages or errors and seemed to create a bunch of new root certificates, many of which also had signature errors – and here we’re talking about a fairly new and little-used machine with a vanilla XP install! And it didn’t fix the problem. So I backed out via system restore, and back to square one.
It imported fine. But the certificate was deemed not trustworthy due to a signature verify failure, so no doubt that’s why it didn’t work.
I wasn’t aware of that. Interesting idea, but pretty much a desperate workaround, though.
FYI – for anyone else with this issue. SP3 fixes this problem, though it’s hard to understand why. It may indeed have to do with the encryption algorithms. I note that on the upgraded machine, none of the security certificates are listed as invalid any more.
