Can a TCP port be open without any “service” running behind, like a web server?
I am trying to get a certificate from Let’s encrypt, using acme.sh client (standalone option). on a given host behind my net.
Set up a NAT rule, yet when trying to verify if port 80 is open, say by port checker as this. https://www.yougetsignal.com/tools/open-ports
but it displays info - port 80 is closed. Verifcation run on a public IP.
Yet, when I start Mikrotik www service than suddenly the checker says “open”, but for the verification it must be that acme.sh web server is internally started, started by acme.sh run with proper option. The standalone option means that the acme.sh will start the web server,
The doc https://github.com/acmesh-official/acme.sh says
Port 80 (TCP) MUST be free to listen on, otherwise you will be prompted to free it and try again.
But this is somehow I cannot see with a given port checker, even after I set up a NAT rule.
Hope somebody will explain to clear up the confusion.
ACME working over HTTP needs HTTP server running and delivering (right) response to request from letsencrypt server. This can either be done using already running web server (and asme script simply stores response to correct place in web server’s file structure) or acme script can temporarily run its own web service (limited in functionality) during certificate renewal procedure. Possibilities are actually limitless, but one has to know what he’s doing (at least basic knowledge is required).
You can actually also easily use --standalone for the first issuance of a LetsEncrypt certificate.
I have been doing this lately as you therefore do NOT have to create a virtual server entry for the HTTP “version” of a new site (which would never get used in an SSL-everything paradigm!). You can immediately write your Nginx (or Apache) configs to use the issued SLL cert and don’t have to remove the http (port 80) cruft!
The only thing to consider is that renewals will then ALSO use --standalone (which means you would need to use a --pre and --post argument to shutdown the webserver temporarily while pulling the renewed cert).
My “workaround” for that issue (as I don’t generally want to shut down the webserver) is to edit the certbot renewal scripts to use --webroot mode instead of --standalone. Pay close attention to editing these scripts, however – you could bork your renewals if not careful. It makes sense to test (with
certbot renew --dry-run
) after editing the renewal scripts!
I have found this LetsEncrypt workflow to be highly efficient and easy to grasp.