Hi @CLogic,
Yes, you're going to have two different keys here. The account key (which the site also refers to as a "Let's Encrypt key") identifies an account, which allows you to issue certificates. You use this instead of a password. Most ZeroSSL users allow ZeroSSL to generate this for them, and you can then save it so that you can re-use the account later rather than creating a new account each time.
The private key for the certificate might also be called the domain key. When you use an externally-provided CSR, you don't actually possess this key. In your case, only the hosting provider possesses the private key corresponding to the certificate; it's something that they generated and then used to create the CSR. (There are different models for this, including some where you would generate this private key yourself—but it looks like that's not what your hosting provider wants you to do here.)
The domain certificate is public data that refers to the certificate authority's confirmation that the person or entity that possesses a certain private key also controls a particular domain name (or combination of domain names). The certificate is what you get from Let's Encrypt at the end of the process and then have to share with your hosting provider. If you pass Let's Encrypt's validation (for example by creating the correct challenge files), Let's Encrypt will issue a certificate that contains the information indicated in the CSR (stating that whoever controls the referenced domain key also evidently controls the domain names, which is not obvious and which it is the CA's entire role to check).
Both the account and domain will keys will normally be an RSA PRIVATE KEY, but in the CSR model that your hosting provider is using, you never see the domain key; only the hosting provider has a copy of it. In this model the only RSA PRIVATE KEY that you will probably get to see is the account key.
The certificate refers to a "subject public key" which is the public key that (1) the certificate refers to the ownership of, and (2) mathematically corresponds to the domain private key. The connection between the subject public key and the corresponding private key is described at
You don't need to make use of any of these details in order to complete the certification process.
In this case, the entity that possesses the private key (here, your hosting provider) is able to use it to make cryptographic signatures that a verifier (here, the web browser of someone visiting your site) can confirm must have been made by the same entity that the certificate refers to, because the certificate refers to the matching public key. This is in turn how we can say that the certificate allows the browser to "know it's talking to" the intended site. Only that site has the necessary information to make digital signatures that match those that the certificate says it should be able to produce.
Yes, that should be right.
Yes, all of these are different kinds of PEM-formatted files, which is a common way of exchanging data related to cryptography. The BEGIN and END stuff I think originated with the PGP encryption software by Phil Zimmermann, and then the people devising the PEM standards must have chosen to imitate it. You should normally always keep these lines in place in order to allow the software (and also any human beings who have to examine the file) to confirm exactly what type of file it is.
I once found a really good introductory article about all of these things, and I've never been able to find it again! They've become pretty much second-nature to me since I've been working on PKI and crypto stuff for a while, but I think most people who deal with this process never quite understand what all of these files are meant for and what role they play in the process. (Note that if you use software like Certbot, it will usually be able to do the entire process for you without showing you any of the files. They all still exist, but Certbot takes care of obtaining and installing the certificate, so you typically don't have to paste anything or e-mail anywhere anywhere.) If I ever find that article again, I'm going to suggest it to everyone who asks these questions; its explanation was much clearer than mine and I think it included samples of the files themselves.