EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Self-signed certificate

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#12532
Posted: 02/22/2010 10:02:56
by Ken Ivanov (EldoS Corp.)

Quote
In that case I would drop the validation and get the required values out of the certificate only... I need to get the NodeID from the certificate, that's all I need to know.

This will make your system insecure. Anyone can generate a self-signed certificate containing the needed NodeID and authenticate to your server with it. That's why all the valid copies of self-signed certificates of your clients must be available to your server locally. Using a CA simplifies this question (only a CA certificate should be available for your server in this case, all the end-entity certificates can be validated using that CA certificate).

Quote
What, if I put the received certificate into a memory storage, assign this to ClientCertStorage (in server case) or CertStorage (in client case) and call InternalValidate?

What exactly do you mean by the "received certificate" term? If the certificate was received before connecting (via e-mail, XEnroll or other means that guarantee its integrity), this is a correct way for checking the authenticity of the peer. If "received certificate" is the certificate returned to you by the OnCertificateValidate event, it would be a short circuit (as you called it).

Quote
What do I need more for self-signed certificates?

The only guaranteed way to validate the peer that returns a self-signed certificate is to compare the certificate received during TLS negotiation to the "correct" copy of the original certificate of that peer. As I said above, anyone is able to generate self-signed certificates containing any desired information (that's why they are actually called self-signed -- no one is responsible for their content).
#12533
Posted: 02/22/2010 10:27:06
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Quote
This will make your system insecure.

I know, I know :) This is just an intermediate solution, until the final CA based thing is up. The primary (and necessary) purpose of the certificate is not just to authenicate the client, but more to carry the required information (NodeID).

Quote
If "received certificate" is the certificate returned to you by the OnCertificateValidate event, it would be a short circuit (as you called it).

That's what I meant :) But your answer did raise another question: Let's say, the enrollement server would supply a signed certificate to each node in the overlay out of band (which is one of it's central tasks, AFAIK, but I don't have a reference and don't know much currently about the realisation of the enrollement server up to now). Say, I would stuff this "issued cert" into the storage, apply this to either CertStorage or ClientCertStorage and call client/server InternalValidate: What would I have won? What degree of trust would I have reached?

Thanks for your efforts.
Regards
#12534
Posted: 02/22/2010 10:52:07
by Ken Ivanov (EldoS Corp.)

Quote
Say, I would stuff this "issued cert" into the storage, apply this to either CertStorage or ClientCertStorage and call client/server InternalValidate: What would I have won? What degree of trust would I have reached?

There is no need to add the issued (i.e. end-entity) certificate to the CertStorage or ClientCertStorage. Instead, the CA certificate should be added. Then InternalValidate() will be able to validate all the certificates directly issued by this CA. Thus, the plus in this case is that you do not have to maintain the list of all client certificates locally. Instead, you only keep the CA certificate and use it to validate all the certificates issued by this CA.
#12535
Posted: 02/22/2010 11:27:05
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hmm. I'm confused. I'm sorry for being so dumb, but I don't even have the complete picture. So let me summarize, what I have to do:

Ok, so every node has to add the server certifcate to a memory store, add the received certificate (received is meaning the certificate given in OnValidateCertificate), apply the store to ClientCertStorage (server side) and CertStorage (client side) and call InternalValdiate()?
#12536
Posted: 02/22/2010 11:58:07
by Eugene Mayevski (EldoS Corp.)

Quote
neil young wrote:
Hmm. I'm confused. I'm sorry for being so dumb, but I don't even have the complete picture.


Try reading a book or two regarding PKI. This topic lists really good books about PKI and certificates.


Sincerely yours
Eugene Mayevski
#12537
Posted: 02/22/2010 12:36:00
by Ken Ivanov (EldoS Corp.)

Quote
Ok, so every node has to add the server certifcate to a memory store, add the received certificate (received is meaning the certificate given in OnValidateCertificate), apply the store to ClientCertStorage (server side) and CertStorage (client side) and call InternalValdiate()?

PKI infrastructure assumes organization of the certificates belonging to it in a tree. The root of the tree corresponds to the root CA certificate, the leaves correspond to end-entity certificates. The intermediate nodes of the tree correspond to intermediate CA certificates. Validation of any certificate belonging to the PKI consists of sequence of validations of each certificate forming the path in a tree (or chain) from that certificate up to the certificate of the root CA. Each intermediate certificate in this chain is validated by checking the correctness of the signature applied to this certificate by the upper CA.

The purpose of InternalValidate() method is to validate a chain using certificates contained in the CertStorage/ClientCertStorage storage. Roughly, this method does the following:
a) Takes the certificate received from the peer (the one passed to the OnCertificateValidate event) and searches for its immediate parent in the CertStorage/ClientCertStorage storage. If such parent is found, the integrity of the certificate signature is checked. Otherwise, cvInvalid/vrUnknownCA result is returned.
b) Then it takes the immediate parent of the received certificate and, in turn, searches for its immediate parent in the CertStorage/ClientCertStorage property. If such parent is found, the integrity of the immediate parent's certificate signature is checked. Otherwise, cvInvalid/vrUnknownCA result is returned.
c, d, ...) and so on, until the root certificate is reached.

That is, you do not have to add the certificate passed to OnCertificateValidate event to the CertStorage/ClientCertStorage storage. Instead, you should prepare this storage before connecting by adding the certificates constituting the chains from the certificates of the peers you need to validate up to the root CA certificate(s).
#12539
Posted: 02/22/2010 14:26:11
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Thanks for the detailed answer, Innokentiy.

Quote
a) Takes the certificate received from the peer (the one passed to the OnCertificateValidate event) and searches for its immediate parent in the CertStorage/ClientCertStorage storage. If such parent is found, the integrity of the certificate signature is checked. Otherwise, cvInvalid/vrUnknownCA result is returned.

Exactly here I have a missing link: The method I'm talking about, is server.InternalValidate() (or client.InternalValidate()) This method has two parameters: ref Validity, ref Reason. I can't see how the "certificate received from the peer" is provided to the function. Therefore I was thinking, the certificate has to be provided to the server/client be using CertStorage/ClientCertStorage.
#12540
Posted: 02/22/2010 15:04:00
by Ken Ivanov (EldoS Corp.)

The received certificate (certificates, to be exact, as the peer may provide not only a single certificate, but a complete or incomplete chain) is cached by the component. So InternalValidate() does have all the necessary information to be able to perform validation.
#12541
Posted: 02/22/2010 15:27:47
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Ahh, that was the missing information.

Thanks again for your exellent support, Eugene and Innokentiy!!

Regards
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.

Reply

Statistics

Topic viewed 4196 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!