Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My question is what would prevent a person from taking a certificate and using it to make their fake site look legit. Say you log onto Amazon and your browser grabs that certificate. Then that person sets up an spoofing site and uses that same certificate to make the browser think this is legit to the people that clicked on the link. Or if the certificate is unique to that specific computer what keeps a man in the middle from intercepting that certificate and using to pose as the site?

Thanks in advance.

share|improve this question

The Certificate presented on the site includes the public key of the site, in addition to identifying information, and a digital signature. You use the public key to encrypt information, which in turn can only be decrpyted with the private key. The digital Signature is what verifies that the information has only come from the private key holder (verifies the identity of the site by signing with the private key). Using the public key to encrypt data, only the private key holder (the original site presenting the certificate) would be able to decrypt it. So, no one else would be able to decrypt that data.

As Zoredache points out, you need both keys to perform any kind of impersonation.

share|improve this answer
Though the gist of your answer, a hijacker needs both parts of the key, is valid you have some inaccuracies in what you are saying. The public key can never decrypt data. A public key can only be used to encrypt data, and only the private key can decrypt. – Zoredache Jul 31 '11 at 6:46
@Zoredache: Typically, in a public-key cryptosystem, you have, for a message M and a key-pair P,S and two operation E,D that D(P,E(S,M)) == D(S, E(P, M)) == M; that is, encryption of a plain-text with one half of the key-pair, followed by decryption of the crypto-text with the other half of the key-pair results in the plain-text. – Vatine Jul 31 '11 at 10:04
@Zoredache, thanks for the clarification, I slightly misunderstood the concept. I have updated my answer. – HostBits Jul 31 '11 at 13:09
@Valtine, actually, because the purposes are different, that makes 4 operations: deciphering and signing using the private key, and encrypting and signature verification using the public key. – Bruno Aug 5 '11 at 13:36
@Cheekaleak, you need both keys indeed, but some private key storage formats also include the public key. With RSA, it's often easy to find out the public key using the private key (the public exponent is often quite small, "65537" is used in many cases). – Bruno Aug 5 '11 at 13:39

Just a few points to add to @Cheekaleak's answer.

The Certification Authority (CA) is the entity issuing a certificate for a server (amongst other things). By doing so, the CA signs with its private key the content of the certificate and adds its signature.

To indicate who signed the certificate, X.509 certificate have an Issuer Distinguished Name naming the CA, in addition to the Subject Distinguished Name identifying the entity for which the certificate is issued.

CAs themselves have CA certificates, that is, certificates that can be used to issue other certificates (by signing the issued certificate using the private key matching the public key in the CA certificate, and by using the CA cert Subject DN as the cert Issuer DN). This builds a hierarchy from CAs to End Entities (e.g. servers), and there can be intermediate CA certificates (i.e. a CA cert used to issue another CA cert, which may then be used to issue an end-entity certificate). The root CA certs at the top tend to be self-signed.

The way browsers evaluate their trust into a given End Entity Certificate (e.g. a server certificate) is by building the certification chain between the EE cert and a CA cert they already trust (trusted anchors). Most OS/browsers come with a bundle of CA certs trusted by default. (The second aspect of this is that the browser verifies the EE cert has been issued to the name of the server it wants to connect to.)

The main problem of this model comes from the fact you don't really know why you should trust the CA certs that are bundle by default with the software you get, because a rogue or badly-managed CA that would have its CA cert in your trusted anchors could issue a certificate with the name of the legitimate website.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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