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:

Trusted Root -> Bridge CA -> Other Root -> Intermediate CA -> Subject (Server

Finding out about all of these is called "Trust Path Discovery".

Once you have a path to a trusted anchor (root), then you have to (as a

Verify Validity periods of all certificates in the chain (Valid Before, Valid
Until fields)

Verify if any of the Certificates have been revoked (By Checking CRL and/or
OCSP - watch out - these are also signed artifacts, and you have to perform
PDVal on them too - and it may be recursive

Verify the Key Usage and Extended Key Usage Fields.

Make sure that you process all critical fields in all certificates.

Validate that the certificates were issued according to a certificate policy
that you trust, or one that maps to a certificate policy that you trust.

Verify that everyone is respecting their policy and name constraints.

This is called Path validation.

Most of these functions (but not all) are handled by the "openssl verify"
command. If you have a simple trust fabric, then you should be able to use
this command to verify certificates.

If you are writing code to do this, then I would recommend not doing it
yourself, and just using the X509_verify() functions that are built into

For some more information on the basics of PKI, and explanations of most of
what certificates are and how they work, you can see our "FingerPuppet" howto
guides to PKI:


Have fun.

Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org