I’ve just redone my code signatures today.

One of the habits which I have in my life is, first to undertake a programming project, then to make sure it works, and finally to post some of it on my blog, where I can tell people ‘what I did, to make the project work’. As a result, some of my postings point to a ‘binaries page’, which has the following URL:


What gets shown is a table of contents, from which it’s virtually impossible to intuit what each compressed file is actually about. However, individual posts which link there, usually state, which compressed file resulted from the exercise.

Later, I got the idea to compile some of those projects, on behalf of readers who may not know how to do so, AND, to compile a subset again, to run under Windows.

What makes this tricky is the fact that, under Windows, people like me are obliged to put code signatures onto executables. My code signature only identifies me positively, as the author of the program. It doesn’t, by itself, guarantee, that the user won’t get the scary Windows defender message, when he or she double-clicks on the file-icon.

What makes this even tricker with the type of certificate I chose (to use, to sign the .EXE Files), is, that each certificate expires after one year. Even if readers did download the bundles before yesterday (May 12, 2021), the code would absolutely refuse to work, after May 25 this year. Thus, I need to buy a new certificate, and anybody who might want to keep using my programs, also needs to re-download them.

As of today, I have re-signed all the .EXE Files, with a newer certificate, which will ‘only’ expire after May 13, 2022. So, my readers may proceed, if they have used my program(s), and wish to continue doing so.


(Update 5/14/2021, 14h30: )

Just to be exact, the certificate which I actually used, has the Serial Number ‘154a757a67e7fd31188adce1474afadc‘.




How to verify the signatures, within GnuPG Certificates, from the command-line.

I found this to be a very specific question, with inadequate documentation elsewhere on the Web, and so I’m writing my own observations on it here. First of all, the reader should know what a certifiicate is, as opposed to just, ‘a public key’. A public key goes together Mathematically with a private key, so that either will decrypt what the other enrcypted, but in such a way that, if the public is made aware of the public key alone, they are unable to derive the private key.

This does not just get used for encryption, but also to sign documents or other electronic assets. In fact, if the RSA algorithm is being used for encryption, it may already be somewhat out-of-date, because many Web sites that have an ‘httpS://’ URL, use TLS by now, instead of SSL, the latter being insecure by today’s knowledge. However, while Diffie-Hellman key exchange is suitable for encryption, creating a shared secret between the server and client, that in turn can be used as a strong, symmetrical key for a connection, the actual verification of Web-sites still uses RSA. But, that’s a bit of an aside comment, because we’re not interested in this posting, in certifying Web-sites with an X.509 certificate. This posting is about ‘GnuPG’, which is an alternative to ‘X.509′.

A certificate is what one obtains, when a public key belonging to one person, together with certain mandatory information, is signed, using the private key of another, so that the public key of the other person can be used to validate that signature. This is important because, if there were only a public and private key, the recipient of a (signed) document would have no way of knowing, whether a public key he’s been given, actually belongs to the correct author. He’d just know, that it’s the public key associated with an arbitrary private key, where the two are supposedly already matched as they should be.

Conversely, if a person wanted to encrypt a document being sent to another, then he’d have no way of knowing, that he’s encrypting it using the correct public key. The person who has the corresponding private key, might not be the intended recipient.

Because of the signature of the public key with another person’s key-pair, that person’s attestation to the fact that it belongs to its rightful owner, can add trust in the public key, for the recipient of a signed document, or the sender of a document to be encrypted, the latter so that only the holder of the correct private key will be able to decrypt it.

So, it can happen to users of GnuPG, that they’ve been using GUIs such as ‘Kleopatra’ or ‘KGPG’, that these GUIs have not displayed any messages, but that they’d like to verify the signatures of their public keys, belonging to other people anyway. And from the command-line, there is a way to do that…

(Updated 5/24/2020, 8h35 … )

Continue reading How to verify the signatures, within GnuPG Certificates, from the command-line.

CACert has tightened its access rules.

One fact which I have sometimes blogged about, is that I am a member at CACert.org. This is a certificate authority which has been surrounded by some controversy. Its use is for members to be able to secure their servers, by obtaining an SSL certificate, i.e. obtaining an httpS:// URL, without having to pay money to do so.

What happens in the industry, is that each httpS:// URL is secured via encryption – in such a way that only the server and browser can decrypt the data – but that every Public Key used, needs to be signed by a Certificate Authority using their Private Key. There exist Certificate Authorities who charge big money for this service, to Web-masters. CACert offers this for free.

But for a variety of reasons I won’t go into here, CACert is already not included in most Web browser root certificates. In order for any signing chain to be possible, eventually the ‘top’ of the signing chain needs to be a root certificate, which is already ‘known to’ and ‘bundled with’ the browser, and which the browser automatically trusts.

A decision which a user can make however, is to add root certificates to the browser manually, and to tell the browser to trust those, at his own risk – OF perhaps having data tapped in to, which he is exchanging with the server he wants this secure connection to.

Long story short, in order for anybody to open the CACert Web page itself, which is the link I included above, the user now needs to have not only the CACert root certificate installed, but additionally needs to have their Class 3 certificate installed. Because I only had their root CA installed on some of my browsers, I recently failed to open the link, to their actual site, and spent some time troubleshooting what was causing this. They have tightened the security, with which their own site can even be accessed, always to revert back to the httpS:// version of the URL, prior to which we need to have these two certificates installed, for their page to open.

As it happens, in order for my own httpS:// URLs to open, I only need to have their root CA installed, but I cannot access their site, unless I have both CAs installed. This might sound as though convenient, but in fact is not so.

If I wanted to invite other people to access my httpS:// URLs, I would also need to invite them, to install the root CA from CACert. But in practice, the only way I can do this ethically, is to direct them to the CACert site, as above. I would never try to redistribute their root CA, myself.

And their site will not open on your browser anymore, unless you have done the research, and installed both these CAs yourself.

So this mechanism is now limited, to giving me private access, to certain parts of my own site.

But I am relieved, that CACert has not itself been hacked – so far. It was a bit hard for me to determine what the difficulty was, but it did not turn out to be any sort of hacking, of CACert.org .


(Edit : ) What I can do in a case like this, is to suggest some http:// URL to you, such as


And I could tell you, to use that URL to provide access – to my site and not to CACert. But, you would have no way to trust this URL, coming from me. Doing so would be just as non-secure for you, as it would be, if I simply transferred the cert to you directly. What I can do, is suggest a WiKi page to you, which belongs to CACert.org, like so:


And then you could follow the advice given…