I understand how HTTPS connections work, and I also understand they they require a certificate to know that the secure connection you have is with the right server (and not someone pretending to be the right server). My question is, how are these certificates secure? Why is it hard to fake them?

1 Answer 1


SSL is based on public/private key cryptography. This means that

  • anything encrypted with a public key can only be decrypted with the associated private key
  • the private key can be used to sign a something and that signature can be verified with the public key.

A certificate is a public key with information about the owner attached to it. The owner can either be a person or a domain.

When you visit https://stackauth.com, the server will present its certificate to your browser. The browser checks that the name in the certificate matches the name of the website you requested and if the expire dates are valid.

Then the browser checks whether the certificate was signed by a certificate authority that the browser knows as trustworthy. Anyone who creates a faked certificate has the challenge to get it signed by a certification authority that is trusted by the browsers. There may be a chain of signatures from intermediate certificate authorities which needs to eventually lead to a trusted one.

If any of those checks fails, the browser will show you a warning and require confirmation. If all the checks are passed (or overridden by the user), the browser will use the public key from the certificate to encrypt some information that only the server can decrypt. This information is used to setup a secure session in a couple of more steps.

The main issues with this model is that the certification authorities are the weak link. There is a huge number of CA, that are directly or indirectly trusted by the common browsers. All of them can issue faked signatures, and this has allerady happened a number of times in the past (e. g. Verisign, Comodo, Diginotar).

  • This can be easily worked around using a well-known browser issue where browser trusts the certificate to be an intermediate certificate authority to sign certificates. So if you have bought a VerySign (root CA) certificate for example.com, you can use your certificate to sign ebay.com certificate, and some browsers can trust that it's ebay.com if it isn't (when using MiTM attack). Commented Dec 5, 2011 at 21:51
  • @philpirozhkov. The term "root certificate" refers to the root of the trust chain of multiple intermediate certificates; in other words: A root certificate is a certificate that is hardcoded in the browsers. Commented Dec 5, 2011 at 22:17
  • @philpirozhkov There are different types of certificate usages that are part of the signature. So a certificate for servers cannot not be used to create valid signatures on other certificates. (Around 1997 there were a couple of programs which did not enforce the certificate usage. e. g. Microsoft accepted Active X controls signed by a time service and Sun Java accept certificates for emails on Webstart code). Those issues have been fixed a long time ago. Commented Dec 5, 2011 at 22:17
  • 1
    @philpirozhkov There is a namespace extension to restrict intermediate certificates to specific domains, but it is hardly used. The trusted CA authorities can make a lot more money by requiring customers to buy individual certificate for all their servers, instead of issuing a intermediate certificates, which can be used by the customer to create any amount of certificate for the servers in their domain. Since it is not widely used, I am not sure how well it is supported by browsers. Commented Dec 5, 2011 at 22:26

You must log in to answer this question.

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