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 Cert) 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 minimum): 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 OpenSSL. 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: http://www.carillon.ca/library/howtos.php Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
