It is possible to copy the server certificate to attackers server to misuse it?

Question

I aks myself if it is possible to copy the server certificate to another server to misuse it. Example: An attacker visits https website X and copies the X.509 certificate. He placed the stolen X.509 certificate on his own server and would like being trustworthy.

Of course, the attacker does not have the private key, but the private key is only required to decrypt the encrypted message from the client. In terms of authentification there is no reason to be doubtfully. Or?

The server responses with the X.509 certificate. The client receives the certificate and validates successfully using the stored root certificates. Why should the server not be authentificated? Only when the client sends an encrypted message using the public key the server is not able to decrypt the message - because he does not own the private key.

It is right so far?

Answer 1

Why should the server not be authentificated?

The certificate is tied to a domain name.

The web browser will download the certificate and validate it. One of the steps in the validation is to compare the domain the certificate is for to the domain that the browser actually downloaded it from. If there is a mismatch (and there will be, since the attacker is on their own domain, not the original site's domain) then the browser will present the user with a certificate error and ask them to make the call about whether or not to accept it.

You're probably used to seeing this in action on bad web server configurations. Ever seen an error saying, "This certificate was intended for www.example.com" when you were trying to visit "example.com"?

Of course, the attacker does not have the private key, but the private key is only required to decrypt the encrypted message from the client.

Public/private key pairs have other uses than that. In this case, the private key signs the certificate and the public key verifies it. There is no encryption involved. (What you described is more like a normal encryption scheme, like RSA.)

Answer 2

Only when the client sends an encrypted message using the public key the server is not able to decrypt the message - because he does not own the private key.

The server also needs the private key to sign messages being sent to the client.

The SSL/TLS handshake protocol itself effectively involves such an authenticated message being sent to the client. If the private key is unavailable then this step will fail before any 'real' payload message gets sent.

Answer 3

No, the certificate is a pubic element and it is just a way to bind a public key to a name (here, a DNS name). During the authentication process (in the TLS protocol) the server sends its certificate along with signs some data with the associated private key. In order to verify that the server is the legitimate owner of the certificate, the client have to verify the validity of this signature with the sent certificate. A rogue server can try to use the certificate but without the private key it cannot prove it is the real holder.