Once you control BGP you control any IP and can subvert certificate issuance that effectively uses IP to validate certificate issuance requests. For example anything that relies on a file or dns at a specific IP. Once you have done so, you ARE the site, no matter what HSTS says.
We’ve tried to solve this problem a few times with certificate pinning (dangerous) and more recently just giving up and using certificate transparency to try and mitigate the blast radius by hoping the duration can be curtailed. The whole system is incredibly fragile.
As an aside, BGP should move over to TLS (not https, http is a terrible protocol for this) for other reasons (it’s a better option than tcp aom/md5). That this is not already the case should inform people’s opinion of where this stuff is on the security timeline.
You just need to get a publicly trusted CA to mint a certificate for your new site.
This can be done, for example, with let’s encrypt, using several of the various domain verification challenges they support.
There are some protections against this, such as CAA records in DNS, which restrict which CAs can issue certs and depending on the CA which verification methods are allowed. That may not provide adequate protection.
For example if you are using LE and are using verification mechanisms other than DNS then the attacker could trick LE to issuing it a cert.
That also depends on the security of DNS, which can be tricky.
So, yes, BGP hijacks can be used to impersonate other sites, even though they are using HTTPS.
When you configure your domains, Make sure you setup CAA, locked down to your specific CA, and have DNS sec setup, as a minimum bar. Also avoid using DV mechanisms that only rely on control over an IP address, as that can be subverted via BGP.
[1]: https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...
[2]: https://community.letsencrypt.org/t/validating-challenges-fr...
And Multi-perspective only helps against an attacker who is merely able to influence a local route, if they can ensure all your perspectives see the same thing the attacker wins.
Yes this is why multi-perspective is described as a "mitigation" above. Ideally, ACME issuers have a large array of perspectives with additional perspectives added frequently to foil planned attacks. But real BGP security is the actual solution to this problem.
This document is essentially an agreement between the Trust Stores (largely the browser vendors such as Microsoft, Google, Apple, and Mozilla) on behalf of their Relying Parties (everybody) and the Certificate Authorities they choose to trust. It lays out the requirements on what the CAs may do and how they may do it, the numbers I quoted were sub-section numbers for what are sometimes called the "Blessed Methods" which these days are listed in those requirements - for how a CA shall check that say a certificate for news.ycombinator.com can be issued to this web server we're both using.
This isn't a "standard" really, any more than you'd say the Geneva Conventions were standards. It specifies (that "- ACME" is from the document, it's not my addition) that you can use some ACME protocol features to achieve the name confirming requirement but it also specifies some ways to do so manually. Last month quite a few of the older methods were finally stopped for new issuance (though existing confirmations for those methods will keep working for a few years if you have them). Stuff like "Find the landline phone number for the company in a government directory and call them" which I'm not sure really still made sense when the BRs were first agreed, let alone last month when it was finally removed.
Major news outlets, government websites from various countries, the American army, and many more all lack CAA records, for instance. Any CA can generate a valid certificate for those domains and it's up to the people watching the public certificate transparency logs to catch any malicious certificates.