Security and Code Signing Certificates
There are many things that you get not to worry about when using our products as opposed to rolling out your own.
One of them is: securely and reliably distributing plugins and keeping them up to date. This, turns out, is not an easy feat and is full of tricky details.
Code signing certificates are one such tricky detail, here we explain how we take care of them, and how an upcoming change might affect you.
What is a Code Signing Certificate?
Note: If you are familiar with the concept, feel free to skip this section, and head to How this might affect you.
The goal here is to introduce the topic in an accessible fashion.
Microsoft and other vendors use Code Signing Certificates to ensure authenticity and integrity of the software you use. That is, this helps ensure that you are using software from Publishers you trust and that such software has not been modified before reaching you.
But what are these Certificates really? Well, the way they work is that a Software Publisher like Camilion applies for a Code Signing Certificate to a Certification Authority (CA for short); this process has a cost and the CA performs several checks on the company and the people people behind it.
When the Certification Authority (CA) approves the application, they issue the Code Signing Certificate, which is composed of a public part and a private part which must be kept secret at all costs.
Such a certificate might look like this on your computer:
Note that Issued to contains the name of our legal entity (we are an S.L., which is a Society with Limited Liability based in Barcelona) and Issued by contains the name of a Code Signing Certification Authority.
This is used by Windows and other software to establish a so-called Chain of Trust (try it yourself!):
That is, Windows trusts the top-most certificate (also called a Root CA) and, each certificate signs (or trusts) the next certificate down the chain, until we reach ours. If such a Chain of Trust can be established, the “Certificate is OK” and will be trusted.
Should a publisher misuse their certificate, it will end up being revoked and they will have issues getting a new one in the future.
How this might affect you
So far so good, we have our own, valid Code Signing Certificates that are trusted by Windows.
Authenticode and SmartScreen
At least in theory! In the case of Microsoft and, particularly Windows and Office products, on top of the Chain of Trust there are a couple opaque systems called Authenticode and SmartScreen.
They assign reputation to a Certificate and/or a Publisher and it is quite unclear how this reputation is managed.
The general consensus amongst publishers is that there is some magic usage count and time period, after which these Microsoft-specific systems start trusting a new certificate.
Why is this important?
The longest validity we can get for a Code Signing Certificate is 3 years, which means changes are bound to happen.
For example, our current Certificate expires on March 11th 2022 and will not be valid after that.
We already got a new Certificate, but Authenticode and SmartScreen mean that that a new Certificate will not immediately be trusted, but instead its reputation will be built up over time.
Our mitigations and short-term plan
If you use our products already, our new certificate, along with that of the intermediate Certification Authorities will be deployed in the next few days. You won’t have to do anything. Software like Autodesk® Revit® or AutoCAD®, will trust our new certificate.
We will be publishing a new version of our plugins signed by both our old and new certificates, this will help establish reputation on the new certificate and also it gives you an extra ease of mind that it is still us going forward.
For some of our software (notably: AttMan), double signatures are not an option due to a limitation in the way their publishing works.
But worry not, we are publishing a new version for all our software where we make sure that a Timestamp Server is used. Using a Timestamp Server ensures that at the time of the signature, the certificate was still valid.
This means two things:
- Software like AttMan can still be used after March 11th 2022 because the Timestamp makes the signature valid, even after the certificate expires.
- We will not be able to update Software like AttMan until our new certificate has enough reputation.
How you could help
We are publishing our installer in two flavours:
- Doubly signed, with the old and the new certificate
- Singly signed, only with the new certificate
They are exactly the same, except for the signatures. By downloading and executing the installer that is only signed with the new certificate here, and telling SmartScreen that it is trustworthy (see also this post) the time necessary to establish reputation for the new certificate will be shorter.
Trying to avoid any kind of issues for you, we contacted Microsoft. If you want, you can read their reply:
"The warning you experienced indicates that neither the application nor the signing certificate had established reputation with Microsoft Defender SmartScreen services at the time. We can confirm that setup-newcert.exe is clean and since it has an established reputation while attempting to download or run the application it should no longer show any warnings. The signing certificate (ea97faaed47eefd53989bcf692d1286b5a786302) is still in the process of establishing reputation. Once it does, all applications that are signed with that certificate should have a warn-free experience from the start. Thank you for contacting Microsoft."
Conclusion
We have been planning this migration for months now and hope it will affect you as little as possible.
As you can see it is not an easy topic and certainly not one you want to take care of, so why don’t you let us do that for you?
Get in touch with us and let us discuss your workflow automation, integrations or customisations; we are here to help!
