0

I have misconceptions regarding CA (Certificate Authority) certificates. No matter how many things I read, it is still not fully clear.

Let's take an example, Bob accesses a website. In order for trusted and encrypted communication to happen between Bob wand the website, the website first issues Bob with a digital certificate, which contains a public key and other information.

Bob will then use this public key to encrypt the data in which he will send to the website, and the website will use the corresponding private key to decrypt it. (Just considering one-way communication here)

A man in the middle could pretend to be the website and supply Bob with what he believes is a valid digital certificate and then things go horribly wrong.

If the website uses a CA for this problem to validate or generate its own certificate, which one of my statements is correct, or are both partly correct? :

1 ) Bob simply compares the digital certificate received from the website with the one from the CA, so no decryption is performed, just comparison? In this case, Is every single CA certificate in the world stored on Bob's local computer to compare with? How does this happen.

2) Bob just has a special CA certificate which is used to decrypt certificates from sites. The CA has previously encrypted the digital certificate of the website which Bob wants to use with the CA private key. Bob then gets the certificate from the site, decrypts it with the CA's public key from the CA's certificate. If the certificate can't be decrypted, it's obvious that the CA did not encrypt it and so invalid.

Thanks in advance.

Improve this question
4
  • "A man in the middle could pretend to be the website and supply Bob with what he believes is a valid digital certificate and then things go horribly wrong." - The initial handshake would prevent this. Bob would either be connected to the legitimate website or the "man in the middle" at no point could Bob be switched from the legitimate website to the"man in the middle" since the "man in the middle" could not decrypt the data between the server and the Bob. The initial handshake also will identify whom the certificate belongs to, either the server or "man in the middle".
    – Ramhound
    Commented Nov 28, 2018 at 22:14
  • @Ramhound 5 , I am only speaking about the initial hand-shake here
    – Engineer999
    Commented Nov 29, 2018 at 3:48
  • Bob would have to visit a fake website to be served a certificate he thought belonged to the website he was attempting to visit. The "man in the middle" attack you describe is not possible if Bob actually visits, the website he intended to visit (unless he literally has "man in the middle" hardware installed within the network) but that isn't what you are trying to describe.
    – Ramhound
    Commented Nov 29, 2018 at 3:56
  • AV software in order to scan HTTPS traffic will route all HTTPS traffic through its process, but this requires a "man in the middle" attack, which means every certificate must be signed by the AV. The website would still serves the correct certificate, but the certificate the browser displays, would be the fake certificate signed by the AV software. However, this is not the attack you describe, since the AV software was installed by Bob.
    – Ramhound
    Commented Nov 29, 2018 at 3:59

2 Answers 2

Reset to default
0

You do have a misunderstanding. In fact, both your scenarios are wrong.

First, a digital certificate is issued by a Certificate Authority (CA) and contains the public key for digital signing and specifies the identity of the signer. The certificate is used to confirm that the public key belongs to the signer, where the CA acts as the guarantor.

The certificate is verified against the CA via Internet and not locally, as regarding the validity of the certificate, retrieving from the CA the public key in the process.

The public key is used to verify, using a hash algorithm, that the signed object was truly the one signed and was not changed in any way.

As a picture is worth a thousand words:

enter image description here

Source : Understanding digital signatures.

Improve this answer
5
  • 1
    "The certificate is verified against the CA via Internet and not locally" – I'm not sure, are you talking about OCSP here? Signature verification is always done offline, and the only network traffic is usually to check whether the certificate hasn't been revoked yet.
    – grawity_u1686
    Commented Nov 28, 2018 at 22:10
  • To add to this, that's also what the different local Certificate Stores are for (e.g. Trusted Root Store, Intermediate Root Store, etc.). Also, your post doesn't address SSL/TLS and/or server-only versus mutual auth in SSL/TLS.
    – thepip3r
    Commented Nov 28, 2018 at 22:13
  • @grawity: Signature is described above. Certificate verification is done online. Some caching always exist, but is just an optimization.
    – harrymc
    Commented Nov 29, 2018 at 7:31
  • @thepip3r: Where known CAs are stored, whether certificates are cached, and the Internet protocol used for communicating, all these are only additions to the subject, which is how certificates are processed. This post did not ask for a treaty of the whole subject of authorization, which can easily fill a book.
    – harrymc
    Commented Nov 29, 2018 at 7:35
  • The certficates on your machines are not "CAs", they are certificate stores. And they are where you or your org defines the CAs that are trusted. e.g.: If you visit somewebsite.com and somewebsite's SSL cert is provided by Verisign but your local machine doesn't trust the Verisign CA that that was issued to somewebsite.com, then your browser will throw a validation error. His question specifically asked about web-based certificates so it seems that at least covering the SSL/TLS handshake is relevant.
    – thepip3r
    Commented Nov 29, 2018 at 15:27
0

First of all, there are two steps to verifying a CA-issued certificate:

  1. Is this specific CA trusted to issue certificates at all?
  2. Has this certificate really been issued by the CA that it claims to be?

Both of your descriptions are nearly right for one half of the whole process but completely ignore the other half. Combine the two, and you're kiiiinda on the right track.

But the second point: Encryption is not used at all in this situation, and certificates (containing public keys) may be used to encrypt data, but not to decrypt it. What's performed is signature verification.

(I suspect that some of your confusion is caused by having read somewhere that e.g. "in RSA, encryption and signing are the same". Forget that. Although mostly correct in the mathematical sense, it is incredibly misleading in practice, as the intention is completely opposite between the two. So when you're reading a document that talks about signing something, do not assume it means the same as encrypting it.)

"Has this website's certificate really been issued by the CA that it claims to be?"

Variant #2 is almost correct about this one. There are at least two certificates involved – one representing the website (the "server certificate"), and one representing the CA itself (called the "CA certificate", or the root cert).

The website's own certificate is not encrypted with the CA's private key; it is signed with the CA's private key. If the signature cannot be verified, it is obvious that the CA didn't really sign what's claimed.

(In practice, the chain is usually a little longer, consisting of at least three certificates – but the mechanism is still the same; each one signs the next in chain.)

But where does Bob get this "special CA certificate" in the first place? See below.

"Is this CA trusted to issue certificates in general?"

The received CA certificate is compared against a list of "trusted roots" stored within the local computer.

Now that's similar to what you describe in variant #1, except the computer doesn't store all certificates issued by CAs – instead, it only stores the certificates belonging to CAs themselves, i.e. the "special CA certificates" in your variant #1.

There are roughly 50–100 "root certificates" installed on most systems – not quite "every single CA in the world", but it covers many larger and smaller companies. (It costs quite a bit to be included in the list.)

Improve this answer

You must log in to answer this question.

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