Re: Signature validation in certificates

Hi Geetha:

Certificate Validation is explained in detail in RFC3280 (and, more up to
date, RFC5280).

More replies inline:

On July 9, 2008 03:17:56 am Geetha_Priya wrote:
>
> A root certificate [signed by CA] comprises of version, serial num,
> issuer and subject details, public key algorithm details and a signature
> which is hash of the rest of cert details further encrypted using
> private key. This root cert is installed by browsers automatically. The
> web servers have their certificates signed by these CA.
>
No - a Root certificate is a self signed certificate - usually belonging to a
Certificate Authority, but possibly made up by Bob in accounting. In order to
find out if you trust this certificate, you have to either:

1) Explicitly trust it, because it came with your browser, and you trust
Microsoft, Mozilla, Apple, Opera, or the KDE folk.

2) Make an informed trust decision, and go through some process to decide what
to base your trust of this Certificate on. This usually means to find out the
Certificate Authority that is represented by this certificate, read the
certificate policy that this certificate was issued under, and ask them to
produce an audit result from a recognised auditor that they are complying
with their certificate policy.

>
>
> When a https site id accessed , the server sends a server certificate
> that contains most of the above details (except for changed subject
> name/validity etc.)along with the signature and a RSA public key
>
>
Well, the server sends a certificate that has the Subject name as the name of
the server, and the Issuer as the name of the person or organisation that
signed the server's certificate. There may be LOTS of other details
included - see RFC5280 for the full list. The full function of verifying
validity is called Path Discovery and Validation (PDVal for short)
>
> Now for certificate validation:
>
>
>
> First we verify the credentials of issuer/common name etc.. that is
> clear to me
>
>
This is actually the last step - you only want to match the Subject to your
access control list. The issuer is only used to figure out whether you can
trust the assertions made in the certificate.
>
> Second step is to match the signature which I find a lil confusing
>
The signature is verified by taking the public key of the Issuer (usually
found in the Issuer's certificate) and doing a signature verification
function on the hash of the Subject Certificate contents.

Sometimes, the Root (also called a trust anchor, or trusted root) signs the
subject certificates itself:

ROOT -> Subject

It's likely though, that to get to a root, there may be a chain of
verifications to do:

ROOT -> Intermediate CA -> Subject

There may be also a complex trust fabric to follow to get back to a root that
you trust: