11

I've been trying to provide security to my API.

I will issue certificates to my clients to access my API through a TLS channel. So it'll be a SSL-Client Authentication.

I'm wondering, should I use CRL on my server? Why?

Note: I'll use my own CA and communication will be between machines so a browser won't be used.

There is an exception for my question. Some day, if my ca root key is compromised, I can create a CRL list, add my old ca root key and implement to my server simply. So, please ignore this case.

An Image from Websense Community enter image description here

  • 6
    Let me tell you, there's a lot of percents in that pie... – Reinstate Monica Apr 20 '15 at 14:12
  • Thanks :) I guess 709,052 certificate had been revoked and this value must be 44% of the whole pie. But values seem a bit messy. – efkan Apr 20 '15 at 15:05
  • 2
    Oh, makes sense. I confess I simply interpreted that as a decimal separator (my locale normally uses the comma for that), so this meaning never occurred to me. – Reinstate Monica Apr 20 '15 at 15:11
16

First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks about a certificate C is something that comes from the issuer of C. Since a root CA has no issuer, it cannot be revoked.

In other words, if your root CA is compromised, you are in deep trouble. This is why people who are serious about certificates use a three-level structure:

  • A root CA is created and maintained on an offline machine, that is kept in a safe or some shielded room. It is powered regularly (say, on a monthly basis) to sign a CRL, but that's about all.

  • An intermediate CA is awarded a certificate by the root CA, as a one-time procedure.

  • All user certificates are issued by the intermediate CA.

If the intermediate CA is compromised (which is conceivable, since it is used often and thus is probably part of a network), then the root can still issue a CRL that revokes that intermediate CA.


That being said, you should consider that there are two PKI instances at work in your case. With SSL/TLS and client certificates:

  • The server owns a certificate, that the client validates.
  • The client owns a certificate, that the server validates.

These two certificates may live in separate world, issued by distinct CA.

For the server certificate, you need the client to have access to all information required to make sure that the server certificate is valid, and this includes regularly issued CRL or something equivalent (OCSP responses...). I suppose here that you do not issue that certificate yourself; instead, you buy an "SSL certificate" from some commercial CA, because the root CA is already distributed in all client systems, and that CA issues and publishes CRL.

Now let's see about the client certificates. These certificates are to be validated by your server. And you are also the one who will decide which certificates are to be revoked. In other words, any CRL here would be a mechanism by which you will agree with yourself. In that sense, this is entirely your business and you can fulfil that functionality in any way as you see fit. For instance, you could maintain, on the server, some SQL table that lists the thumbprints of client certificates that are to be rejected, and revocation would simply be adding an entry in that table. When you talk to yourself, you do not necessarily need to sign your mental messages !

Regardless, you still need the ability to revoke certificates, or something similar. At this point, you must understand that there is a difference between authentication (making sure that the client who talks to you is Bob) and authorization (deciding what Bob should be allowed to do). Suppose that Bob's private key is compromised:

  1. Since Bob's key may be in the wrong hands, you can no longer accept Bob's certificate as a proof of Bob's identity. That certificate should be "cancelled" in some way (e.g. revocation).

  2. Since certificate revocation is asynchronous, you also need a "fast block" system that will keep any purported Bob out of the system immediately. This is done on the authorization layer: you temporarily "disable" Bob's account, or set his access rights to "nothing".

  3. Bob is still Bob, though, a (possibly paying) customer. He will want to connect again, and it should work. Therefore, Bob's access rights will have to be enabled again. However, you should do that only when Bob has been issued a new certificate (with a new public/private key pair, of course) and Bob's old certificate is now rejected by your server.

Therefore, you really need, in all generality, a way to reject certificates that would otherwise look fine. Revocation is such a way; another one is to issue only very short-lived certificates (valid for, say, one week at most), but this requires pushing new certificates to clients on a daily or weekly basis, and client software is not necessarily up to such a task. The normal method is thus to issue long-lived certificates to clients (valid for one or a few years) and to maintain, on the server side, a mechanism that allows arbitrary rejection of certificates. Conceptually, that mechanism is as simple as having a list of "undesirable certificates" that the server consults. A CRL is a standard formatting for such a list, that the issuing CA signs to allow transport over unsecured mediums. However, as explained above, this list is to be transferred between your CA and your server, which may be the same machine, and do not necessarily need such a signature.

  • Thank you very much! This was really a great article. And a great guide for me. In my case I cannot work with a commercial CA (I guess) because my clients and I will not use a browser for communication. For instance a client will try a GET operation to here https://api.myDomain.com/clients/123/orders/ to get its open orders. After I've read your great answer I decided to; 1. Keep root CA in a safe 2. Protect intermediate CA 3. Use fingerprint 4. forget CRL for now. If I cannot implement a CRL to my application, then until I lost my intermediate CA I won't use a CRL. – efkan Apr 20 '15 at 14:55
  • 1
    @user3765109 You can use commercial CAs even with non-browser clients. Either you can access the system's list of trusted CAs (if there is one), or include the needed root CA(s) in your software (assuming you are controlling the client). – Paŭlo Ebermann Apr 20 '15 at 17:14
  • Why would a certificate revocation have to identify a "trusted source"? If I receive something signed with the public key identified in certificate X that says certificate X should be considered revoked, would it not be safe to say that either (1) someone with authority over that public key has revoked it, or (2) someone without authority over that public key has somehow acquired its private key? And shouldn't the certificate be considered invalid in any case? – supercat Apr 20 '15 at 17:36
  • @supercat: it turns out that the answer to your questions is "no", but it is a tricky one. It turns out (it was discovered in 2005) that given a signature value, it is possible to create a new key pair that matches that signature value over an arbitrary message m (not necessarily the one the signature s was computed over), and without knowing the private key that was used to produce s in the first place. See this article. – Thomas Pornin Apr 20 '15 at 17:42
  • Hi @PaŭloEbermann, Thank you. it seems useful. Mr. Thomas Pornin said too "These two certificates may live in separate world, issued by distinct CA." - I'm searching immediately. If I can accomplish then I will be get rid of a ton of work! – efkan Apr 20 '15 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.