How are ssl certificates verified

Question

What is the series of steps needed to securely verify a ssl certificate   My  very limited  understanding is that when you visit an https site  the server sends a certificate to the client  the browser  and the browser gets the certificate s issuer information from that certificate  then uses that to contact the issuerer  and somehow compares certificates for validity      How exactly is this done   What about the process makes it immune to man-in-the-middle attacks  What prevents some random person from setting up their own verification service to use in man-in-the-middle attacks  so everything  looks  secure

User · Answer

if you re more technically minded  this site is probably what you want  http   www zytrax com tech survival ssl html  warning  the rabbit hole goes deep

User · Answer

I KNOW THE BELOW IS LONG  BUT IT IS DETAILED  YET SIMPLIFIED ENOUGH  READ CAREFULLY AND I GUARANTEE YOU LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED  First of all  anyone can create 2 keys  One to encrypt data  and another to decrypt data  The former can be a private key  and the latter a public key  AND VICERZA  Second of all  in simplest terms  a Certificate Authority  CA  offers the service of creating a certificate for you  How  They use certain values  the CA s issuer name  your server s public key  company name  domain  etc   and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data  The result of this encrypted data is a SIGNATURE  So now the CA gives you back a certificate  The certificate is basically a file containing the values previously mentioned  CA s issuer name  company name  domain  your server s public key  etc    INCLUDING the signature  i e  an encrypted version of the latter values   Now  with all that being said  here is a REALLY IMPORTANT part to remember  your device OS  Windows  Android  etc   pretty much keeps a list of all major trusted CA s and their PUBLIC KEYS  if you re thinking that these public keys are used to decrypt the signatures inside the certificates  YOU ARE CORRECT    Ok  if you read the above  this sequential example will be a breeze now   Example-Company asks Example-CA to create for them a certificate  Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate  Tomorrow  internet-user-Bob uses Chrome Firefox etc  to browse to https   example-company com  Most  if not all  browsers nowadays will expect a certificate back from the server  The browser gets the certificate from example-company com  The certificate says it s been issued by Example-CA  It just so happens to be that Bob s OS already has Example-CA in its list of trusted CA s  so the browser gets Example-CA s public key  Remember  this is all happening in Bob s computer mobile etc   not over the wire  So now the browser decrypts the signature in the certificate  FINALLY  the browser compares the decrypted values with the contents of the certificate itself  IF THE CONTENTS MATCH  THAT MEANS THE SIGNATURE IS VALID   Why  Think about it  only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them  How about man in the middle attacks  This is one of the main reasons  if not the main reason  why the above standard was created  Let s say hacker-Jane intercepts internet-user-Bob s request  and replies with her own certificate  However  hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA  Lastly  hacker-Jane remembers that she has to include a signature on the certificate  But what key does Jane use to sign  i e  create an encrypted value of the certificate main contents  the certificate      So even if hacker-Jane signed the certificate with her own key  you see what s gonna happen next  The browser is gonna say   quot ok  this certificate is issued by Example-CA  let s decrypt the signature with Example-CA s public key quot   After decryption  the browser notices that the certificate contents don t match at all  Hence  the browser gives a very clear warning to the user  and it says it doesn t trust the connection

User · Answer

Here is a very simplified explanation    Your web browser downloads the web server s certificate  which contains the public key of the web server   This certificate is signed with the private key of a trusted certificate authority  Your web browser comes installed with the public keys of all of the major certificate authorities   It uses this public key to verify that the web server s certificate was indeed signed by the trusted certificate authority  The certificate contains the domain name and or ip address of the web server   Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection  Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection  this is much more efficient than using public private key encryption for everything   Your browser encrypts the symmetric key with the public key of the web server then sends it back  thus ensuring that only the web server can decrypt it  since only the web server has its private key    Note that the certificate authority  CA  is essential to preventing man-in-the-middle attacks   However  even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic  since they have no way to gain access to your shared symmetric key

User · Answer

I KNOW THE BELOW IS LONG  BUT IT IS DETAILED  YET SIMPLIFIED ENOUGH  READ CAREFULLY AND I GUARANTEE YOU LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED  First of all  anyone can create 2 keys  One to encrypt data  and another to decrypt data  The former can be a private key  and the latter a public key  AND VICERZA  Second of all  in simplest terms  a Certificate Authority  CA  offers the service of creating a certificate for you  How  They use certain values  the CA s issuer name  your server s public key  company name  domain  etc   and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data  The result of this encrypted data is a SIGNATURE  So now the CA gives you back a certificate  The certificate is basically a file containing the values previously mentioned  CA s issuer name  company name  domain  your server s public key  etc    INCLUDING the signature  i e  an encrypted version of the latter values   Now  with all that being said  here is a REALLY IMPORTANT part to remember  your device OS  Windows  Android  etc   pretty much keeps a list of all major trusted CA s and their PUBLIC KEYS  if you re thinking that these public keys are used to decrypt the signatures inside the certificates  YOU ARE CORRECT    Ok  if you read the above  this sequential example will be a breeze now   Example-Company asks Example-CA to create for them a certificate  Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate  Tomorrow  internet-user-Bob uses Chrome Firefox etc  to browse to https   example-company com  Most  if not all  browsers nowadays will expect a certificate back from the server  The browser gets the certificate from example-company com  The certificate says it s been issued by Example-CA  It just so happens to be that Bob s OS already has Example-CA in its list of trusted CA s  so the browser gets Example-CA s public key  Remember  this is all happening in Bob s computer mobile etc   not over the wire  So now the browser decrypts the signature in the certificate  FINALLY  the browser compares the decrypted values with the contents of the certificate itself  IF THE CONTENTS MATCH  THAT MEANS THE SIGNATURE IS VALID   Why  Think about it  only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them  How about man in the middle attacks  This is one of the main reasons  if not the main reason  why the above standard was created  Let s say hacker-Jane intercepts internet-user-Bob s request  and replies with her own certificate  However  hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA  Lastly  hacker-Jane remembers that she has to include a signature on the certificate  But what key does Jane use to sign  i e  create an encrypted value of the certificate main contents  the certificate      So even if hacker-Jane signed the certificate with her own key  you see what s gonna happen next  The browser is gonna say   quot ok  this certificate is issued by Example-CA  let s decrypt the signature with Example-CA s public key quot   After decryption  the browser notices that the certificate contents don t match at all  Hence  the browser gives a very clear warning to the user  and it says it doesn t trust the connection

User · Answer

You said that      the browser gets the certificate s issuer information from that   certificate  then uses that to contact the issuerer  and somehow   compares certificates for validity    The client doesn t have to check with the issuer because two things      all browsers have a pre-installed list of all major CAs public keys the certificate is signed  and that signature itself is enough proof that the certificate is valid because the client can make sure  by his own  and without contacting the issuer s server  that that certificate is authentic  That s the beauty of asymmetric encryption    Notice that 2  can t be done without 1    This is better explained in this big diagram I made some time ago    skip to  what s a signature    at the bottom

User · Answer

It s worth noting that in addition to purchasing a certificate  as mentioned above   you can also create your own for free  this is referred to as a  self-signed certificate   The difference between a self-signed certificate and one that s purchased is simple  the purchased one has been signed by a Certificate Authority that your browser already knows about  In other words  your browser can easily validate the authenticity of a purchased certificate   Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA s like GoDaddy and Verisign  and that you have to live with browser warnings exceptions if you use them  this is incorrect   If you securely distribute a self-signed certificate  or CA cert  as bobince suggested  and install it in the browsers that will use your site  it s just as secure as one that s purchased and is not vulnerable to man-in-the-middle attacks and cert forgery  Obviously this means that it s only feasible if only a few people need secure access to your site  e g   internal apps  personal blogs  etc

User · Answer

Here is a very simplified explanation    Your web browser downloads the web server s certificate  which contains the public key of the web server   This certificate is signed with the private key of a trusted certificate authority  Your web browser comes installed with the public keys of all of the major certificate authorities   It uses this public key to verify that the web server s certificate was indeed signed by the trusted certificate authority  The certificate contains the domain name and or ip address of the web server   Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection  Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection  this is much more efficient than using public private key encryption for everything   Your browser encrypts the symmetric key with the public key of the web server then sends it back  thus ensuring that only the web server can decrypt it  since only the web server has its private key    Note that the certificate authority  CA  is essential to preventing man-in-the-middle attacks   However  even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic  since they have no way to gain access to your shared symmetric key

User · Answer

It s worth noting that in addition to purchasing a certificate  as mentioned above   you can also create your own for free  this is referred to as a  self-signed certificate   The difference between a self-signed certificate and one that s purchased is simple  the purchased one has been signed by a Certificate Authority that your browser already knows about  In other words  your browser can easily validate the authenticity of a purchased certificate   Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA s like GoDaddy and Verisign  and that you have to live with browser warnings exceptions if you use them  this is incorrect   If you securely distribute a self-signed certificate  or CA cert  as bobince suggested  and install it in the browsers that will use your site  it s just as secure as one that s purchased and is not vulnerable to man-in-the-middle attacks and cert forgery  Obviously this means that it s only feasible if only a few people need secure access to your site  e g   internal apps  personal blogs  etc

User · Answer

Here is a very simplified explanation    Your web browser downloads the web server s certificate  which contains the public key of the web server   This certificate is signed with the private key of a trusted certificate authority  Your web browser comes installed with the public keys of all of the major certificate authorities   It uses this public key to verify that the web server s certificate was indeed signed by the trusted certificate authority  The certificate contains the domain name and or ip address of the web server   Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection  Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection  this is much more efficient than using public private key encryption for everything   Your browser encrypts the symmetric key with the public key of the web server then sends it back  thus ensuring that only the web server can decrypt it  since only the web server has its private key    Note that the certificate authority  CA  is essential to preventing man-in-the-middle attacks   However  even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic  since they have no way to gain access to your shared symmetric key

User · Answer

The client has a pre-seeded store of SSL certificate authorities  public keys  There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called  root  certificates in order for the server to be trusted   You can examine and or alter the list of trusted authorities  Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not   The pre-seeded list can vary depending on which client you use  The big SSL certificate vendors insure that their root certs are in all the major browsers         Monkey-in-the-middle attacks are  impossible  unless the attacker has the private key of a trusted root certificate  Since the corresponding certificates are widely deployed  the exposure of such a private key would have serious implications for the security of eCommerce generally  Because of that  those private keys are very  very closely guarded

User · Answer

The client has a pre-seeded store of SSL certificate authorities  public keys  There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called  root  certificates in order for the server to be trusted   You can examine and or alter the list of trusted authorities  Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not   The pre-seeded list can vary depending on which client you use  The big SSL certificate vendors insure that their root certs are in all the major browsers         Monkey-in-the-middle attacks are  impossible  unless the attacker has the private key of a trusted root certificate  Since the corresponding certificates are widely deployed  the exposure of such a private key would have serious implications for the security of eCommerce generally  Because of that  those private keys are very  very closely guarded

User · Answer

You said that      the browser gets the certificate s issuer information from that   certificate  then uses that to contact the issuerer  and somehow   compares certificates for validity    The client doesn t have to check with the issuer because two things      all browsers have a pre-installed list of all major CAs public keys the certificate is signed  and that signature itself is enough proof that the certificate is valid because the client can make sure  by his own  and without contacting the issuer s server  that that certificate is authentic  That s the beauty of asymmetric encryption    Notice that 2  can t be done without 1    This is better explained in this big diagram I made some time ago    skip to  what s a signature    at the bottom

User · Answer

It s worth noting that in addition to purchasing a certificate  as mentioned above   you can also create your own for free  this is referred to as a  self-signed certificate   The difference between a self-signed certificate and one that s purchased is simple  the purchased one has been signed by a Certificate Authority that your browser already knows about  In other words  your browser can easily validate the authenticity of a purchased certificate   Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA s like GoDaddy and Verisign  and that you have to live with browser warnings exceptions if you use them  this is incorrect   If you securely distribute a self-signed certificate  or CA cert  as bobince suggested  and install it in the browsers that will use your site  it s just as secure as one that s purchased and is not vulnerable to man-in-the-middle attacks and cert forgery  Obviously this means that it s only feasible if only a few people need secure access to your site  e g   internal apps  personal blogs  etc

User · Answer

Here is a very simplified explanation    Your web browser downloads the web server s certificate  which contains the public key of the web server   This certificate is signed with the private key of a trusted certificate authority  Your web browser comes installed with the public keys of all of the major certificate authorities   It uses this public key to verify that the web server s certificate was indeed signed by the trusted certificate authority  The certificate contains the domain name and or ip address of the web server   Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection  Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection  this is much more efficient than using public private key encryption for everything   Your browser encrypts the symmetric key with the public key of the web server then sends it back  thus ensuring that only the web server can decrypt it  since only the web server has its private key    Note that the certificate authority  CA  is essential to preventing man-in-the-middle attacks   However  even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic  since they have no way to gain access to your shared symmetric key

User · Answer

The client has a pre-seeded store of SSL certificate authorities  public keys  There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called  root  certificates in order for the server to be trusted   You can examine and or alter the list of trusted authorities  Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not   The pre-seeded list can vary depending on which client you use  The big SSL certificate vendors insure that their root certs are in all the major browsers         Monkey-in-the-middle attacks are  impossible  unless the attacker has the private key of a trusted root certificate  Since the corresponding certificates are widely deployed  the exposure of such a private key would have serious implications for the security of eCommerce generally  Because of that  those private keys are very  very closely guarded

User · Answer

It s worth noting that in addition to purchasing a certificate  as mentioned above   you can also create your own for free  this is referred to as a  self-signed certificate   The difference between a self-signed certificate and one that s purchased is simple  the purchased one has been signed by a Certificate Authority that your browser already knows about  In other words  your browser can easily validate the authenticity of a purchased certificate   Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA s like GoDaddy and Verisign  and that you have to live with browser warnings exceptions if you use them  this is incorrect   If you securely distribute a self-signed certificate  or CA cert  as bobince suggested  and install it in the browsers that will use your site  it s just as secure as one that s purchased and is not vulnerable to man-in-the-middle attacks and cert forgery  Obviously this means that it s only feasible if only a few people need secure access to your site  e g   internal apps  personal blogs  etc

User · Answer

if you re more technically minded  this site is probably what you want  http   www zytrax com tech survival ssl html  warning  the rabbit hole goes deep

User · Answer

The client has a pre-seeded store of SSL certificate authorities  public keys  There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called  root  certificates in order for the server to be trusted   You can examine and or alter the list of trusted authorities  Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not   The pre-seeded list can vary depending on which client you use  The big SSL certificate vendors insure that their root certs are in all the major browsers         Monkey-in-the-middle attacks are  impossible  unless the attacker has the private key of a trusted root certificate  Since the corresponding certificates are widely deployed  the exposure of such a private key would have serious implications for the security of eCommerce generally  Because of that  those private keys are very  very closely guarded

[algorithm] How are ssl certificates verified?

Examples related to algorithm

Examples related to security

Examples related to ssl

Examples related to certificate