Goal of CA is to allow clients ability to determine if TLS was tampered with while "in-transit"?

I believe my question will be a continuation of questions such as:

What’s the point of the CA?

How does a digital certificate prove authenticity?

In short, I still don’t have a firm grasp on why a TLS certificate signed by a reputable and public Certificate Authority (CA) is “better” than one that is not. I feel like I am not “connecting the dots” on this topic because I’m not seeing step-by-step examples of how a hacker can take advantage of TLS certificate that’s not been signed by a CA.

EDIT

Actually, I spent a few days thinking through hypothetical situations. My current understanding is the main problem a CA is trying to solve is to ensure TLS certificates are not tampered with while in-transit between server and client. Is that correct? Please correct me if I am completely missing the point on what CAs are all about.

Here’s a more detailed explanation of what I understand. I’ll frame my understanding in the form of Problem and Solution and communicate my ideas with step-by-step demonstrations and use of pseudo-code.

Problem

A TLS certificate contains a public key and the Subject Alt Name (SAN) or Common Name (CN) of the entity the public key is meant to encrypt information for. The public key is susceptible to being altered while in-transit from server (eg. Apache web server) to client (eg. FireFox web browser) in the form of man-in-the-middle attacks. Undesirable ways a TLS can be altered while in-transit are:

• an unauthorized entity can intercept transmissions between server and client and inject a fraudulent public key into the TLS certificate. If client uses fraudulent public key to encrypt information and then clients sends this encrypted information to server, the unauthorized entity can intercept transmissions and decrypt the information with the unauthorized entity’s corresponding private key.

• network connectivity issues could corrupt the TLS certificate, which could corrupt the public key and make the public key unuseable

To demonstrate this problem, I will use an example:

Assume there are 3 players for our example: AcmeCorp, FireFox web browser, and Hacker.

AcmeCorp is a legitimate company and wants to create a website https://acmecorp.com. AcmeCorp wants use a TLS certificate on their website https://acmecorp.com/. The website uses Apache Webserver. Apache Webserver needs two files to serve acmecorp.com over TLS. The two files required will be acme.cert and acme.key, which are the TLS certificate and private key respectively. The acme.cert contains a public key which can be extracted.

FireFox webbrowser is used by a real human customer. FireFox web browser visits https://acmecorp.com. FireFox receives acme.cert during TLS handshake. FireFox extracts public key from acme.cert and saves it as acme.pub. FireFox encrypts all information with acme.pub before sending it to acmecorp.com.

Hacker wants to steal information between FireFox and https://acmecorp.com. Hacker has the files hacker.cert and hacker.key, which are TLS certificate and private key respectively. The hacker.cert will have almost identical information to acme.cert, except the public key included in the hacker.cert is different from the public key acme.cert. The hacker.key can be used to decrypt information that’s been encrypted by the public key in hacker.cert. Hacker wants to intercept transmissions from acmecorp.com and replace the contents of acme.cert with contents of hacker.cert.

As it stands now, it is very easy for Hacker to intercept transmissions from acmecorp.com to FireFox and replace the contents of acme.cert with the contents of hacker.cert. There is no way for FireFox to know if such modifications took place while acme.cert was in transit. If FireFox uses the public key from hacker.cert, then Hacker will be able to decrypt all of FireFox’s transmissions using hacker.key.

Solution

The goal of a Certificate Authority is to provide client applications the ability to identify whether TLS certificates were tampered with or altered while in-transit from the server to the client application.

AcmeCorp can offer FireFox a way to verify whether the contents of acme.cert was modified by having a trusted third party called a Certificate Authority create the acme.cert on behalf of AcmeCorp. The TLS certificate creation process for acmecorp.com becomes:

TLS Creation Process

1. AcmeCorp owns the domain acmecorp.com.
2. AcmeCorp uses OpenSSL to create a private key and a CSR. The CSR has a public key, a SAN/CN of acmecorp.com and all the meta information to create a TLS certificate for the domain acmecorp.com.
3. AcmeCorp gives the CSR to a CA.
4. CA sees that the CSR is for the domain acmecorp.com.
5. CA does DNS checks to ensure AcmeCorp does own the domain acmecorp.com. If checks fail, then abort process.
6. CA creates a temporary file called temp-cert.pem based on the information of the CSR.
7. CA creates a TLS certificate file and digitally signs the TLS certificate with a command like MakeTLSCert(outfile: 'acmecorp.cert', infile:'temp-cert.pem', hash:'sha256', cakey:'ca.key'). My understanding of this step is weak, but i’m guessing it is broken down into these steps:
   7.1. hash the contents of temp-cert.pem with sha256 and call the result a message digest.
   7.2. encrypt the message digest with CA’s private key ca.key and call the result the CA digital signature.
   7.3. concatenate the temp-cert.pem and the CA digital signature and call this the acmecorp.cert, which is the TLS certificate.
8. CA gives acme.cert to AcmeCorp.

Now AcmeCorp can use acme.cert and acme.key with Apache web server to serve https://acmecorp.com over TLS.

If a Hacker tries to perform steps 1 to 8, the hacker will fail at step 5. That is, a CA will see that the hacker does not own the DNS records for acmecorp.com. Therefore, the CA will not issue a certificate that has the CA’s digital signature.

Next, these are the steps that FireFox will use to identify a legitimate TLS certificate, that is, differentiate between acme.cert and hacker.cert by inspecting the contents:

TLS verification

FireFox comes bundled with the Public Key of reputable CA. Let’s say FireFox has the public key of the reputable CA used in the steps above and it has the file name ca.pub. When FireFox visits https://acmecorp.com, the following happens:

1. FireFox receives TLS certificate.
2. FireFox extracts public key from TLS certificate.
3. FireFox asks if public key can be trusted. The next step and onwards are meant to answer this question.
4. FireFox sees a CA digital signature in the TLS certificate.
5. In step 6 of the TLS creation process, temp-cert.pem is the first half of the TLS certificate, and the digital signature is the second half. Hence:
   5.1 FireFox uses the ca.pub to decrypt the digital signature which yields a message digest (note, only ca.pub can decrypt information encrypted by ca.key). We now have the message digest that made by the CA.
   5.2 FireFox uses the ca.pub to sha256 hash temp-cert.pem of TLS certificate to create another message digest.
6. FireFox compares the message digest of step 5.1 and step 5.2 to make sure they are the same. If they are not the same, then it means the TLS certificate was modified while in transit from acmecorp.com to Firefox.

Final Questions

Did I mis-understand anything? Specifically:

1. Did I mis-understand the main goal(s) of a Certificate Authority?
2. Did I mis-understand how the Certificate Authority achieves its goals?
3. Does anything I’ve said change between TLS1.2 vs. TLS1.3? I think everything I’ve said so far applies to TLS1.2 . If I were to guess how this applies to TLS1.3, it is that public keys in TLS certificates are used for generating symmetric keys in the Diffie-Hellman algorithm as opposed to being used for encrypting information. Hence, the function of CA digital signatures to allow FireFox a way to verify TLS certificates coming from the server were not tampered with still applies…because incorrect public keys means you are generating the wrong symmetric keys which a hacker can exploit. Is that correct?