How to recognize fake SSL certificates?

Question

I've read about SSL protocol and now, I know how it encrypts data. But there is something I couldn't understand. With SSL , you're sure you're sending data to and getting data from correct server. But how?
I mean if I create a fake certificate and send it for requests of special website, how do browsers ( or other programs) detect the fake certificate?

Edit: I didn't mean to create a self-signed certificate. I meant how can someone validate my certificate if I create a certificate that its issuer and subject ,etc are something to real certificate! (the only things that are not real is Public key & signature)

Answer 1

SSL certificates are signed by a certificate authority (CA), which is someone the user already trusts (or more likely, the people who designed their operating system trusts).

The CA digitally signs the certificate using public key encryption. The basic explanation is that the CA has a "private key", and a "public key" that everyone knows. Via some math I don't understand, the CA can create a signature using its private key which can easily be verified with its public key (but the public key can't be used to create a new signature).

When you get an SSL certificate from a server, you get the server's public key, and a signature from a CA saying that it's valid (along with some other info). If you know and trust that CA, you can check the signature and determine if it's valid. You can also use a certificate revocation list to make sure it wasn't revoked.

So basically, you can recognize a bad SSL certificate because it isn't signed by a certificate authority that you trust.

Answer 2

TL;DR summary:

Validity of a server certificate is established by:

• Host name verification
• Verifying the signatures of the entire certificate chain
• Performing additional checks on meta data for each certificate
• Checking the revocation status of each of the certificates involved
• Checking whether the self-signed root certificate of the chain is among the certificates that one trusts by default

Explanation

Let's assume you want to connect to https://mail.google.com (you can try this out in your browser!).

The (real) server will respond with a certificate that is issued to mail.google.com, i.e. in the 'Subject' field of the certificate you will find the Common Name (CN) 'mail.google.com' - cf. RFC 5280 for details on the fields of certificates. The fact that the subject is linked to the site URL is very important for the security of the whole model, and it is actively checked by your TLS implementation ("host name verification"), because otherwise there would be room for Man-In-The-Middle attacks. I.e. somebody could acquire an otherwise valid certificate and impersonate mail.google.com without you taking any notice of it.

In addition to the host name verification, your TLS implementation will also check the "validity" of the certificate. The whole procedure is rather complex and does include checking the trustworthiness of the certificate, but additionally a lot of other things will be checked, more on that in a minute.

If you view Google Mail's certificate in your browser, you will notice that there are actually three certificates shown:

• mail.google.com
• Thawte SGC CA
• Class 3 Public Primary Certification Authority (VeriSign)

The model is that there are a few (well, unfortunately not so few anymore) trusted root certificate authorities ("root CAs") that either you could choose on your own or (more likely) that come preconfigued with your software (e.g. browser) that are blindly trusted. These trusted authorities form the anchors of the entire trust model of "PKI" (Public Key Infrastructure). The basic idea is that the trusted entities may issue certificates to other authorities and grant them permission to again issue certificates (these authorities are called intermediate certificate authorities). The intermediate CAs may again recursively apply this procedure up to a certain point, the number of intermediate CAs between an actual end entity certificate and a root CA certificate is generally limited.

At one point, an intermediate CA will issue certificates to an "end entity" ("mail.google.com" in our example). Now the process of issuing a certificate actually means that the party requesting a certificate will create a public/private key pair first, and use them to authenticate a certificate request that is sent to the certificate authority. The issuing authority creates a certificate for the subordinate entity (either intermediate CA or end entity) by "signing" that certificate using its own private key using an asymmetric algorithm such as RSA and by additionally including the public key of the requesting party within the newly generated certificate. The root CA possesses a so called self-signed certificate, i.e. the root CA is the only authority that may sign their own certificate and include their own public key. The private key remains hidden at all times, of course.

The recursive nature of the certificate issuing process implies that for each end entity certificate there is a unique way of establishing a "chain" of certificates that leads up to a root certificate authority. Now when you are presented with an end entity certificate while trying to connect to a TLS-secured site, the following procedure will be applied recursively until you end up with a root CA certificate:

• Find the certificate of the authority that issued the certificate to be validated (see RFC 5280 for details). If none is found: exit with error.
• Take the public key of the issuing certificate and verify the signature of the to-be-validated certificate using this public key.
• Check a lot of additional things such as whether the certificate has neither expired nor is it not valid yet, "policy constraints", "key usages", "extended key usages"... (again, the gory details are in the RFC).
• Certificate revocation status (more on that later)

If all checks were positive, you will ultimately end up with a certificate being self-signed, i.e. where the subject is also the issuer (such as the VeriSign certificate in our example). Now the last thing you have to verify is whether this certificate is among those that you blindly trust: if it is, all is well and the connection will succeed, if it is not, the connection attempt will be rejected.

As if this were not complicated enough already, the checks described so far do not handle cases where once valid certificates suddenly become rogue, examples being cases where a certificate is stolen or private keys are compromised (think of Comodo and DigiNotar). In these cases, the normal procedure is to "revoke" those certificates gone bad, that is you want to mark them as being invalid starting from a distinct point in time (they will expire at some point anyway, but for the remainder of that period they shall already be marked as invalid). For these cases, CAs have the possibility to issue CRLs (a catalog of certificates declared as invalid) or OCSP responses (information for one or in rare cases a set of certificates) that provides clients with information whether a given certificate has been marked as invalid or not. The revocation status needs to be checked for all certificates in a chain, should one of them be marked as invalid then the end entity certificate cannot be trusted and the connection must be rejected as well.

Answer 3

Any fake certificate you create will be a self-signed certificate.

The browser will display big scary warnings when connecting to a site with a self-signed certificate _{which the user will promptly ignore.}

In order to avoid warnings, you need a certificate signed by a certificate authority that the browser trusts, such as VeriSign.
These companies will ^hopefully make sure that you actually own the domain for the certificate they're signing.

Re: Edit: You can only create a non-self-signed certificate if you get it signed from a trusted CA.
They will refuse to sign a certificate for a different subject.

Answer 4

Process from my understanding:

1. server sends servers public key
2. server sends certificate (all information encrypted by trusted CA with their private key)
3. Your PC decrypts certificate with public key (built into OS from trusted CA)
4. Your PC hashes (with sha1 and sha256) the servers public key
5. Your PC compares the hashes of servers public key with certificate stored hash, if not same browser will block site
6. Your PC compares allowed domains from certificate and the domain, if not allowed, if not same browser will block site
7. Your PC compares valid date from certificate and your date, if not valid browser will block site.

To fake this you would either need to:

• obtain a CA private key (extremely hard to get),
• be a CA,
• be part of the 5 eyes (Government intelligence agency alliance) and ask a CA for their private key

So if you see a padlock in the address bar you are almost always safe.