Gang,
Those of you who managed to push past Windows/Microsoft's worries about the signing of unknown code with an unknown certificate will have then hit a "Error: 8" report.
Error 8 is: "Downloaded update failed Authenticode verification"
I have been SUPER CAREFUL to prevent the possibility that anyone might subvert GRC's server and place a malicious SQRL app there. So the EXISTING instance of SQRL that performs the self-upgrade first downloads the candidate newer release as a non-executable filename then verifies not ONLY that the file is properly signed, but that it is signed by DigiCert. The certificate issuer it looks for is: "DigiCert SHA2 Assured ID Code Signing CA". And ONLY IF the certificate's issuer exactly matches that, will the old SQRL decide that it can trust the new SQRL, and it will step aside.
The problem is, not only do I have a new certificate, but I have a fancy new hardware-token signed EV certificate. And, guess what? It comes with a fancy DIFFERENT certificate issuer! <sigh> The new one is signed by: "DigiCert EV Code Signing CA (SHA2)". As we can see... this will FREAK OUT the existing Release #64 of SQRL (or anything earlier) since it won't know anything about that... and it will issue an "Error: 8" and FOREVER refuse to update to that newer release.
This is an "auto-updater" block. So (and I'm REALLY SORRY about this!) but EVERYONE is going to need to arrange to manually download and run the latest release #65 of the SQRL.exe which is NOW on the server here: https://www.grc.com/dev/sqrl.exe (4/21/2019 3:35 PM). The earlier releases did not know about the newer code signing certificate.
When you run THAT executable on a machine having release #64 or #65, it will see that it's a later release and it will update that machine... and all will be good from then on.
Those of you who managed to push past Windows/Microsoft's worries about the signing of unknown code with an unknown certificate will have then hit a "Error: 8" report.
Error 8 is: "Downloaded update failed Authenticode verification"
I have been SUPER CAREFUL to prevent the possibility that anyone might subvert GRC's server and place a malicious SQRL app there. So the EXISTING instance of SQRL that performs the self-upgrade first downloads the candidate newer release as a non-executable filename then verifies not ONLY that the file is properly signed, but that it is signed by DigiCert. The certificate issuer it looks for is: "DigiCert SHA2 Assured ID Code Signing CA". And ONLY IF the certificate's issuer exactly matches that, will the old SQRL decide that it can trust the new SQRL, and it will step aside.
The problem is, not only do I have a new certificate, but I have a fancy new hardware-token signed EV certificate. And, guess what? It comes with a fancy DIFFERENT certificate issuer! <sigh> The new one is signed by: "DigiCert EV Code Signing CA (SHA2)". As we can see... this will FREAK OUT the existing Release #64 of SQRL (or anything earlier) since it won't know anything about that... and it will issue an "Error: 8" and FOREVER refuse to update to that newer release.
This is an "auto-updater" block. So (and I'm REALLY SORRY about this!) but EVERYONE is going to need to arrange to manually download and run the latest release #65 of the SQRL.exe which is NOW on the server here: https://www.grc.com/dev/sqrl.exe (4/21/2019 3:35 PM). The earlier releases did not know about the newer code signing certificate.
When you run THAT executable on a machine having release #64 or #65, it will see that it's a later release and it will update that machine... and all will be good from then on.