EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Certificate Chain

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#85
Posted: 04/28/2006 03:55:47
by Matthias Hanft (Basic support level)
Joined: 04/28/2006
Posts: 15

Hello,

I'm running a SSL server with Secure Blackbox. The SSL certificate is signed by "AddTrust" which is signed by "UTN". The UTN root certificate seems to be pre-installed in all Windows versions, however the AddTrust in-between certificate seems to be missing in some Windows versions. This doesn't matter in browsers like Internet Explorer because the complete certificate chain is sent by my server, and everything works fine.

You can check this with the URL:
https://wddx.hanft.de/ktopruef?un=demo&pw=demo&blz=89999999&kto=1234

But now, I have written an own client with Delphi, and I check the certificate in the IOHandler's OnCertificateValidate event as described in the help file:

procedure TMyObject.ValidateCert(Sender: TObject;
Certificate: TElX509Certificate; var Validate: Boolean);
var
myValidity : TSBCertificateValidity;
begin
FIOHandler.InternalValidate(myValidity, FValidateReason);
FValidateResult:=myValidity=cvOk;
Validate:=True
end;


and this leads to a "vrUnknownCA" error if the in-between AddTrust certificate is not installed in Windows.

What I miss is something like a "ValidateCertificateChain" property...?! Shouldn't happen this even automatically, like Internet Explorer does?

(I must confess that I'm using a SBB version of last year or so - as you know "never touch working programs" ;) )

Is there something I have overlooked?

Thank you and best regards

Matthias
#88
Posted: 04/28/2006 04:38:26
by Ken Ivanov (EldoS Corp.)

Quote
What I miss is something like a "ValidateCertificateChain" property...?! Shouldn't happen this even automatically, like Internet Explorer does?

Unfortunately, the only way to validate a chain at the moment is to process it manually (i.e., validate the first certificate, validate its issuer, validate its issuer's issuer and so on).

However, there's a corresponding item in our to do list. Certificate chain validator is planned to be published in one of the future build updates.

Quote
(I must confess that I'm using a SBB version of last year or so - as you know "never touch working programs" ;))

We recommend you to upgrade to the latest version. It contains a lot of new features, improvements and fixes (e.g., support for compression, PSK and Camellia cipher suites).
#95
Posted: 04/28/2006 08:16:16
by Matthias Hanft (Basic support level)
Joined: 04/28/2006
Posts: 15

Quote
Unfortunately, the only way to validate a chain at the moment is to process it manually (i.e., validate the first certificate, validate its issuer, validate its issuer's issuer and so on).

Ok, this seems to work. What would be the best algorithm? I have seen that, in my case, the OnCertificateValidate event occurs three times:

  • with the root certificate (UTN), Validity=cvSelfSigned (I guess this wouldn't even be necessary for the server to transmit?)
  • with the intermediate certificate (AddTrust), Validity=cvOk
  • with my own server certificate (wddx.hanft.de), Validity=cvInvalid, Reason=vrUnknownCA

So, I can save the 2nd certificate (*), and, when the 3rd event arrives, call 3rdCertificate.ValidateWithCA(2ndCertificate). This works, but can I rely on the server sending the certificates always in that "top-down" order?
On the server, I just use the property "ForceCertificateChain", but I cannot guarantee that all certificates are always loaded into the server CertStorage in the same order - so if the certificate transmisson order depends on the loading order, I had to switch to some other algorithm...

(*) BTW, "save"? Can I just save the object reference within the 2nd event which is still valid when the 3rd event occurs? Or do I have to create a locally saved copy of the intermediate cert?

Thank you & best regards

Matthias
#96
Posted: 04/28/2006 08:30:43
by Ken Ivanov (EldoS Corp.)

Quote
This works, but can I rely on the server sending the certificates always in that "top-down" order?

Yes. Certificates are always arranged from root CA to the end-entity certificate. That's why you can validate the sequence by simply validating each next certificate with the previous one.

Quote
On the server, I just use the property "ForceCertificateChain", but I cannot guarantee that all certificates are always loaded into the server CertStorage in the same order...

ElSecureServer internally re-arranges the certificates as needed. Sending a 'strict' chain is a requirement of SSL protocol, so you may rely on this ('top-down') order.

Quote
Can I just save the object reference within the 2nd event which is still valid when the 3rd event occurs?

No, you should create a copy. Please consider using Clone method to copy the certificate data:
CertCopy := TElX509Certificate.Create(nil);
Certificate.Clone(CertCopy);
#98
Posted: 04/28/2006 08:47:25
by Matthias Hanft (Basic support level)
Joined: 04/28/2006
Posts: 15

Quote
Yes. Certificates are always arranged from root CA to the end-entity certificate. That's why you can validate the sequence by simply validating each next certificate with the previous one.

Great! Last question for today (I hope :D ): Is it necessary to load the root (self-signed) certificate into the server's CertStorage (so the server will transmit it as first cert), or is it just sufficient to start with the intermediate cert?

Some experiments show that it should be sufficient to start with the intermediate cert, but I'd like to have this confirmed by the experts ;)

Thank you again!

Matthias
#99
Posted: 04/28/2006 09:41:00
by Ken Ivanov (EldoS Corp.)

Quote
Is it necessary to load the root (self-signed) certificate into the server's CertStorage (so the server will transmit it as first cert), or is it just sufficient to start with the intermediate cert?

To completely authenticate the server, the client needs the entire certificate chain (in *any* case). However, the server may omit one or more higher-level certificates if he is sure that every client connecting to him has these certificates on his workstation.

So, if the root certificate is present in the 'trusted root' store of all the clients connecting to your server, you may simply exclude it from the chain.
#100
Posted: 04/28/2006 10:45:06
by Matthias Hanft (Basic support level)
Joined: 04/28/2006
Posts: 15

The UTN root cert seems to be installed in every Windows version, so I think I can omit it from the cert chain. (It was just the goal of my programming that my client need not have an own root cert installed, but can rely on the regular Windows Update Root Cert Updates.)

Everything works fine now. Just one note: The IOHandler.InternalValidate function returns cvOk even when the Cert.ValidTo date is already expired. I would have expected Validity=cvInvalid and ValidateReason=[vrExpired]... or may this be a bug already fixed in the current version? (I promise to update all my software with the latest SBB version as soon as possible, but I'm already late finishing the current project...)

Matthias



#101
Posted: 04/28/2006 11:27:31
by Ken Ivanov (EldoS Corp.)

Quote
Just one note: The IOHandler.InternalValidate function returns cvOk even when the Cert.ValidTo date is already expired. I would have expected Validity=cvInvalid and ValidateReason=[vrExpired]... or may this be a bug already fixed in the current version?

Hmm, it's quite strange. Does InternalValidate return this incorrect result for each certificate in a chain or for some particular certificate?
#102
Posted: 04/28/2006 12:00:25
by Matthias Hanft (Basic support level)
Joined: 04/28/2006
Posts: 15

Quote
Does InternalValidate return this incorrect result for each certificate in a chain or for some particular certificate?

I have just tried it with the "WDDX2005-2006" certificate which has expired on March 21, 2006 (you can download it from http://www.hanft.de/WDDX2005-2006.cer if you like to have a look at it).
Before using it, I have installed the issuer's Comodo intermediate cert into the Windows system cert storage so that there is no "chain" in this case, and there is only one ValidateCert event (which returns cvOk).

Matthias
#103
Posted: 04/28/2006 12:18:00
by Ken Ivanov (EldoS Corp.)

Thank you. We will try to reproduce the error in our conditions.

Actually, you may also try to validate the certificate by calling the Validate method of certificate store you are using instead of calling InternalValidate.
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 8580 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!