Yesterday I asked the following question regarding what would happen if you placed a stolen certificate on your own server and edited the 'host' file so that the DNS name matched:

Could a stolen certificate show as trusted?

I now know the website in the browser wouldn't appear as trusted, but I have a couple of follow up questions:

  1. Would the 'identity'/authentication part possibly show as trusted (even though overall the 'padlock' would still show as untrusted?) Before the SSL/TLS handshake, the diagrams I've looked at show that the protocol authenticates the server first. On Chrome, if you click the padlock > connection, there are two parts, identity and connection. The identity part is the authentication and am I right in thinking this would pass with a stolen certificate if the DNS name was correct? The signature would still be valid I believe as it hasn't been modified therefore will hash to the same value and has been signed by a trusted agent.

  2. The answer to the question I linked above explained the reason the connection would show as untrusted is the private key is needed on the server to complete the SSL/TLS handshake. My question is, how is the private key used in the handshake (not looking for too much depth).

    Am I right in thinking either RSA or Diffie-Hellman can be used to create a shared symmetrical secret key in SSL/TLS, depending on how it is implemented? I understand why a private key is needed with RSA, a random number is encrypted by the client with the servers public key and sent to the server and decrypted with the private key. When I look at a certificate and see a public key, is this always the RSA public key? And is it only used if RSA is the method for generating the secret symmetrical key?

  3. If DH is used instead of RSA, is the public key ever on a certificate, or are both the public and private keys created when the connection is made and temporary. Could a SSL/TLS connection not then be created with the attackers server and the stolen certificate would authenticate the server (if the DNS names matched).

I know DH is susceptible to MITM attacks and that's why certificates are used for authentication, but if a stolen certificate could authenticate the fake server, could a SSL/TLS connection with DH happen to a fake server using a stolen certificate?

If anyone could help clear up the above three questions it would be greatly appreciated.

3 Answers 3


Regardless of whether DH or RSA is used - First, the server presents its certificate (which contains the server's public key) to the client immediately upon an HTTPS connection. Then, the client and the server negotiate the SSL/TLS protocols and ciphers to be used to facilitate the HTTPS connection. So the same certificate (and thus, the same server public key) are used regardless of whether RSA or DH is used.

If DH is used, the server uses its private key to create a digital signature, which the client then verifies using the server's public key from the server's certificate, to authenticate the identity of the server. Aside from this, the server's private and public keys are not used for anything else during the session. With DH, the keys that are used to encrypt the data being sent back and forth between the client and the server are ephemeral - meaning that the keys are used once and not reused. For more info on this, see How ECDHE is signed by RSA in ECDHE_RSA cipher. But, as you can see, it is necessary for the server to have the private key that corresponds to the public key in the certificate, to create a digital signature, which the client then uses to verify the authenticity of the server, in order for DH to proceed.

If RSA is used, your statement "I understand why a private key is needed with RSA, a random number is encrypted by the client with the servers public key and sent to the server and decrypted with the private key." is correct. This session key is then used with a symmetrical encryption algorithm (such as AES) to encrypt the data being sent back and forth between the client and the server.

So, regardless of whether RSA or DH is used, the server must have the private key that corresponds to the public key in its certificate, in order to complete the SSL/TLS handshake, so that an HTTPS connection can be established - and I strongly doubt that any widely used browser would indicate that a site is trusted without being able to establish an HTTPS connection with it.

  • Thanks mti2935 for this, but I'm a bit confused and have a few follow up questions. Firstly, when you say 'So the same certificate (and thus, the same server public key) are used regardless of whether RSA or DH is used.'. Is the public key on this certificate always RSA, because as you say later DH keys are temporary just for the creation of the secret key. So regardless of whether DH or RSA is used for the shared secret, the server will have a certificate with a RSA public key on it? Thanks
    – RJSmith92
    Commented Nov 14, 2015 at 15:07
  • I think the confusion here (and in the previous question) boils down to semantics and terminology. At the heart of it, almost all SSL/TLS protocols use a symmetric encryption algorithm (such as AES) to actually encrypt the data back and forth between the client and server. That leads to the question of how the client and the server agree on the 'shared secret' or 'key' used for the symmetric encryption. This can be done either through RSA or DH.
    – mti2935
    Commented Nov 15, 2015 at 0:25
  • 1
    The notion that a 'public key on this certificate always RSA' doesn't apply. Technically, the structure of a certificate (including the public key) is based on PKI and x.509. The certificate (and the public key contained in it) can then be used to facilitate RSA or DH, through which a the client and the server then agree on a 'key' or a 'shared secret' for symmetric encryption. I hope this makes sense. If any of this is still confusion, you can contact me through my profile.
    – mti2935
    Commented Nov 15, 2015 at 0:27
  • think I've got it now. One final thing, am I right in saying there are sort of two forms of authentication when establishing SSL/TLS session? The first being the certificate hashed and signed by a CA, and attached as a digital signature. On its own though this isn't good enough, as anyone can steal a certificate and pretend it's their own (as my original question/s were about). The other form of authentication is, as you have described, the need for the corresponding private key to establish a SSL/TLS connection, regardless of whether DH or RSA is used...
    – RJSmith92
    Commented Nov 15, 2015 at 20:14
  • Again, on its own this isn't enough as anyone can create a key pair and cert, place it on a webserver and pretend to be anybody. This is where this digital signature from a CA is needed to prove the certificate and key pair belongs to a legitimate source. Is that correct (ish)?
    – RJSmith92
    Commented Nov 15, 2015 at 20:14

@mti2935's answer is great, but I think I have some insight into the nature of your confusion, so let me chime in.

Data sent over a TLS session is never encrypted with the private key of your certificate. It is encrypted with the session key. This session key is established during the TLS handshake. How is not important; there are random numbers involved, some from both sides, some hashing, and sometimes DH or ECDH. All this is easy and requires no private key.

To complete the handshake, however, the server will have to prove it possesses the private key associated with the certificate it presented by decrypting an essential part of the session key exchange process. Without the decryption key, the server will be unable to complete the handshake, and no data will ever be sent over the pipe.

Most likely, this will not trigger a security warning as dire as using a self-signed certificate, because it looks like a protocol error of some type, or like the server just hung up. It's not really treated as an intrusion attempt, because there was no chance it would work in the first place.

Finally, just a note about semantics: when people talk about a "stolen certificate," they typically refer to a stolen certificate/private key pair. This is because certificates are public by their very nature, so there's nothing to steal about them by themselves. Web servers hand them out to every connection attempt, and Google's Certificate Transparency initiative aims to put every one ever issued in a public list. The whole reason this is OK is because this attack doesn't work without the private key.

  • I'm glad you clarified that a certificate cannot be stolen because by definition it is already public. I just want to point out that certificates are not useless without the private key. They are quite useful to everyone else to authenticate the certificate owner or check a signature for authenticity. They are useless to the owner without the private key, however. Commented Nov 15, 2015 at 6:50
  • 1
    @AndrewPhilips I was perhaps a bit overzealous in my use of hyperbole :) I've made an edit to clarify the situation. Commented Nov 15, 2015 at 11:42
  • Thanks @MrNerdHair. My confusion boils down to, where in the handshake process do things fall down without the server having the corresponding private key, for both DH and RSA as the method used for establishing a session key?
    – RJSmith92
    Commented Nov 15, 2015 at 13:05
  • "All this is easy and requires no private key." Umm no, in traditional RSA based ciphersuites the client generates the key and uses the RSA to encrypt it before sending it to the server. The server then needs it's private key to decrypt the session key. Commented Nov 15, 2015 at 15:10
  • Thanks everyone, found what I was looking for here - blog.cloudflare.com/…
    – RJSmith92
    Commented Nov 15, 2015 at 15:11

EDIT - OP really did mean use of Server Certificate. Answer changed to reflect this. Mostly, stuff added to end.

Both answers (@mti2935 & @MrNerdHair) address your questions, however, one of your comments says you're still a bit confused about the use of the Private Key in the TLS exchange. I'm providing this answer to address that by outlining how the TLS protocols work at a high level. After the protocol outline, we can examine the contribution of the Server's Private Key and why having just the Public Certificate (and hacking DNS) is insufficient to faking a web server.

Methods for Key Establishment

Let's examine four protocols: RSA, Diffie-Hellman and how TLS uses each of them. First of all, every network cryptographic establishment protocol ends with the creation of a secret session key used for symmetric encryption. This is an engineering principle and not a security principle. Why? Because symmetric cryptography is designed to be fast while other forms of cryptography (RSA) are slower and some key agreement protocols don't have cryptography. Protocols 2, 3 & 4 show how both sides securely agree upon a session key.


RSA Public Key Cryptography can be one-way cryptography or two-way cryptography. However, it differs from symmetric cryptography in that neither party in the exchange needs to have met the other party prior to the exchange and exchanged a secret. Focusing on one-way cryptography, how can something (like a message or key) be sent encrypted?

  • Cert_Server contains the public key of the server: (N,e) where N=pq.
  • Private Key of the server is (N,d), although it can keep p, q and a Phi(n) and it needs its Certificate to give out to clients. No one should have the private key but the server.

Here's how a client sends a secret message to a server:

    Client to Server: Hello
    Server to Client: Hello, Cert_Server
    Client, internal: Somehow Validate Cert_Server and, if valid,
    Client to Server: Enc(plaintext, Key_Public)
    Server, internal: Dec(cryptext, Key_Private)

That's it, the Client encrypted plaintext and sent it to server. Everyone can see the cryptext (Enc(msg, key_pub)), no one but the server can see the plaintext without breaking RSA by factoring N or stealing the server's private key (d which was computed knowing primes p and q). Server can see the plaintext by decrypting using its Private Key (d,N). The Client's Validation step involves checking that the cert is internally valid (all signatures check out), checking the Root CA, checking revocation lists.


Briefly, in DH Key Exchange, we start with two numbers (P,g), P is Prime (actually a Safe Prime, where P=2Q+1 and Q is also Prime) and g is a generator.

The exchange may look something like this:

    Client to Server: Hello
    Server to Client: Hello, (g,P)
    Client, internal: A = RND(P), a = (g^A)%P
    Client to Server: a
    Server, internal: B = RND(P), b = (g^B)%P, K = (a^B)%P
    Server to Client: b
    Client, internal: K=(b^A)%P

At the end of the exchange, both parties know K, however, no one watching the exchange which contained (g,P,a,b) can compute K without being able to perform a discrete logarithm in the field P.

Note, this is subject to man-in-the-middle attack. Because (g,P) are known (sent by the server). That means, Mallory can step into the middle and run the server side of the exchange with the client and run the client side of the exchange with the server, produce two separate secrets (K) and neither side will know Mallory sits in the middle.


The TLS cipher suite that uses only RSA works as follows (lots of other bits snipped):

    Client to Server: Hello
    Server to Client: Hello, Cert_Server
    Client, internal: Somehow Validate Cert_Server and, if valid,
    Client, internal: K=RND()
    Client to Server: Enc(K, Key_Public)
    Server, internal: Dec(cryptext, Key_Private)

Notice that this is essentially the same as our description of RSA above, except that for the plaintext we've used a client generated session key, K. Note, some of the problems with TLS_RSA cipher suite is that the client generates the K. Often, the client doesn't do a good enough job generating K (cryptographically strong RNG), leaving the session open to attacks.


TLS cipher suite for DH_RSA (with many bits snipped out, order could be slightly broken):

    Client to Server: Hello
    Server, internal: B=RND(P), b=(g^B)%P
    Server to Client: Hello, Cert_Server, g, P, Sign({b}, Key_Private)
    Client, internal: Somehow Validate Cert_Server and, if valid,
    Client, internal: A = RND(P), a = (g^A)%P, K = (b^A)%P
    Client to Server: a
    Server, internal: K=(a^B)%P

Here we have the merging of both protocols. We fix the MITM attack DH Key Exchange suffers by signing the DH ephemeral, b, from the Server. The client and server then use DH Key Exchange to produce the session key, K.

Answer to Theft Question

OK, so after that long interlude, what about use of a Server's Certificate and a DNS hack to faking (with security) a legitimate web site?

Go back and have a look for Private_Key in three of the four protocol descriptions above. You'll see that in each case, the Server is either decrypting some message with it or signing some message with it. So, unless the attacker has stolen the Server's Private Key, he cannot impersonate that Server by running the server side of each of these protocols. The client may detect the failure of the Server by a number of means. I detail each detection for the algorithms below.

  • RSA - Strictly speaking, the client cannot detect the server failing to have the private key in this case. If all the client ever does is RSA encryption with the Server Public Key, the client will never know the Server isn't legitimate. OTOH, the fake server cannot decrypt the data, so this isn't the worst situation, although it's not optimal. However, and this is a big however, no communication system would be built s.t. client sends server messages without a server ever being challenged. That is, the server must prove its knowledge of the private key at some point before the client trusts it. So, the fake server will be detected eventually, if not exactly within this algorithm.
  • DH - DH Key Exchange - Ignoring the MITM attack, here, the session key, K, a.k.a. Master Session Key, is used to generate a number of other keys for Privacy (encryption) and Integrity (hmac). In the next step the client and server use these generated keys to challenge each other to prove they know the keys. This amounts to correctly encrypting and hmac'ing data and sending it back and forth. I will show what that looks like below.
  • TLS & RSA - Same as DH, next step, mutual proof of Keys.
  • TLS & RSA & DH - There are two touch points here and an attack I want to highlight. First, if somehow we make it to the DH Key exchange step, both sides would do mutual proof of Keys. However, notice the Sign(b, Key_Private) step? A fake server without the Private Key couldn't perform this signature, so the client would know (because it should check) at that point that the server is fake. However, there's an attack here. Attacker can run this cipher suite with the real server, which will send it a signed ephemeral! That is, the fake server could fetch (one time only needed) a copy of Sign(b_old, Key_private). The client validates the signature and everything looks good. This is why the client must eventually authenticate the server using the generated session key.

Finally, sample mutual proof of keys a.k.a. client and server mutual authentication:

    ... continuing exchange ...
    Client, internal: K_enc = F1(K), K_mac = F2(K), Nc = NONCE
    Client, internal: Ec = Enc(Nc, K_enc), Hc = HMAC(Nc, K_mac)
    Client to Server: Ec, Hc
    Server, internal: K_enc = F1(K), K_mac = F2(K), Ns = NONCE
    Server, internal: Hc == HMAC(Dec(Ec, K_enc), K_mac)?
    Server, internal: Es = Enc(Ns||Nc, K_enc), Hs = HMAC(Ns||Nc, K_mac)
    Server to Client: Es, Hs
    Client, internal: Hs == HMAC(Dec(Es, K_enc), K_mac)?

Please note the two internal steps, one for the server and the other for the client which look like this: Hs == HMAC(Dec(Es, K_enc), K_mac)? This is the mathematical proof that client runs to prove the server knows the session key, could produce the encryption and hmac keys, and was able to decrypt the Nonce, Nc, it sent over (server concatenated to Ns).

That specific check breaks down as follows:

  1. Decrypt Es using K_enc. Plain text is Ns||Nc.
  2. Check that plaintext Nc matches the Nc client first created.
  3. HMAC(Ns||Nc, K_mac). Run our own version of HMAC on Ns and Nc.
  4. Check that HMAC == Hs. If equal, all good.

All of these steps constitute a proof of the various steps that came before and allow the server to prove to the client it is legitimate.

I hope that answers your question.

  • Thanks for all that Andrew, really appreciate it. When I said 'steal the certificate', I did mean the certificate and its public key. The reason I asked that was I thought some could take a web servers' certificate and place it on their own, edit a PCs host file and have the DNS entry point to an attackers server. I knew they couldn't do an attack without the corresponding private key, but I was curious how this would appear in the 'victims' browser as the DNS name in the browser matched that on the certificate and signed by a trusted source.
    – RJSmith92
    Commented Nov 15, 2015 at 18:03
  • The signature on the certificate may be be valid (not too sure on this, the hash hasn't changed so it may still be valid) and signed by a trusted authority. I originally thought the browser may show it as 'trusted' with the green padlock. I have since learnt that it won't show as trusted without being able to complete the handshake, which requires the server to have the corresponding private key regardless of whether DH or RSA is used to generate the session key. Thanks again @Andrew
    – RJSmith92
    Commented Nov 15, 2015 at 18:10
  • Ah, got it! Thanks for clarifying. I will update my answer to reflect this. Commented Nov 15, 2015 at 21:54
  • @RJSmith92, answer now shows exactly how client can prove server is legitimate by knowledge of Private Key or server faking handshake bits and getting caught at the end of the key exchange proof phase. Commented Nov 15, 2015 at 22:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .