It doesn't matter too much; some editors provide indentation and "block" support for files ending in .conf which could be an argument for renaming, but the name is not important; only that the link has to point to the actual file.

The pathnames used in sites-enabled/ have the additional significance that nginx will process them in alphabetical order, and if many, the first ono is taken as "the default service" if it needs that. Since you have only one there is no potential of confusion.

In short: it's up to you but make sure the link is valid.

To follow current sysadmin style, your nginx service configuration should be a main file /etc/nginx/sites-available/realupnow.conf and optionally a side file like /etc/nginx/snippets/ssl.conf, plus the link /etc/nginx/sites-enabled/realupnow.conf pointing to ../sites-available/realupnow.conf.

I don't see a direct need to change the main configuration in /etc/nginx/nginx.conf or /etc/nginx/nginx.conf.d/* but I might be wrong in that.

You will need a certificate that includes both realupnow.com and www.realupnow.com so that's a new certificate; you don't want to keep the existing.

You still need to update your nginx configuration both so that it also services www.realupnow.com, and that it offers https access as well (to both domain names).

You may do the first by adding www.realupnow.com to the server_name directive (space separated).

The second, adding ssl, has a number of bits to it; perhaps the easiest is to search for that techrepublic howto ("setup ssl for nginx" might find it?) and pick knowledge from it.

Yes, or edit it so it says "www" instead of "realupnow.com" and then it will define the resolution for "www.realupnow.com"

Or possibly a caching issue. Check the authoritative service with

dig realupnow.com @dns1.registrar-servers.com

Yes, the http service is not accessible (from outside).

If you are sure there shouldn't be any blocking, then you could run

# tcpdump -n -i eth0

on the service host to see connection attempts for port 80.

But maybe best to get some sleep too

No, but the "webroot path" needs to coincide with the served "root path".

• certbot will put its file at $webroot/.well-known/acme-challenge/BLAH (i.e. using its $webroot), and

• the "external" host will get it from http://realupnow.com/.well-known/acme-challenge/BLAH

  which nginx will want to find at $root/.well-known/acme-challenge/BLAH (i.e., using its $root).

Re firewall, I'm not totally clear about your setup. With the Internet to the left, and your service host to the right, I currently understand it as:

      Internet --- 66.172.90.106 = router ---- 192.168.50.4 = host

If that is the case, you'd make 2 rules:
   1 http blank 192.168.50.4 80 tcp
   2 https blank 192.168.50.4 443 tcp
("blank" means to leave the field blank)

Doing so will open those two ports for connection from the Internet.

If your host ("the static IP") is directly on the Internet then that should do.

It needs to be an IP address that an "external" host can use for accessing your HTTP service.

Assuming you can suffer an amount of ads, you could check your externally visible IP address at https://whatismyipaddress.com/

Yes, it should be just @
that means realupnow.com for that configuration

Did you configure your domain registration to point at namecheap nameserver(s)?

EDIT: also check on their "Domain" tab that the domain is active.

EDIT 2: the "nameservers" slot should be fine with "Namecheap BasicDNS".

EDIT 3: The A record entry should be for host "@" to indicate the basic domain name (realupnow.com), with other host names like "www" and "mail" for "www.realupnow.com" and "mail.realupnow.com".

Installing "daedalus preview" without network seems to clock in at 860M.

Note that the SSL credentials system is built upon "domain name control"; i.e., that you are the current renter of the proposed domain name, and in control of the DNS resolution for it.

The "http" validation done by Let's Encrypt via certbot involves them, at an external host, looking up the domain name (realupnow.com) so as to access a file via HTTP that certbot has prepared. This is only possible if you have control of the domain resolution to make that name resolve for that external host to your host and then also run an HTTP service for offering that file.