You have a domain and a server with a public IP address. Connecting them is not complicated, but the order matters — do it in the wrong sequence and you will spend an afternoon waiting for caches that never needed to expire.
Step 0: find out who controls the zone
Before changing anything, establish which nameservers are actually authoritative for your domain: dig example.com NS +short.
This matters because the registrar you bought the domain from is not necessarily the service answering DNS queries for it. Editing records in the wrong control panel produces no error and no effect, which is a frustrating combination. Whatever the NS records say is where your changes need to go.
Step 1: lower the TTL first
If the domain already points somewhere and you care about downtime, reduce the TTL on the records you are about to change — 300 seconds is a reasonable value.
Do this at least one full old-TTL period in advance. If the current TTL is 24 hours, lowering it today means resolvers will still be honouring the old 24-hour value until tomorrow. This step is what makes the actual switch fast later.
Step 2: point the records at your server
Create an A record for the bare domain pointing at your server's public IPv4 address, and an AAAA record for the IPv6 address if the server has one.
For www, use a CNAME pointing at the bare domain rather than a second A record. That way there is one place to change the address in future.
Keep in mind that a bare domain generally cannot be a CNAME, because a CNAME may not coexist with the other records a zone apex needs. If a service asks you to CNAME your apex, look for their ALIAS or flattening equivalent instead.
Step 3: configure the server to answer for the name
DNS gets the visitor to the right machine. The web server still has to know it should serve your site for that hostname. In nginx that is the server_name directive; in Apache it is ServerName and ServerAlias.
Do this before issuing a certificate. Domain-validated certificate issuance works by proving control of the name, and the HTTP challenge method requires the server to already respond correctly on that hostname over plain HTTP.
Step 4: add HTTPS
Once the name resolves to your server and the server answers for it, issue a certificate. Automated issuance handles renewal for you, which matters because certificates are short-lived by design.
Serve HTTP as a redirect to HTTPS rather than turning it off. The redirect is what fixes the visitors who typed the address without a scheme, and it keeps the HTTP challenge path available for future renewals.
Step 5: verify, then raise the TTL
Check the authoritative answer directly rather than trusting your browser, which caches aggressively and independently of DNS: dig @ns1.yourprovider.com example.com A +short.
Then check the certificate chain and the redirect. Once everything looks right and has been stable for a day, put the TTL back up to an hour or more to reduce query load.
Email is not included
Pointing a domain at a web server changes nothing about email. MX records are separate and independent, and moving your website will not move your mail.
This is worth stating explicitly because the failure mode is silent: the site moves successfully, mail keeps flowing to the old provider, and nobody notices until a mailbox somewhere fills up or is switched off.