Question about IceSSL

[OrNot]

hi, there,
IceSSL plugins provide users powerful tools to communicate in a security mode and users do not need to cope with the low level operations on ssl. But now I have to do something about PKI creation and management and therefore need some information about the certifications. Howerver I don't know how to get it from the IceSSL. If it is necessary for the client to send its certification explicitly without the intervention of the IceSSL here? Althouth the chapter "IceSSL" has a section "c++ programing with icessl", however it seems too simple and there isn't a java counterpart.
BTW: when will the c# icessl be released?


Cheers
OrNot

[matthew]

With the current SSL plug-in you cannot do this. However, we've done alot of work on the plug-ins for the upcoming 3.1 version. Among some of the new stuff we've added is the ability to get at the content of the certificate. 3.1 will also contain a C# SSL protocol plug-in.

Since you are asking: What information do you need to get from the certificates? What form would you like the certificate in?

[OrNot]

In our curernt project, our boss now wants a PKI/CA module integrated into the orginal system. I am investigating these techniques. As my understanding to our system, maybe a mini PKI/CA is enough. one thing I want to do is to get the certificate from client to verify if it has been revoked. Acturally due to my poor knowledge on PKI/CA so far, I am even not sure if this is feasible.
Summarily, I want to implement a PKI/CA system which will be based on the IceSSL and hope it can seamlessly integreate the icessl.
BTW again: when will the 3.1 be released? I am so excited by its new features.

[matthew]

In our curernt project, our boss now wants a PKI/CA module integrated into the orginal system. I am investigating these techniques. As my understanding to our system, maybe a mini PKI/CA is enough. one thing I want to do is to get the certificate from client to verify if it has been revoked. Acturally due to my poor knowledge on PKI/CA so far, I am even not sure if this is feasible.

Do you already have certificates available for the clients? How to plan to manage the certs? For example, use a commercial service? Or roll your own? What exactly do you want to authenticate? For example, the client? The server? Or both?

For revocation you can check the expiry date of the certificates easily enough (actually this is done automatically for you). However, if you want to revoke a valid certificate then you need to maintain a certificate revocation list on the server. The exact details on how to do this depend on the language you are using (C#, Java or C++ -- and thus OpenSSL).

Summarily, I want to implement a PKI/CA system which will be based on the IceSSL and hope it can seamlessly integreate the icessl.
BTW again: when will the 3.1 be released? I am so excited by its new features.

We don't have a 3.1 release date planned yet. We're busy implementing the new features

[OrNot]

Good catch! . Here we may face two situations in client ends. One is that the clients have no certificates initially and need to request one from the server and then install it for later use. So does I need to establish a tcp connection at first for the CSR and then switch to ssl when certs installed? Another situation is that a Smart-card or Usb-Key is used to authenticate the user identities, that is , the certs is assumed to be available already. Of course this depends on the issue policies.
In the server end, we want to implement our own CA. The Java stuff seems a not bad choice. Since PKI/CA is an additional module , we want to not change the orginal architecture too radically ( there a User/password mechnism is used).
Because a broker pattern is used, which is very similar to what Mark described in his instructive article of issue11, the final architechure may be like this:


client(C#)<-ssl-->Broker(C++)<--tcp-->CA(java)

When a client sends its cert to broker, broker can verify its validity include the expiry date with IceSSL, but as you said, if this cert has been revoked needs to ask CA. So I want to get some info from certs. To setup a CA, I think it is possible that a user has to intervene to IceSSL , isn't it?
In Chapter "IceSSL", most parts of it are focus on the IceSSL configuration. Could you pls give some sections on how to set up a PKI based on IceSSL?

Thank you very much.

[matthew]

To help you more I need to understand your requirements. What exactly do you want to know on the server side? And what exactly do you want to know on the client side?

A number of things that you have suggested above are very questionable. For example, a client "requesting" a certificate. This is rather uncommon, since you have no idea about the identity of the requesting client.

Running a CA really has nothing to do with IceSSL. This is the procedure of issuing, distributing and managing X.509 certificates which has nothing to do with IceSSL

[OrNot]

hi, Matthew
Sorry for my poor expressions about my questions. It may be better that I ask a specific question about Icessl.
Now I want to take part in the certficate verifying porcess in c++ server end point. I read the source codes and it seems that I can implement a CertificateVerifierOpenSSL class and override the verify method and then set this class as the verifier. Within this method, I can comunicate to a CA to check the CRL to verify the validity of the cert from client. Is it right? The DefaultCertificateVerifier and SingleCertificateVerifier seem to be two samples, but because without further document about them, I dare not to go ahead. Could you please give some more advice? a code segment will be great appreciated. (BTW: Is it possible to do above with Java IceSSL ?)
The second question ,perhaps stupid, is: if ,say, 3 clients of different certs but issued by a same CA are communicating to my server, do I need to have all the three certs installed in my server' trust store , or only the issuing CA 's cert is enough? Sorry for this silly question but I am not very sure about it.

TIA

[matthew]

If at all possible I would avoid doing too much custom stuff with the 3.0 SSL plug-in. We have complete re-written the plug-in for 3.1, and this stuff is different and much simpler.

However, if you really want to go ahead then, yes, you need to derive from CertificateVerifierOpenSSL, and implement verify. Then you can do whatever steps are necessary to determine whether you accept or reject the connection.

How the CRL's are actually used is implementation specific. For example, you can ignore them (ie: no CRLs). Or you can publish CRL lists to your server hosts on a regular basis, so no RPC is necessary.

The second question ,perhaps stupid, is: if ,say, 3 clients of different certs but issued by a same CA are communicating to my server, do I need to have all the three certs installed in my server' trust store , or only the issuing CA 's cert is enough? Sorry for this silly question but I am not very sure about it.

It depends on your application requirements. In general, on the server you only need the CA certificate and the CRL (if you are handling CRLs). Once you get a certificate you:

- check the chain length (length 2 typically)
- the root certificate of the chain is in the trusted CA list.
- The second certificate in the chain is signed by the CA.
- The certificates have not expired.

Sometimes your applications have different requirements. For example, its not enough that the certificate is signed by the CA. Your application only accepts connections-from or connects-to applications that use a particular set of certificates signed the CA.

Many clients have this restriction -- that is they only want to connect with a given server.

[OrNot]

Thank you very much .