Yes all configuration looks fine, although some ssl settings can probably be tuned. But it should connect and allow access. One thing missing is the ssl_dhparam setting which according to doc is required when/if DH ciphers are used. But I would have thought nginx would issue an error message when started/restarted if that would stop it from opening the ssl listener. Try with stopping nginx, then starting it, and check the error log.

Does that host have any local firewall?

Ok. hmm 203.220.142.95 would be me, yes.

Right. with wget -H http://www.realupnow.com I get that it connects on port 80, responds with redirect (301) to https, and then fails connection on port 443.

That is an indication that the ssl setup is wrong in some way. Perhaps you could show the log again, following your last entry.

Hmm nginx is running but not serving pages...

Where did those "managed by certbot" lines come from? That configuration file of post #89 is a bit different from the one you showed at post #57 and it confuses me... where did "default_server" comd from, and where did that ssl setup come from? And why is it "root /var/www" ? Is that really the right file? Did you (also:)) get tired yesterday?

The nginx log files are still in /var/log/nginx where it has error.log and access.log

mmm no the ssl-params.conf needs to be included outside of the location block... But it also seems you have at some time let certbot mess with the configuration and it has then given you a mix of stuff you may and may not want.

It's ok to use /etc/letsencrypt/options-ssl-nginx.conf instead of the currently non-existing /etc/nginx/snippets/ssl-params.conf although you of course will need to review that instead.

Just make sure to remove the "# managed by certbot" comment on that include line.

And in the future, do not ever, never, never run certbot with --nginx argument again as it will then want to mess with the configuration again. certbot might also have dropped a cron action (/etc/cron.d/certbot) to "do helpful things" that you may and might not want. That's another thing to review and clean up. (sometimes I wish that those "we must do it all" hats were much smaller)

Further certbot added stuff at the bottom of that service block, which amounts to enforcing a redirect response when the incoming request is not https. That's an ok function, but again I think you should remove the "# managed by certbot" comment.

So: what's in /etc/letsencrypt/options-ssl-nginx.conf ?

EDIT: I meant that file of course.

Ok; I had forgotten... you need to set up group access to live and archive:

# chmod g+rx /etc/letsencrypt/{live,archive}

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.