The question I have is simply how do I prevent a MiTM attack on a certificate once the server side creates a new one and tries to send it to a client? Does the certificate get encrypted by rsa and sent or...
You have two potential attacks:
The attacker poses as a fake server, and talks to the genuine client, feeding him a wrong certificate or other nefarious data.
The attacker poses as a fake client, and talks to the genuine server, obtaining a valid certificate with the genuine client's name but the attacker's key in it.
A man-in-the-middle attack is when the attacker does both simultaneously. However, each attack is problematic in its own right.
Defeating the first attack (impersonation of the server), use the standard mechanisms: have the server use a certificate, issued by a well-known CA, that the client trusts. All HTTPS Web sites do that. This is how, when you connect to
https://www.paypal.com, you get the nifty padlock icon and know that you are really talking to Paypal's server.
To defeat the second attack, well, it is up to you: the server is creating and sending a certificate to "a client who just connected". How does the server know what to put in the certificate ? From where comes its knowledge of the client's identity ? If, for instance, the "genuine client" is authenticated by virtue of having been granted a one-time registration password, then the communication will occur within a HTTPS connection. In that connection (where the server is verified as "true" by the client, see above), the client sends its one-time registration password, and the server, from that point onwards, knows that it is talking to the expected client, and can send him a certificate or whatever it wishes to send him.
Use HTTPS as Tom Leek suggested in his answer. Additionally, request a password from the user and send them back an encrypted PKCS-12 formatted file that is encrypted using the password that you got from the user. The PKCS-12 file will contain the user's certificate and private key. Optionally, you can also sign the PKCS-12 file using your server's certificate, although I don't think that's necessary because the certificate contained within the PKCS-12 file is already signed by a trusted, valid CA.
I posted this as a separate answer because I don't consider it sufficient to send private keys over SSL when there is a standard procedure known as PKCS-12 that is used to protect the keys in certain cases, such as when you send it over unsecure networks. However, if your only goal is to defeat a MITM attack, Tom Leek's answer may be sufficient. If your goal is additionally to securely send a certificate and private key, then I suggest this answer.