No more code-signing options
Posted: 2017-12-26, 23:37
It is with great disappointment that I have to announce this, but our code-signing of Windows binaries will come to an end in January 2018.
For a number of years we have supplied Pale Moon with digital signatures attached to the executables themselves on Windows (Authenticode signing), which allowed users to verify that the installer or updater was actually officially supplied by me and unaltered, which would also show in the UAC (User Account Control) prompt when performing administrative tasks (with the exception of setup.exe which due to technical limitations was never signed in the packaging process).
We've been able to do this thanks to the flexible service offered by StartSSL who have reliably issued certificates for this purpose after Identity Verification of me as an individual (Class 2 IV).
Because of the relentless pursuit by mainstream browser vendors after their newly-acquiring parent company WoSign caused them to become distrusted on all platforms, despite immediately taking action to separate from WoSign and starting a re-validation process as a trusted CA, StartCOM and StartSSL have now been forced into foreclosure with no ability to extend or issue new certificates for code signing. They will effectively terminate as a CA because of continued resistance to get themselves re-authorized after a lengthy verification process.
This means that a different code-signing certificate vendor was looked for. Unfortunately, the list of available options for individual developers is extremely short, as code-signing certificates are only issued by the mainstream Certificate Authorities to registered organizations which have gone through either an Organization Validation (OV) process or Extended Validation (EV) process, neither of which are available to individual developers (and are very expensive due to the insurance backing that comes with such certificates). IV is only available as a rare exception and requires notarized documents of a nature I cannot provide, as I found out when attempting to get a certificate from Comodo.
This brought me to the only available option left for me as an Open Source developer: Certum (by Asseco Data Systems SA). This is a CA based in Poland offering a special class for Open Source developers with a simplified validation process similar to what StartSSL required. I've gone through this process with them, getting a cryptographic card for 2-factor code signing (the only option they offer) and a certificate issued to me as an Open Source Developer by them (at substantial cost to purchase the hardware and certificate), to find out after a number of headaches and lots of trial and error that their card reader/driver/management software only allows code-signing using SHA-1 signatures. SHA-1 is not an acceptable digest algorithm for signing, since it is not strong enough to prevent tampering and cannot sufficiently guarantee the authenticity of the file. As such, modern versions of windows require SHA-2 based signatures (SHA-256). As far as I can tell, their driver/software and/or card reader simply do not support SHA-256, which makes their code-signing certificates completely useless for any developer.
I tried contacting Certum about this, but after their previous assistance getting the certificate issued which required some back-and-forth with their helpdesk, they simply ignored my attempts at contacting them with this issue. I tried contacting them 3 times over the last month with 0 response, and can only conclude at this point that they are aware of the issue and do not wish to provide assistance or updates or any sort of solution or compensation for selling me a pig in a poke (a "cat in a bag"). I'm therefore also extending a warning to any Open Source developer out there looking for code-signing to not consider Certum to be a CA they can trust to deliver usable code-signing certificates.
Having crossed the one viable CA for code-signing left off the list, this leaves me with one option: We will no longer code-sign our windows executables with an authenticode certificate.
To be able to verify the authenticity and integrity of our binaries, we will continue to provide both secure hashes for downloads (SHA256 checksums) and PGP/GnuPG cryptographic signatures (.sig) for all binaries (both Windows and Linux). Windows and some antivirus packages may complain about software not being authenticode signed any longer, but there is simply no option left for us to make this happen at this time; and not for lack of trying.
I hope this announcement has sufficiently clarified the situation.
For a number of years we have supplied Pale Moon with digital signatures attached to the executables themselves on Windows (Authenticode signing), which allowed users to verify that the installer or updater was actually officially supplied by me and unaltered, which would also show in the UAC (User Account Control) prompt when performing administrative tasks (with the exception of setup.exe which due to technical limitations was never signed in the packaging process).
We've been able to do this thanks to the flexible service offered by StartSSL who have reliably issued certificates for this purpose after Identity Verification of me as an individual (Class 2 IV).
Because of the relentless pursuit by mainstream browser vendors after their newly-acquiring parent company WoSign caused them to become distrusted on all platforms, despite immediately taking action to separate from WoSign and starting a re-validation process as a trusted CA, StartCOM and StartSSL have now been forced into foreclosure with no ability to extend or issue new certificates for code signing. They will effectively terminate as a CA because of continued resistance to get themselves re-authorized after a lengthy verification process.
This means that a different code-signing certificate vendor was looked for. Unfortunately, the list of available options for individual developers is extremely short, as code-signing certificates are only issued by the mainstream Certificate Authorities to registered organizations which have gone through either an Organization Validation (OV) process or Extended Validation (EV) process, neither of which are available to individual developers (and are very expensive due to the insurance backing that comes with such certificates). IV is only available as a rare exception and requires notarized documents of a nature I cannot provide, as I found out when attempting to get a certificate from Comodo.
This brought me to the only available option left for me as an Open Source developer: Certum (by Asseco Data Systems SA). This is a CA based in Poland offering a special class for Open Source developers with a simplified validation process similar to what StartSSL required. I've gone through this process with them, getting a cryptographic card for 2-factor code signing (the only option they offer) and a certificate issued to me as an Open Source Developer by them (at substantial cost to purchase the hardware and certificate), to find out after a number of headaches and lots of trial and error that their card reader/driver/management software only allows code-signing using SHA-1 signatures. SHA-1 is not an acceptable digest algorithm for signing, since it is not strong enough to prevent tampering and cannot sufficiently guarantee the authenticity of the file. As such, modern versions of windows require SHA-2 based signatures (SHA-256). As far as I can tell, their driver/software and/or card reader simply do not support SHA-256, which makes their code-signing certificates completely useless for any developer.
I tried contacting Certum about this, but after their previous assistance getting the certificate issued which required some back-and-forth with their helpdesk, they simply ignored my attempts at contacting them with this issue. I tried contacting them 3 times over the last month with 0 response, and can only conclude at this point that they are aware of the issue and do not wish to provide assistance or updates or any sort of solution or compensation for selling me a pig in a poke (a "cat in a bag"). I'm therefore also extending a warning to any Open Source developer out there looking for code-signing to not consider Certum to be a CA they can trust to deliver usable code-signing certificates.
Having crossed the one viable CA for code-signing left off the list, this leaves me with one option: We will no longer code-sign our windows executables with an authenticode certificate.
To be able to verify the authenticity and integrity of our binaries, we will continue to provide both secure hashes for downloads (SHA256 checksums) and PGP/GnuPG cryptographic signatures (.sig) for all binaries (both Windows and Linux). Windows and some antivirus packages may complain about software not being authenticode signed any longer, but there is simply no option left for us to make this happen at this time; and not for lack of trying.
I hope this announcement has sufficiently clarified the situation.