How can the issuer certificate be verified?
I'm trying to understand how digital signing using x509 certificates works. I read a few articles and related answers on the web, but still there are a few questions left to confirm my understanding:
This great answer of PTW-105 explains how the certificate trust chain is being verified. But what is missing is how the verifying party can get the issuer's certificate which was used to sign some derived certificate. The only idea I have is that it is embedded into the derived certificate as other information. In this case certificate size would grow with each level of the certificate trust tree. This was already asked as a comment, but still left unanswered.
How do client applications such as the browser or MS Word know which certification authorities are trusted root authorities? Are they just hard-coded into every application? How big is the list of root certification authorities and who manages it? What if some application developers forget to include one of the authorities (or just a new one is registered) - their certificates won't be considered trusted, will they? So is it possible that some site is trusted in Chrome, but non-trusted using Firefox (it can be derived from here). What if an attacker manages to include his self-issued certificate into some trusted storage: it might be the victim's computer trusted root certificates list, or her enterprise domain trusted certificates. I know it's an unlikely scenario, but would it work?
Similar scenario to #3: patch a client's application such as MS Word (or share a patched version on the web for everyone to download freely) so that it considers the attacker's certificate to be the root certification authority. Would that work?
The browser has a database of trusted certificates, who are known to verify identity before signing. If the derived certificate is signed by one of those, then it checks out.
However, there are some CAs known as 2nd level. In this case a certificate chain is used. The server provides the certificate that needs to be verified. The server provides the issuer certificate. Following the chain, we reach the top-level certificate which is already in the browser's database of trusted certificates Naturally, the top-level certificate issuer will be very careful about authorising 2nd-level CAs. There is quite some process, but the important thing is that new CAs can be signed by existing ones for compatibility with older devices. The only idea I have is that it is embedded into the derived certificate as other information.
Yes, the certificate to verify does indicate the fingerprint or similar identification of it's CA certificate. This way the browser knows which CA cert to use. In the case of chain certification, the whole certificate is included. (#2 above) (not just the fingerprint) That certificate has the fingerprint of a top-level CA (#3 above) that is (hopefully) already in the browser's keystore. In this case certificate size would grow with each level of certificate trust tree. If there are 2-3 certificates in the certification chain then yes it does take more space, (which could be considered 'certificate size') but that's hardly a problem.
- As for the ever-growing browser certificate store, there is actually only a limited number of CAs, even accounting for the ones that are not top-level, so this is not a practical problem either.
- Some 2nd-level CAs could be trusted in one browser, and not in another. So the CA who issues your certificate often provides intermediate CA certs so that the apps will always be able to trace back to a top-level CA in their store.
- The CA must keep their private key secret, or else it can be used to sign any and all domains. CAs are trusted because it is known that
- They have good security measures to protect their private key.
- They verify ownership before issuing a certificate.
If an attacker can access a victim's computer (presumably the victim has bigger problems at that point) and inserts a trusted certificate, then that attacker has means to successfully MiTM the https connections. Eavesdropping, or altering the connections at will, if he can get a device in between the victim and the server. (i.e. WiFi interception, or physical network connection) Yes, but presumably if you can patch the client application then the victim has lots more to worry about.