How do digital certificates work when used for sec

问题:

Please help me understand how the process goes. I understand that web browsers contain root certificates for certificate authorities (CAs) like verisign, Entrust, Comodo .. etc, but what exactly happens when a user accesses a secure page? Does the web browser send a request to the server of the CA to verify the ceriticate or it just uses the CA's root certificate (in the browser) to verify the certificate?

I used some HTTP sniffer and logged on to gmail (the login page is secure) but didn't see requests going to any websites other than google, does that mean it only uses the CA's root certificate?

回答1:

It depends on your browser/OS configuration. Basically a browser or an OS has a list of trusted root authorities (Mozilla has it's own list, IE uses the Windows one).

When the SSL handshake takes place the site certificate is examined to see if it is signed by one of the trusted authorities, and if the server name matches the one in the certificate.

What happens next depends on the browser or OS configuration. CAs have a revocation list function (its either a big list or a separate service (OCSP) where you can ask if a certificate is still good). If your browser/OS is configured to check this then this extra step will happen.

Firefox and Windows will check OCSP services by default if they are available, neither check CRL lists by default.

回答2:

A Certificate Authority issues certificates signed with a private key. Your browser stores the corresponding public key for a bunch of trusted CAs. When you receive a request for a secure transaction, your browser checks the root of the certificate (provided by the host you're connecting to) with the public key to make sure it was really signed by the matching private key.

The host stores the certificate signed by a trusted third party (the CA) and your browser stores the public key of that same third party. When a transaction begins, the host only needs to present that certificate for your browser to verify. There's no need for transaction-time intervention by the trusted third party.

This is different than systems like PGP, where you have to contact the third party in order to get the public key of whoever you're communicating with. The systems can work differently because with PGP you're encrypting/decrypting data. With certificates all you're doing is authenticating identity.

回答3:

The web browser has list of root certificates it trusts. These are public keys of CAs. The browser is saying you can trust that the private keys of these CAs are in fact private, and that anything that has been encrypted by one of those private keys -- including the alleged web server's certificate -- really came from the CA.

The certificate contains the public key of the web server and the web server's address (and company name etc.), encrypted by the private key of the CA. This encryption is done once, when the web site owner bought the certificate from the CA. After that, the web site owner keeps the certificate on hand to send you when you make an https request. Since your browser is able to use the CA's public key (which was already on your machine) to decrypt the certificate sent by the web server, and sees in the decrypted certificate that the certificate contains a host address that matches the https-serving host, the browser concludes that the host's public key (decrypted using the CA's public key) is authentic. The certificate routinely given out by the web host might still be coming from some random person spoofing the host, but at least you can be confident that it contains the authentic public key of the https-serving host you are aiming to communicate with.

You can then send data (like your credit card number) encrypted with the host's public key, and only the host's private key will be able to decrypt your data. No communication with the CA was necessary during the transaction.

回答4:

CA signs the Web server certificate. Since the browser already has the CA public key (in root certificates), it can validate the authenticity of it without accessing CA. The only thing that requires CA access is to check if the certificate is revoked.