Hi Schoen
Thanks very much for your help.
(1)
I should have included the letsencrypt reference:
in my original post.
In particular this part:
If you use Certbot in its automatic Nginx or Apache modes, you need to upgrade to version 0.21 in order to issue certificates for new domain names. If you use the certbot or letsencrypt command, you are using packages provided by your operating system vendor, which are often slow to update. If this is the case, you should probably switch to certbot-auto626, which provides the latest version of Certbot on a variety of operating systems. Also note: If you block port 80 on your web server, upgrading to the latest Certbot will not fix your problem, because it switches to the HTTP-01 validation method, which uses port 80. I recommend opening port 80 and redirecting HTTP traffic to HTTPS.
(2)
I tried and failed to install certbot - probably because the packages were in flux. So I followed the recommendation and installed certbot-auto instead. Following the guidelines for certbot-auto did not include the --nginx flags.
However, thanks to your explanation I now understand that with regular certbot I will be able to specify
--authenticator nginx and it will modify my nginx configuration only temporarily for the challenge timespan only.
I guess I will wait until the ubuntu packages are ready - I'm not in a rush right now.
(3)
I did set up the nginx
location ^~ .well_known { ... }
block inside the https server block, to see if the challenge would work in https.
However it returned an error as follows:
The following errors were reported by the server:
Domain: www.go-oio.com
Type: connection
Detail: Fetching
http://www.go-oio.com/.well-known/acme-challenge/7Oe4qP4r1R5J22VX3l7zGXAVgHHaouZiN9myQF4Jpdw:
Timeout
Although it could be something I did wrong, I'm inclined to think
it was a requirement to use HTTP for the challenge, as the letsencrypt reference seems to say.
(4)
As you say, trying to handle the authentication in HTTP with a "localtion /.well-known {...}" clause
which if that clause fails skips out with a redirect to the HTTPS block is also an option.
I find nginx syntax and semantics somewhat problematic in that it is not always intuitive,
the documentation is not always straightforward, and it is difficult/awkward to debug and test.
I will consider that option if by the end of April, when the current cert expires, the new certbot module is still not stable.
With your helpful dialog I think I now have a good enough grasp to move forward.
Thanks again!