Ttdfjt

I understand that Digital Certificates and Certificate Authorities (trusted 3rd parties) help prevent man in the middle attacks during HTTPS connections. However, I am confused on a few details.

Let's say we have a client Alice and Bob who has a server mapped to "bob.com".

When Bob (bob.com) asks a CA (let's say veriSign) for a new certificate to be created and sends them his public key to be put inside the certificate, what is stopping a hacker from intercepting the request, switching the public key with their own, having the CA create a false certificate, and then returning this false certificate to Bob. Is the only protection here that Bob actually checks that the public key on the returned certificate matches what he originally sent in his request to the CA? And then I guess informing the CA that what he got back doesn't match what he sent out, so the CA doesn't maintain a false record?

Assuming that the newly created certificate Bob gets from veriSign is legit, let now say that Alice is going to make a request to "bob.com" via the HTTPS protocol. What is preventing a dual channel MITM attack where a hacker intercepts Bob's new certificate on way to Alice, creates a new one, signs it with their own secret key (which was previously signed by verisign), but then also intercepts Alice's request to veriSign when she asks for veriSign's public key, and switches it out again with the matching public key to the malicious secret key. Now when Alice tries to check the integrity of the false certificate, it checks out because although she thinks she is checking the signature with veriSign's public key, she is really using the malicious public key?

Is the only protection here that Bob actually checks that the public
key on the returned certificate matches what he originally sent in his
request to the CA?

If the public key was switched before the CA used it to create the certificate, then Bob's web site won't work at all. The private key, which he has kept safe, will only work with his original public key. It is unlikely the attacker can MITM all connections and prevent this fact from becoming obvious.

intercepts Alice's request to veriSign when she asks for veriSign's
public key, and switches it out again with the matching public key to
the malicious secret key.

Alice doesn't reach out to Verisign; Alice only trusts copies of the CA certificates in her browser or computer's trusted certificate store, of which Verisign's happens to be one.

The trusted certificate store is populated at install time (of the OS, or in the case of Firefox, of the application) and is then updated via regular OS or Application updates as necessary - less than you'd think, as many root CAs are long-lived.

Good question. The certificates of the most trusted CAs are normally included into software install package, e.g. into browser installer, into OS installer, or are preinstalled on device like smartphone. That's why the browser (or some other application) will notice if certificate is really from the specified CA.