So, in this log, what you see is Certbot trying to perform a challenge called tls-sni-01. In this challenge Let's Encrypt talks to the HTTPS server with the name you want a certificate for, and it asks for a nonsensical virtual host name ending in ".invalid" using a feature called SNI (which is host virtual hosting works for TLS).
It does this because an ordinary web server won't have such a host, and, as happened here for you, it'll just send back a certificate for a host it does have, failing the challenge.
Probably this challenge worked for you when you originally obtained the certificate because you did not have HTTPS enabled at all (probably you planned to switch it on once you'd got a certificate). So that time Certbot was able to take the roll of web server, it answered the HTTPS connection from Let's Encrypt and handed over acceptable proof.
But now your real web server is running with HTTPS, and it has no idea about any of these shenanigans, so that can't work as before.
You have a few ways forward, I will list only the two most likely to be appropriate:
Look at switching to the http-01 challenge, aka "webroot" in which Let's Encrypt essentially looks for a file on your web server with a special name, placed there by Certbot. This is suitable if you have a "normal" web server where it's possible to put files somewhere (often named the "webroot") and they're presented by the web server software.
Temporarily stop the real HTTPS server every time you perform renewal, this might be OK for small personal or hobby sites where it's OK for the site to be down for a few minutes every month, it's obviously not OK for a business or anything that's supposed to be accessible all the time.
Finally: Note that "dry run" means not for real, it comes from the idea of a practice fire drill in which everything is done except they don't fill the hoses with water and drench everything, it's dry. A dry run is useful to check how things work but will not actually renew your certificates.