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 .

Dirk

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

http://www.cacert.org/certs/root.crt

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:

http://wiki.cacert.org/FAQ/BrowserClients

And then you could follow the advice given…

 

How I typically Solve my Kleopatra Start-Up Delay Problem

Both under Linux and under Windows, I use “Kleopatra”, which is a GUI for the ‘GnuPG’ system – the “GNU Privacy Guard”. In case the reader does not know, GnuPG or ‘GPG’ is one software alternative for providing ‘Public Key Cryptography’, which can be used in practice to sign and/or encrypt emails, as well as to validate digital signatures made by other people’s computers.

Using GPG does not strictly require that we use Kleopatra, because there exists the capability which some power-users have, to use GPG from the command-line, and Kleopatra is a distinctly KDE-based front-end, even though there exist Windows ports of it.

One problem which I eventually run in to, and which has been reported elsewhere on the Internet, is that at first after installation, Kleopatra seems to run fine, but that after some point in time we encounter a strange delay, when we start up this program, which can last for several minutes or even longer, during which the program does not respond properly to user commands. Our GPG installation does not seem to be compromised.

In my case, this seems to take place entirely, because Kleopatra has been instructed to check the revocation status of some certificates, but no ‘OCSP Server’ has been specified in its settings. According to some other reports on the Web, this is a problem specific to “CACert” certificates, and in my case also, the problem seems to set in, after I’ve added a CACert certificate to my key-ring. Yet, AFAIK, this problem could just as easily occur after we’ve added other certificates.

The way I eventually solve this problem – on every computer I own – is to open Kleopatra somehow, and then to go into Settings -> Configure Kleopatra -> S/MIME Validation , and then to look at the field which says “OCSP responder URL”. By default, this field will be blank.

Since in my case the problem starts after I’ve added my CACert certificate, I actually add the OCSP Server which is provided by CACert there, which is currently “http://ocsp.cacert.org/”. After that, I find that when I open Kleopatra, a narrow and subtle progress-bar in the lower right of the application window, sweeps to completion within one second, and the program opens fine.

I need to explain why this solution works for me, so that anybody who may be having the same problem, but not with a CACert certificate, can also solve this problem.

Certificates which are not self-signed, are signed by a ‘Certificate Authority’, such as CACert. When Kleopatra starts, one of the functions which it automatically performs is to check its certificates against a ‘Revocation List’, in case the Certificate Authority has decided to revoke it.

The actual certificate which I received from CACert, has the detail encoded into its plain-text data, that its revocation status must always be checked. But what I’ve found happens with Kleopatra specifically, is that if no OCSP Server has been specified, instead of somehow recognizing the fact that it cannot check the revocation status, this program goes into some type of infinite loop, never actually connecting to any server, but also never seeming to exit this state.

I choose to put this OCSP, because in my case, I know that it is the CACert certificate which has this need set with a high priority. It should be possible to put some other OCSP Server into the same field, because ultimately they should all be synchronized. But finally, the OCSP Server provided by the same Certificate Authority, also provides the fastest response time, for validating its own certificates.

As I see it, there was a problem in priorities somewhere, in programming this application. There was the bureaucratic priority, which states that the status of this certificate must always be checked. but then there was also the programming priority, which states that an attempt to connect to a server, without any specification of which server, will lead to some sort of malfunction eventually. And between these two, the bureaucratic priority won out.

There are some people on the Web who choose to solve this problem, by simply deactivating the feature, of online revocation checking. This can be done within the same settings tab, by unchecking the first check-box in that tab. This check-box is located directly before the setting, to “Check certificate validity every Hour” (on my setup, with a drop-down window set to “hour”). I prefer to let my software do everything it’s supposed to do, including to check the revocation status of my certificates. And the way to do the latter is to specify an OCSP Server. The fact that this problem can apparently be solved both ways, affirms the quality of the programming.

Dirk