70

(Sorry I know this is a complete noob question and at the risk of posting a somewhat duplicate topic. I have a basic understanding of public/private key, hashing, digital signature... I have been searching online & stack forum last couple days but cannot seem to find a satisfactory answer.)

Example: I am surfing on open wifi and I browse to for the 1st time. Server sends back its SSL certificate. My browser does its thing and verifies that the cert is signed by a CA that it trusts and all is well. I click around on the website. BUT!

Question: Can someone actually please explain to me in a simple way how does my browser actually verify that the server certificate is legitimate? Yeah okay so on the certificate itself it says it is issued by, say "Verisign" but what is the actual cryptographic magic happens behind the scene to validate that it isn't a bogus certificate? I have heard people explain "SSL certificates are verified using the signing CA's public key" but that doesn't make sense to me. I thought public key is to encrypt data, not to decrypt data.

So confused... appreciate it if someone could enlighten me. Thanks in advance!

  • Oh wait, I think I got it. Please correct me otherwise. So basically the way browser verifies the cert is by re-generating the digital signature (re-hash and re-encrypt via CA public key) and then seeing if that matches the digital signature included on the server's certificate. – SecurityNoob Apr 22 '14 at 21:12
  • actually you know what, this article clarified it for me. I did not understand the difference between encryption and signing. I thought they were the same and confused myself. Hopefully this will be helpful others :) crypto.stackexchange.com/questions/2123/… – SecurityNoob Apr 22 '14 at 21:30
  • @DeerHunter thanks. That's more around how SSL works in generally. I was getting hung up on the logic behind how certificates get verified by the browser. But that's a great posting and thanks for sharing! – SecurityNoob Apr 22 '14 at 21:40
  • 2
    This question focuses on the validation of the certificate chain. While How does SSL/TLS work? includes many of the aspects too it is more a general description of SSL/TLS and details of certificate validation are only a small and hard to find part of it. That's why I've reopened this question so that it is no longer marked a duplicate. – Steffen Ullrich Feb 13 '17 at 21:05
74

You are correct that SSL uses an asymmetric key pair. One public and one private key is generated which also known as public key infrastructure (PKI). The public key is what is distributed to the world, and is used to encrypt the data. Only the private key can actually decrypt the data though. Here is an example:

Say we both go to walmart.com and buy stuff. Each of us get a copy of Walmart's public key to sign our transaction with. Once the transaction is signed by Walmart's public key, only Walmart's private key can decrypt the transaction. If I use my copy of Walmart's public key, it will not decrypt your transaction. Walmart must keep their private key very private and secure, else anyone who gets it can decrypt transactions to Walmart. This is why the DigiNotar breach was such a big deal

Now that you get the idea of the private and public key pairs, it's important to know who actually issues the cert and why certs are trusted. I'm oversimplifying this, but there are specific root certificate authorities (CA) such as Verisign who sign certs, but also sign for intermediary CA's. This follows what is called Chain of Trust, which is a chain of systems that trust each other. See the image linked below to get a better idea (note the root CA is at the bottom).

Simple Chain of Trust

Organizations often purchase either wildcard certs or get registered as a intermediate CA themselves who is authorized to sign for their domain alone. This prevents Google from signing certs for Microsoft.

Because of this chain of trust, a certificate can be verified all the way to the root CA. To show this, DigiCert (and many others) have tools to verify this trust. DigiCert's tool is linked here. I did a validation on gmail.com and when you scroll down it shows this:

Certificate of Trust for Gmail

This shows that the cert for gmail.com is issued by Google Internet Authority G2, who is in turn issued a cert from GeoTrust Global, who is in turn issued a cert from Equifax.

Now when you go to gmail.com, your browser doesn't just get a blob of a hash and goes on it's way. No, it gets a whole host of details along with the cert:

Google Public Cert Details

These details are what your browser uses to help identify the validity of the cert. For example, if the expiration date has passed, your browser will throw a cert error. If all the basic details of the cert check out, it will verify all the way to the root CA, that the cert is valid.

Now that you have a better idea as to the cert details, this expanded image similar to the first one above will hopefully make more sense:

Certificate Chain of Trust Expanded

This is why your browser can verify one cert against the next, all the way to the root CA, which your browser inherently trusts.

Hope this helps you understand a bit better!

  • @SecurityNoob - No problem. If you have further questions, feel free to toss 'em out. – PTW-105 Apr 22 '14 at 22:01
  • @PTW-105 So the public key decrypts the signature, beforehand does the entity sign the signature with a private key? – JVE999 Apr 27 '15 at 21:33
  • 2
    @PTW-105 the SSL certificate presented to the browser is in public domain and can be copied by anybody. What if it is installed by anyone else on its server? How will the browser really tie the ssl certificate to a domain? – KawaiKx Apr 22 '16 at 16:39
  • 5
    @PTW-105 : As part of TLS handshake, browser gets "gmail.com" certificate from gmail webserver (TLS server). After that browser will identify that the intermediate CA name as "Google Internet Authority G2". Now how and from where the browser will get the cert of "Google Internet Authority G2" ? and then how it gets cert of "GeoTrust Global CA" and "Equifax" ? – rashok Jul 12 '16 at 13:05
  • @rashok: the server sends the chain cert(s) in the handshake, see The Great Bear answers at #20803 (linked above) or tools.ietf.org/html/rfc5246#section-7.4.2 et pred. Although the GeoTrust-to-Equifax bridge is now obsolete; see security.stackexchange.com/questions/93081/… and additional links there – dave_thompson_085 Aug 21 '17 at 12:13
0

To clarify one point from the question not covered in the otherwise excellent answer by @PTW-105 (and asked in the comment there by @JVE999):

I thought public key is to encrypt data, not to decrypt data...

The keys work both ways - what is encrypted with the public key can only be decrypted with the private and vice versa. We just decide one is private and one is public, there's no conceptual difference.

So if I encrypt data to send to you I use your public key to encrypt it and only you can decrypt it with your private key.

However, if I want to sign something, to prove it came from me, then I generate a hash of the message and encrypt that hash with my private key. Then anyone can decrypt it with my public key and compare to the actual message hash, but they know that only I could have encrypted it, since only I have my private key. So they know the message hash hasn't changed since I signed it, and therefore that it came from me.

As per the comments, the above is not quite true. See the link from the comment by @dave_thompson_085. However, this isn't a "how to sign properly" tutorial, just clarifying the roles of private and public keys in encryption verses signing. The basic point in that regard is this:

  • To encrypt data the external party uses a public key and only the private key holder can decrypt it.
  • To sign, the private key holder uses a hash function and their private key (plus appropriate padding, etc.). The external party can then verify the signature using the public key. This ensures the message came from the private key holder (assuming no-one else has access to the private key).

Signing may sometimes (depending on the implementation) be done with the same key pair as encryption, just used the other way round, or it may use a distinct key pair (see another link, also from @dave_thompson_085's comment)

0

If a web site has a valid certificate, it means that a certificate authority has taken steps to verify that the web address actually belongs to that organization. When you type a URL or follow a link to a secure web site, your browser will check the certificate for the following characteristics: the web site address matches the address on the certificate the certificate is signed by a certificate authority (CA) that the browser recognizes as a "trusted" authority

Both the TLS and SSL protocols use what is known as an 'asymmetric' Public Key Infrastructure (PKI) system. An asymmetric system uses two 'keys' to encrypt communications, a 'public' key and a 'private' key. Anything encrypted with the public key can only be decrypted by the private key and vice-versa. When you go to a site, a website presents their public key which your browser validates and uses to encrypt the data sent (between your browser and their server) and only server/site has the private key which is able to decrypt the data.

Some info about keys: Asymmetric encryption (or public-key cryptography) uses a separate key for encryption and decryption. Anyone can use the encryption key (public key) to encrypt a message. However, decryption keys (private keys) are secret. This way only the intended receiver can decrypt the message. The most common asymmetric encryption algorithm is RSA; however, we will discuss algorithms later in this article.

full credit to these sites:

https://www.us-cert.gov/ncas/tips/ST05-010

https://www.digicert.com/ssl-cryptography.htm

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.