How can the issuer certificate be verified?

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.