I've been using certbot in manual mode for quite some time now with no problems. I use the following command line in a personal computer running Ubuntu:
sudo certbot certonly --manual
And then I'd go interactively from there, specifying the domain names, uploading the http challenges and so on. I used to include a lot of domains in a single cert, but yesterday I included only two (translite.com.br,www.translite.com.br)
I sent the cert files to the hosting provider as usual, but they say the cert is invalid.
I've already tried uninstalling/reinstalling certbot, to no avail. They still say the cert is invalid!
So, the way most shared hosting providers should work is by them automatically getting the certificate themselves every couple months, and you shouldn't need to do anything at all. So the process you're using, of doing authentication manually and sending them files, is the most complicated, difficult, and error-prone way that one can secure a site using Let's Encrypt. But not all hosting providers have figured that out yet, for some reason.
In any event, without more detail than "the cert is invalid", I don't think that there's much that people can do. In what way is it invalid? Does it use an ECDSA key and their system is so ancient and backwards that they only know how to handle RSA keys? Is it from an older run somehow and is actually an expired certificate? Do they just not know how to install this particular intermediate chain into their system? A lot of possibilities, and if they don't know what's wrong then we can only guess.
Then...
You are using the system that needs the cert to get the new cert.
What part does Site5 play in this?
I mean: All they really need to do is reload/restart the web server [for you, if you can't].
The new cert should be reached via the exact same path.
And there may be no need to do this manually [automated is the preferable method].
I'd place my bet on it being this one, since looking at the CT Logs, the prior certificates for translite.com.br were RSA, and your newer ones are ECDSA. So you may need to add --key-type RSA to your certbot command to get a certificate that they know how to deal with. But changing to a more competent hosting company might be easier.
huh?
My best guess is that they use system #1 via A record to obtain a cert [HTTP-01 auth].
Then send that cert to Site5 for some other purpose [like MX record use] on system #2.
Otherwise, they are on the same system and have root access to it.
In hindsight/review, none of that makes much sense either - it must be one system only.
Here are some other ideas of why it might be invalid. But, we really need more details from your hosting provider about the reason
Maybe they need all the domain names in the same cert like you have been providing them in the past (see below).
Maybe they check the cert against the public CT logs at crt.sh. Which is currently way behind and is not showing your recent cert. The info below comes from a different CT log system
I can install Certbot on my system and try to get a certificate for one of your domains using the manual plugin. If I then tell you to put some challenges in the correct location, I'll get a certificate for your domain. That wouldn't be much different than installing Certbot on a totally unrelated computer (e.g. at home) and then put the challenge files on the correct server using e.g. a cPanel file management system or perhaps using FTP.
@Osiris, I suppose you are correct about that being possible.
But why do it that way? When they have enough rights to add and remove software.
Unless... that part happened outside the server - hmm...
Lots of pieces too vague/missing to this puzzle.
