IceSSL and revocation list (CRL)

grembo

Hello,

I've been wondering if IceSSL supports using a CRL (for glacier2, unix), the only option I could find was for .NET, which doesn't help in my scenario. Patching iceca so it provides the necessary openssl commands is easy enough (revoke certificate, export CRL), which basically alters $ICE_CA_HOME/ca/db/index.txt (changing cert to revoked) and creates $ICE_CA_HOME/ca/db/crl.pem (in my scenario).

It seems like there is no configuration option for setting a CRL file in IceSSL (couldn't find anything in the docs and no trace of the usage of one in the sources).

We're running a CA for the use of glacier2 and wondering what can be done out of the box, and what functionality is missing.

1. Verify validity of the certificate
2. Revoke certificates
3. Check IP/DNS name in cert (also see my separate post about this)

The SSL specific part of our glacier2 configuration is:

Ice.Plugin.IceSSL=IceSSL:createIceSSL
IceSSL.DefaultDir=certs
IceSSL.CertAuthFile=ca_cert.pem
IceSSL.CertFile=ca/db/ca_cert.pem
IceSSL.KeyFile=ca/db/ca_key.pem
IceSSL.CheckCertName=1

Client certificate validation works as expected, not certain about expiry and CheckCertName has no effect at all.
It would be great, if there was a configuration option like IceSSL.CRLFile (so you could e.g. set IceSSL.CRLFile=ca/db/crl.pem), which might also provide a default value and also use the already existing configuration option IceSSL.CheckCRL to toggle the use (algorithm should be: If IceSSL.CheckCRL and not (defined(IceSSL.CRLFile and readok(IceSSL.CRLFile)) => barf();).

In general I would be willing to create patches to IceSSL adding functionality, but I would need some hint where to start and how to make sure I won't break portability or violate general design principles of IceSSL.

/Michael

matthew

Are you authenticating your remote clients using certificates? It so, I would recommend not modifying Ice at all. If the default behavior offered by Ice does not meet your requirements, you can implement whatever you like in your implementation of the Glacier2::SSLSessionManager. You can find some detail in section 39.6 of the Ice manual. The interfaces themselves can be found in slice/Glacier2.

grembo

Yes I do low layer authentication of clients using IceSSL. I just think that revocation lists are so fundamental to dealing with client certificates, that this is a feature that should be in IceSSL itself (and not just for Glacier2 which is not always useful + not having 1000 different implementations of a basic feature done over and over again).


(I am aware of SSLSessionManager in Glacier2, I just don't think that this is a very user friendly solution)

matthew

The problem with CRLs are there are at least 1000 different methods of dealing with them, and every organization seems to deal with them in a slightly different manner. As such, we haven't felt it is possible to make Ice deal with CRLs in any sort of standard manner. Hence we provided hooks into IceSSL itself, and the Glacier2 authentication layer so that you can deal with it in whatever way that you see fit.

grembo

At least for unix implementations it seems like you're using all openssl anyway, which generates a crl.pem file which is used by most services.

An alternative would be to supply this as some kind of util/example/whatever icebox service that works out of the box, therfore avoiding users of ice to implement such a critical service on their own (I'm thinking of people just SSL enabling existent services with very little experience mastering openssl's insanity).

Btw, is there a comprehensive list of what IceSSL checks and what not? Just looking at the code for a minute it seems like the only it checks is if the client cert has been signed by the ca_cert (so it's not even checking the certificates validity period) - or have I'm mislead and this is basically done implicitely in the call into openssl?

matthew

Ice for C++ uses OpenSSL (and therefore so do the other products based on Ice for C++). As for what is checked, there is no comprehensive list. OpenSSL checks the certificate validity, among other things.

Personally, I don't think the way OpenSSL manages CRLs (and in fact, the entire certificate store) is very intuitive, well understood or, I suspect, widely used. I strongly suspect most organizations manage their certificates in some other way, such as custom database. This suspicion is further backed up by the fact that you are first person who has asked for this support

Given that most organizations manage their certificates, and things such as CRLs, in very different ways I don't think its possible to write such an authentication service in a way that satisfies the majority of customers. This is why we put the hooks into Ice that allow you to write whatever authentication service that you want.

grembo

Hmm I just think having iceca to issue but not revoke certificates is suboptimal, so I somehow disagree.

Then again, it's your product so I'll have to deal with it

Hmmm thinking about this, maybe this could be implemented like a reverse IceSSL.TrustOnly rule, so you can just specify on CN etc. which certificates not to trust - this would basically CRL agnostic and would fit most people's needs - normally you don't revoke certificates that frequently.

Then again, of course you could just state all allowed certificates based on CN in the TrustOnly configuration (if this could be extended to allow different CNs to be specified?). That would be the perfect solution for small deployments (especially because giving a positive list is much safer then maintaining a revocation list).

About being the first to ask for that, I'm not certain how people actually revoke certificates (you only ever do that, if you don't control all participating hosts or suspect a security breach somewhere).

matthew

My suspicion is that most small organizations also don't issue CRLs. They simply delete the offending certificate from the database, and then they certify the entire cert chain, not just the root signing cert.

As to your comment with TrustOnly, you can already specify more than one entry by separating the elements with a ';'

ie:

IceSSL.TrustOnly.Client=CN="matthew";CN="alex"

The problem I have with this scheme is that it forces you to restart your servers each time you make a change to the list. If this isn't an issue for your deployment, then it is a decent solution.

Hmmm thinking about this, maybe this could be implemented like a reverse IceSSL.TrustOnly rule, so you can just specify on CN etc. which certificates not to trust - this would basically CRL agnostic and would fit most people's needs - normally you don't revoke certificates that frequently.

Thanks! This is quite a good idea. We'll consider this.

grembo

Do you have any status update on implementing this idea (IceSSL.Untrusted or similar)?

mes

Hi,

The syntax for IceSSL.TrustOnly properties has been enhanced in Ice 3.4 to add support for rejection. You can read more about these properties here.

Regards,
Mark