RE: Signature validation in certificates
Hi Patrik, Thanks for your detailed response. It certainly helped my understanding. I did refer RFC3280 but missed out on 5280. Will refer it and like you said manually validating certificates might be risky. Thanks and Regards Geetha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Patterson Sent: Wednesday, July 16, 2008 1:31 AM To: openssl-users@openssl.org Subject: 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: 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
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: 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Signature validation in certificates
Thanks Dominique. I guess the openssl verify does these steps to actually verify if an incoming server certificate compares to a root certificate. Regards Geetha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dominique Lohez Sent: Wednesday, July 09, 2008 7:33 PM To: openssl-users@openssl.org Subject: Re: Signature validation in certificates The signature checkingwork like this The SIGNER ( CA or SERVER ) build a digest with an appropriate algorithm then he encrypt the digest with its private key Within the certificate you know the digest algorithm so you can build this digest and then you decrypt thi sdsignature with the public key of the signer , this must be identical to the digest I hope this helps Dominique LOHEZ Geetha_Priya a écrit : I have read numerous certification related docs. Being new to this technology I don't find any material detailing the manual certificate validation [even the faq on the same heading ] specially verifying key part. I also went through verify.c in openssl but key verification is lost amongst the APIs. Here is my understanding on certificate validation 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. 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 Now for certificate validation: First we verify the credentials of issuer/common name etc.. that is clear to me Second step is to match the signature which I find a lil confusing Here do you use public key to decrypt the signature portion of your root certificate and compare it with, the decrypted portion of server certificate (decrypted with public key that appears in server certificate). Does this sound right? The root certificate has public key and signature and so does the server certificate. Please clarify as I am manually trying to verify certificates. Any other C files within openssl which talks the details about signature validation. Thanks for your help Regards Geetha DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Dr Dominique LOHEZ ISEN 41, Bd Vauban F59046 LILLE France Phone : +33 (0)3 20 30 40 71 Email: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Signature validation in certificates
I have read numerous certification related docs. Being new to this technology I don't find any material detailing the manual certificate validation [even the faq on the same heading ] specially verifying key part. I also went through verify.c in openssl but key verification is lost amongst the APIs. Here is my understanding on certificate validation 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. 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 Now for certificate validation: First we verify the credentials of issuer/common name etc.. that is clear to me Second step is to match the signature which I find a lil confusing Here do you use public key to decrypt the signature portion of your root certificate and compare it with, the decrypted portion of server certificate (decrypted with public key that appears in server certificate). Does this sound right? The root certificate has public key and signature and so does the server certificate. Please clarify as I am manually trying to verify certificates. Any other C files within openssl which talks the details about signature validation. Thanks for your help Regards Geetha DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
Signature validation in certificates
I have read numerous certification related docs. Being new to this technology I don't find any material detailing the manual certificate validation [even the faq on the same heading ] specially verifying key part. I also went through verify.c in openssl but key verification is lost amongst the APIs. Here is my understanding on certificate validation 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. 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 Now for certificate validation: First we verify the credentials of issuer/common name etc.. that is clear to me Second step is to match the signature which I find a lil confusing Here do you use public key to decrypt the signature portion of your root certificate and compare it with, the decrypted portion of server certificate (decrypted with public key that appears in server certificate). Does this sound right? The root certificate has public key and signature and so does the server certificate. Please clarify as I am manually trying to verify certificates. Any other C files within openssl which talks the details about signature validation. Thanks for your help Regards Geetha DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Signature validation in certificates
The signature checkingwork like this The SIGNER ( CA or SERVER ) build a digest with an appropriate algorithm then he encrypt the digest with its private key Within the certificate you know the digest algorithm so you can build this digest and then you decrypt thi sdsignature with the public key of the signer , this must be identical to the digest I hope this helps Dominique LOHEZ Geetha_Priya a écrit : I have read numerous certification related docs. Being new to this technology I don't find any material detailing the manual certificate validation [even the faq on the same heading ] specially verifying key part. I also went through verify.c in openssl but key verification is lost amongst the APIs. Here is my understanding on certificate validation 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. 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 Now for certificate validation: First we verify the credentials of issuer/common name etc.. that is clear to me Second step is to match the signature which I find a lil confusing Here do you use public key to decrypt the signature portion of your root certificate and compare it with, the decrypted portion of server certificate (decrypted with public key that appears in server certificate). Does this sound right? The root certificate has public key and signature and so does the server certificate. Please clarify as I am manually trying to verify certificates. Any other C files within openssl which talks the details about signature validation. Thanks for your help Regards Geetha DISCLAIMER: This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Dr Dominique LOHEZ ISEN 41, Bd Vauban F59046 LILLE France Phone : +33 (0)3 20 30 40 71 Email: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
