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?