Hi all,

I'm writing today to inform you that in March the current code signing certificate for Zettlr will expire. If you use Zettlr on Windows, this has a set of implications that you should be aware of. In this post, I want to elaborate on what this means, what I have to do, and what this means for your experience of using Zettlr on Windows.

Quick Summary: As soon as Zettlr's code signing certificate expires or as soon as I use a new certificate (which may be earlier), you will start seeing warnings that Windows doesn't trust Zettlr. It will warn you not to run the installer or app. However, as soon as I have a new certificate, you need to install the app despite the warning because this is how you can tell Windows that you trust our app, which will in turn make Windows trust it, and the warning will disappear over time.

What is Code Signing?

Code signing is a process by which some executable file (namely, computer programs) is certified to come from some known individual or organization. If a program is correctly code signed, this means that your computer can verify who created that program. If a program is not code signed, this means that your computer cannot verify the origin of the program, and thus prevent it from executing. Code Signing involves a certificate (similar to the SSL certificates that are used to secure websites) that is used to generate a signature for a program. Individuals and organizations can receive such certificates and use them to validate their own programs.

Note: Apple also employs code signing, but with some essential differences. If you are interested in what these are, see the end of the post.

Why Code Signing?

Code signing is the answer to the problem that, on the internet, nobody knows who you are. By requiring code signing, Microsoft essentially ensures that each program for Windows can be traced to a known individual or organization. This disincentivises malicious actors from writing viruses or other unwanted software, because if someone uses a code signing certificate to distribute malicious software, two things will happen. First, Microsoft can withdraw the certificate's “trust,” meaning that Windows will prevent execution of the program despite it being signed. Second, since each certificate is issued to an individual or organization and requires strict verification (including a check using a government-issued ID), the malicious actor can quickly be identified.

Why does Zettlr's Code Signing Certificate Expire?

Certificates essentially certify trust. You only receive a certificate after you have identified yourself, and being able to use a certificate usually implies that you are the one who uses it. To ensure that certificates cannot be used, e.g., after some company went out of business, to distribute malicious software under a wrong name, certificates have an expiry date. Typically, certificates are valid for one to five years. While the expiration date varies, each certificate will expire eventually. Zettlr's current code signing certificate has been issued three years ago, and thus is reaching its end of life.

What are the Implications For Windows Users?

As a Windows user, you are likely to experience some hiccups starting in March. Specifically, this is what may happen:

What I expect will happen is that, for a few weeks in March/April 2025, Windows will warn you that the (then-new) certificate is not yet trusted (because Windows hasn't seen many programs that use this new certificate). This warning will eventually go away, but only if users actually run the program despite the warning.
In the worst case (I am unable to secure a new certificate until March), each new update will make Windows warn you not to install the update because it won't be able to verify that it comes from us. Windows might even actively try to prevent you from running the app, even if you really want to.
In the best case (the new certificate is a more premium one that is immediately trusted), you will notice nothing. (The chances for this outcome are very slim.)

What is the Problem with Renewing the Certificate?

Now to the spicy part. In the past, renewing a certificate was as simple as paying several hundred Dollars to some company, waiting a bit, and then downloading the new certificate file. However, this is no longer possible. Microsoft has enacted a change in 2023 that now requires certificates used to sign software to be stored on especially secure hardware modules, called HSM (Hardware Security Module). You may have heard of such things, because this is essentially what a “YubiKey” is. However, in the context of software development, a YubiKey doesn't really help, because it is a physical device that is not available to, e.g., GitHub Actions. One can also use cloud-based HSM, and this is the only viable option for Zettlr to ensure the continuous signing of keys. The problem now is threefold.

This new requirement means added costs, since providers happily draw money out of my pockets for the “convenience” of storing certificates on their server.
It is not always clear which solution will enable me to continue signing Windows installers using our existing pipeline, as the documentation is often lacking details.
It is not yet fully clear how having to switch to cloud signing will integrate with the specific process Electron requires.

At the moment I am evaluating options. If you have knowledge on the process, please feel free to chime in and provide suggestions. Options I am currently considering are:

SignPath, which has a FOSS tier, and apparently supports cloud signing with no strings attached.
SSL.com, which I have used in the past seven years, but whose cloud-signing process (“eSigner”) costs basically as much as the certificate itself, essentially doubling my costs.

Other options (Sectigo, digicert) are either essentially equivalent but more expensive, or don't support HSM cloud signing (Assego Certum). What I do not want is two separate services (e.g., buy a certificate from SSL.com and then use Azure Trusted Signing to store it), because I am worried of losing the certificate if I spread my resources too thin between multiple offerings.

Final Thoughts

Essentially, my point from five years ago still stands, and I believe that, while I approve of code signing, how it is implemented is atrocious. Essentially you pay several hundred dollars for a few kilobytes of text file to some parasitic corporation with bad customer support, and now with the HSM requirement, you pay double because it's now a “service.” In the past seven years, I have paid several thousand dollars just so that Windows doesn't scare my users. Essentially, it's like paying hush money. But I don't make the rules.

Appendix: Apple Code Signing and Differences to Windows Code Signing

You may note that this post was only for Windows, but Apple employs code signing, too. As I mentioned above, I strongly believe that the process of code signing is a crucial building block for ensuring malware has a hard time to infect any computer – regardless of whether it runs Windows or macOS. However, Apple has – in my opinion – a reasonable approach to this. I pay about $100 each year to Apple, but with this subscription, everything is included – including a code signing certificate with 5 years of validity.

Furthermore, Apple does not require HSM storage for its certificates and immediately trusts its own certificates, meaning that for Apple users of Zettlr, literally nothing will change when the current certificate expires in February 2025. In fact, I have already instructed the build pipeline to use the new certificate. The only thing that can go wrong there is that I made an error, but that is easily fixable.