Web TLS certificates are not "trust on first use" (like SSH is often used), they are "trust by webpki", which is a kind of "cached trust on first use".
Your browser only accepts certificates signed by one of a few hundred Certificate Authorities (either the list curated by Mozilla, or the one by Microsoft or the one by Apple), which should not issue a certificate for your domain to anyone who is not in control of your domain.
If everything is working as expected, the attacker cannot get a certificate for your site that is signed by a CA the visitor's browser trusts.
To get a certificate for your domain that the visitor's browser trusts, the attacker needs to either:
- get control of the webserver (in which case TLS gives you no protection), or
- be able to read mail sent to one of a few special mailboxes ('admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster'), or
- get control of the authoritative DNS server for the domain, or
- get control of the DNS server for the eTLD, or
- social engineer the registrar or get control of the registrar or
- compromise a trusted CA (or sub-CA), or
- have control of a private CA that is trusted by the browser or the OS on which the browser is running (this is often done in large corporations).
All of those are supposed to be too hard to do.
From that list, compromising the web server is by far the easiest. The one that happens second most often is that IT admins from your company can MitM your connection from your work computer because your work computer often has a private root CA installed that is controlled by company IT. That is considered a feature.
The rules for web certificates are spelled out in the CA/Browser Forum Baseline Requirements. Browsers use the rules for TLS (which are in the RFCs and affect private/corporate certificates too) + the CA/B BRs (which are for publicly trusted certificates).
I wanted to add that if on first visit the visitor get to the site using a http:// link and not an https:// link, and you rely on the site redirecting the browser from http:// to https://, the redirection might be stripped by an attacker. To combat this, you can add your domain to the HSTS preload list. If the site is on the list, browsers won't try to use plain http and will only try to use https, as if they have a valid HSTS header for that site, but even for the first visit. Of course, if your site's TLS breaks, your site will be completely unavailable, like in a pinning suicide, so be sure you have your certificate renewal 100% reliable before you do this.