If you are logged in as root then you won't need sudo.
Something else is wrong.
Can you copy&paste actually command and error?

Ah, my mistake. The user is www-data... so perhaps the full sequence should be:

# addgroup ssl-cert
# chgrp ssl-cert /etc/letsencrypt/{live,archive}
# adduser www-data ssl-cert

And then you may verify access by getting no complaints from:

# runuser -u www-data cat /etc/letsencrypt/live/realupnow.com/fullchain.pem > /dev/null

Yes, if it comforts you. I wouldn't .
And yes, you need to change the nginx configuration accordingly.

(I would rather keep in mind that I've choosen my own root and adapt instructions where needed)

Great. The ssl configuration can be merged with the plain http configration into a single "server {...}" block. That would bring the advantage of certainly sharing the "location {..}" blocks which are where you declare service the points.

But if you, as is customary nowawdays, primarily want to only provide https service, and hev the http service merely redirect to corresponding https service, then you would certainly have separate "server {..}" blocks.

You seem to still want the local names in the DNS setup to include the base domain name, and you have now defined resolution for www.realupnow.com.realupnow.com

The record should only have www and not www.realupnow.com

The local name will get realupnow.com appended automagically.

No. apparently certbot includes some bogus advice that might be useful for some apache2 setups but certainly not relevant for you. It's just that the certbot developers have had their "we must do it all" hats on and try to make the tool do much more than just preparing the certificate.

With "certonly --webroot" option you avoid that but obviously the program will still insist with bogus (though technically harmless) instructions.

Nope. It only declares the resolution for the domain itself, without local host.

If their web gui allows, you could declare a resolution for "*" to mean "any local domain" and that would include "ralph" as well as "www" as well as "thisisagoodplacetobe" etc. Usually though "*" does not include local domain names with "." in (which is fine here I guess).

You reported the setting

A Record 	realupnow.com    66.172.90.106   Automatic

That setting is for a host with local name  realupnow.com within your domain realupnow.com and it therefore defines the FQDN realupnow.com.realupnow.com.

Maybe you get confused by the fact that the local name looks the same as the domain name?

Great.

Your dns setup defines 2 FQDN, namely realupnow.com (by the @ line), and realupnow.com.realupnow.com (by the other line).

As I understand it, you want to provide several services:
     1. http://realupnow.com
     2. http://www.realupnow.com
     3. https://realupnow.com
     4. https://www.realupnow.com
but don't really care for http://realupnow.com.realupnow.com, which is serviced now.

That means firstly that your DNS setup must define the resolution for www.realupnow.com
(and rather not for realupnow.com.realupnow.com)

Secondly nginx needs to accept two alternative server names, and it also should use both plain http on port 80 and http over ssl on port 443.

For the latter, you need to locate where certbot has put the ssl credentials (as I mentioned before) and add that to the nginx configuration. (I think www.techrepublic.com has a good article for that).
(Also, keep in mind that by convention, nginx runs as user www-data)

I think it's better to change the "-w" argument to /var/www/realupnow.com since your nginx is already set up to serve from that root path.

Yes the DNS is all fine.

Now there seems to be some firewall to penetrate;  you'll need to allow incoming TCP connections for ports 80 (http) and 443 (https).

It might also be good if it responds to ICMP requests (aka ping).

Looks better. Though that IP address is a s.c. private address that is not usable across the Internet. I.e., only hosts on your network can use that IP address.

It will not be something that Let's Encrypt's server can use.