39

If I get an SSL certificate from a well-known provider, what does that prove about my site and how?

Here's what I know:

  • Assume Alice and Bob both have public and private keys
  • If Alice encrypts something with Bob's public key, she ensures that only Bob can decrypt it (using his private key)
  • If Alice encrypts something with her own private key, anyone can decrypt it (using her public key), but they will know that it was encrypted by her
  • Therefore, if Alice encrypts a message first with her own private key, then with Bob's public key, she will ensure that only Bob can decrypt it and that Bob will know the message is from her.

Regarding certificates, here's what I think happens (updated):

  • I generate a request for a certificate. In that request, I put my public key and a bunch of information about myself.
  • The certificate issuer (in theory) checks me out to make sure it knows who I am: talks to me in person, sees my driver's license, retina scan, or whatever.
  • If they're satisfied, the certificate issuer then encrypts my request with their private key. Anyone who decrypts it with their public key knows that they vouch for the information it contains: they agree that the public key is mine and that the information stated is true about me. This encrypted endorsement is the certificate that they issue to me.
  • When you connect to my site via https, I send you the certificate.
  • Your browser already knows the issuer's public key because your browser came installed with that information.
  • Your browser uses the issuer's public key to decrypt what I sent you. The fact that the issuer's public key works to decrypt it proves that the issuer's private key was used to encrypt it, and therefore, that the issuer really did create this certificate.
  • Inside the decrypted information is my public key, which you now know has been vouched for. You use that to encrypt some data to send to me.

Is that right? If not, could someone lay out the steps very clearly?

Nathan Long
  • 2,624
  • 4
  • 21
  • 28
  • 5
    Your description actually cleared up a few grey areas for me. – Martin York Aug 31 '11 at 20:02
  • 2
    It should be noted that the whole system is essentially a technical implementation of the idea "you trust the certificate issuer, and they trust me, therefore you can trust me." Unfortunately, sometimes the certificate issuer isn't trustworthy (like the case of DigiNotar), and the current system requires us to trust all of them to be perfect. Convergence is one system proposed to mitigate that, but it may or may not get traction. http://www.youtube.com/watch?feature=player_embedded&v=Z7Wl2FW2TcA – Nathan Long Oct 24 '11 at 20:46
  • 4
    `` "she ensures that only Bob can decrypt it" is not quite right. I would phrase it as "she ensures that only a process with access to Bob's key can decrypt it." Knowledge of a private key is often a good proxy for identity but it is not the same. Access can be gained by delegation, theft, or brute-forcing and it is almost always a computer that is using the key, rarely a person. Conflating identity and knowledge can cause you to overlook attack vectors. – Mike Samuel Oct 26 '11 at 14:15
  • @NathanLong: Do the updated steps reflect the clarifications were seeking from the answers? – kaizenCoder Mar 13 '17 at 03:04
  • Regarding *"What is an SSL certificate intended to prove"*, the only thing a certificate does is bind a public key to an identity. Nothing else. The *"how [to] do it"* is a very big question, and it depends on security models and threat models. –  Mar 26 '18 at 23:18
  • I presume even your website serves the certificate it does not necessarily mean the certification belong to you, but the secure communication won't work if you don't have the private key. – James Lin Sep 17 '20 at 03:58

3 Answers3

17

Your key theory: basically right, but authentication is usually done by encrypting a cryptographically secure hash of the data rather than the data itself.

A CA's signature on an SSL certificate should indicate that the CA has done a certain amount of diligence to ensure that the credentials on the certificate match the owner. That diligence varies, but the ultimate point is that they're saying that the certificate they signed belongs to the entity named on it.

See http://en.wikipedia.org/wiki/Digital_signature#Definition

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • 1
    "encrypting a cryptographically secure hash of the data rather than the data itself" I can't quite follow that. Which data are you referring to? Which key is it encrypted with? I'm trying to understand the exact steps. – Nathan Long Aug 31 '11 at 19:02
  • Take a look at the diagram on the right side of the page of the link in my answer. It shows that a signature is made when one hashes the data, then encrypts the hash with their private key. – Jeff Ferland Aug 31 '11 at 19:16
  • 1
    Right, but what data has the CA encrypted with their private key? It must not be data specific to this particular communication, because the certificate was generated once and installed on the server. It's not generated for every request. And it must be data that is specific to my site, otherwise it wouldn't prove that the CA vouches for **me**. Is it my public key? – Nathan Long Aug 31 '11 at 20:31
  • 2
    They encrypt the hash of the certificate. The certificate contains the public key in its data, as well as information such as your dns name. – Jeff Ferland Aug 31 '11 at 20:46
  • Awesome! Thanks. I have seen this done once, but forgot how the process worked. I just read about what CSRs are and generated one with the openssl command line tool, so I see all the information it asks for and encrypts in the CSR, and that it generates a private key, too. Makes a lot more sense now. – Nathan Long Aug 31 '11 at 20:53
  • 1
    @JeffFerland, just to point out that, strictly speaking, you don't "encrypt" with a private key, you sign (particularly relevant for DSA certs). – Bruno Jun 16 '12 at 14:11
  • @JeffFerland To make sure I'm following you, can you confirm my understanding of what you've said? The certificate will have unhashed data as well as hashed data, and the hashed data is what's encrypted with the CA's private key. Your browser can then decrypt the hashed data with the CA's public key, and then verify that hash by hashing the unhashed data manually. – temporary_user_name May 01 '16 at 00:16
  • The only thing a certificate does is bind a public key to an identity. Nothing else. –  Mar 26 '18 at 23:15
7

A public key certificate is the signed combination between a public key, identifiers, and possibly other attributes. Those who sign this document effectively assert the authenticity of the binding between the public key and the identifier and these attributes, in the same way as a passport issuing authority asserts the binding between the picture and the name in a passport, as various other pieces of information (nationality, date of birth, ...).

First, a couple of clarifications on the terminology:

  • Strictly speaking, there is no such thing as an "SSL certificate". Most of the time, this is a short expression for "X.509 certificate used for SSL/TLS". (SSL/TLS is also capable of using other types of certificates such as OpenPGP certificates, although this is less common.)

  • Your usage of "encryption" and "decryption" is incorrect here. In public key cryptography:

    • The private key is used for signing and deciphering/decrypting.
    • The public key is used for verifying signatures and enciphering/encrypting.

    See the glossary of the TLS specification:

    public key cryptography: A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.

    It may not seem that this distinction in terminology matters, because these operations are roughly the same as far as RSA is concerned (in fact you'll find underlying routines called RSA_private_encrypt in OpenSSL), but (a) this wouldn't work for DSA and (b) not understanding this fundamental difference can lead you to make mistakes as far as your overall security scheme is concerned.

    In particular, the purpose of encryption is to hide something. When you talk about "encrypting with a private key" here, it doesn't make any sense since the public key is known to anyone. In addition, the issuer's public key isn't required to look inside a certificate this issuer has signed, because everything (see TBSCertificate structure) is there in clear for anyone to see anyway. Nothing is hidden here.

    (What is done for signing with RSA is indeed more or less the same operation as encrypting, but with the private key, applied to a cryptographic digest of the message to sign, typically done using SHA-1 for certificates nowadays.)

What you server certificate intends to prove is that the CA has somehow verified the binding between your host name and your certificate request (more specifically, the public key in your certificate request). At the very least, it would have e-mail the domain name owner (for Domain Validated certificates). (See distinctions between validation modes here.)

The content of the certificate issued should be compliant with RFC 3280/RFC 5280, which define how clients should verify and validate the certificate. This will define which attributes can be used, in particular (extended) key usage attributes usually, e.g. "TLS server".

As a result, your X.509 server certificate will bind together:

  • A public key (for which you have the private key).
  • An issuer name (the CA certificate Subject DN).
  • A server name (in accordance with RFC 2818 Section 3.1 or RFC 6125), in the Subject Alternative Name extension or in the Common Name of the Subject Distinguished Name.
  • Usage extensions.
  • Possibly other extensions (critical or not), e.g. EV certificate policies.

This is all placed in the TBSCertificate structure of the X.509 certificate. Then, this structure is digested using a cryptographic hash algorithm (e.g. SHA-1) and signed using the CA's private key to form the signature (signatureValue in the resulting Certificate).

When the certificate is used, the client can verify this signature (using the CA's public key it knows, or by building a certification path using multiple CA certificates to one of the trust anchors it knows), check that the usage attributes are compatible with SSL/TLS usage and check that the host name it requested matches the one for which it was issued.

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
3

It should be pointed out, along with all the other answers, that your private key is not always just one key that is used for both decrypting and signing messages. These should be two separate keys. This would create 4 keys for each person:

Public Encryption Key - Used to encrypt data to send to me.

Private Decryption Key - Used to decrypt messages that were encrypted using my Public Encryption Key.

Private Signing Key - Used to sign messages that I send to other people.

Public Verify Key - Used to verify that a message was, in fact, signed by me.

There are some reasons to use separate keys for this. See this discussion for more details.

Community
  • 1
Oleksi
  • 4,809
  • 2
  • 19
  • 26