An answer to question 1:
Yes, except the CA's root is offline in an HSM in a vault, not available to be stolen electronically. The root was used to sign a handful of intermediate certificates (backups and OCSP responder certificates and other stuff) that reside in HSMs that are directly connected to computers that can be reached electronically.
To issue a certificate, the CA "backend":
- receives CSR
- uses some method of validation (ACME protocol, human clicking "ok" on admin website, etc.)
- logs all the decisions and info used to make the decision for checking by later audit
- generates the certificate data (X.509 v3) encoded in X.690 DER, using a template and new serial number / source of randomness.
- maybe gets Certificate Transparency SCTs.
- asks the HSM to sign the blob (or hash of the blob).
- appends signature to certificate and sends it to the customer facing storage.
An answer to question 2:
In RSA key exchange, the client generates a random sequence of bytes and performs RSA encryption using the public key from the server's certificate. Then the client sends the resulting ciphertext to the server and expects the server to decrypt it (using the private key corresponding to the public key from the certificate) and use the random value in a KDF, together with other values, to generate symmetric keys and send a Finished message encrypted with the resulting symmetric keys. The client verifies the Finished message. The server can only succeed in generating the expected symmetric keys by decryption RSA encrypted message. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2
In DHE/ECDHE key exchange with PFS, the server signs its ephemeral key using the private key corresponding to the public key in the certificate and sends this in ServerKeyExchange. The client verifies the signature using the public key from the certificate. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.3
An answer to question 3:
The browser contains a list of trusted roots (Mozilla Firefox does this) or uses a list of trusted roots provided by the operating system (Google Chrome uses the OS roots store). The root store contains self-signed certificates and some metadata about them that might constrain what they can be used for. Browsers also contain code that adds additional checks, like Chrome requiring Certificate Transparency from Symantec-owned CAs and the cutoff dates that allow using SHA1 certificates.
The way a leaf server/domain certificate is verified using the root store is by building a chain of intermediate certificates, one signing the other, from a trusted root to the leaf. The root signs an intermediate and the intermediate signs the leaf. There can be more than one intermediate in a chain. The intermediates are sent by the server together with the leaf.
Different computers have different root stores and by using cross signing, many different paths can be built. Currently the browsers try to build sha256-only paths if possible, sometimes fail and produce an error saying only a sha1 path was built thus the connection might be insecure.
Do not confuse digital signatures with encryption: https://security.stackexchange.com/a/87373/70830