What's the current recommendation for people for whom port 80 is blocked?

An old thread, How to get a certificate, without using port 80? seems to suggest using " --preferred-challenges tls-sni"

What is the preferred option for those for whom opening port 80 is not available (or who have chosen not to do it), if tls-sni will soon become unavailable?

From https://letsencrypt.org/docs/allow-port-80/ :

You can use DNS-01 challenges or you can use one of the clients that supports TLS-ALPN-01 challenges (on port 443)

As I mentioned in another recent thread: Certbot’s documentation for the DNS-01 challenge is here, but it’s only useful if you happen to use a supported DNS service.

1 Like

Thanks. Assuming DNS-01 isn’t an option, which of the options suggested there would be recommended on an “out of the box” Ubuntu 18.04 system? This post suggests it’s a low priority for certbot; is there an “idiot’s guide” to installing any of the others as there is for certbot? Picking one at random, this may be comprehensive but it does not appear to contain the information required .

You probably picked the most difficult one :stuck_out_tongue: That’s more of a library for people writing their own ACME clients or integrating ACME functionality into their other software. As an end user you’d probably be better off with something like acme.sh or lego.

I’m not aware of any Ubuntu compatible client whose documentation is quite as user-friendly as Certbot’s, but personally I find acme.sh’s README to be quite extensive and clear.

but personally I find acme.sh’s README to be quite extensive and clear.

Thanks - I’ll have a look nearer the time.

1 Like

OK, here’s what I had to do:

Look at the contents of “https://get.acme.sh” to make sure it looks sensible.

As root, run
wget -O - https://get.acme.sh | sh

Comment out the entry automatically added to root’s crontab as it won’t work as is.

/etc/init.d/apache2 stop
acme.sh --alpn --issue -d example.com -w /var/www/html
/etc/init.d/apache2 start

As recommended in the acme.sh docs, create a location to store the new certificate files. I chose:




(which already existed because I’d been using certbot)
so that the files that will be created in this new location are used by apache

Install the newly generated certificate:

acme.sh --install-cert -d example.com \
--cert-file      /etc/letsencrypt/acme.sh/cert.pem  \
--key-file       /etc/letsencrypt/acme.sh/key.pem  \
--fullchain-file /etc/letsencrypt/acme.sh/fullchain.pem \
--reloadcmd     "service apache2 force-reload"

Test that the certificate was indeed updated just now, and note the SHA1 fingerprinter for future reference.

Create a renewal script:

root@myserver:~# cat /usr/local/sbin/renew_acme.sh.sh
/etc/init.d/apache2 stop
"/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" 2>&1 | mail -s "Ubuntuvm34 acme.sh renewal attempt" myuser@example.com
/etc/init.d/apache2 start

And add to root’s crontab

33  16  *   *   * /usr/local/sbin/renew_acme.sh.sh > /dev/null

and check that it runs and a mail is sent saying that it was skipped and when the next renewal time is.

Test that a new certificate can be successfully issued by temporarily adding “–force” to the acme.sh command in the cronned script. After it runs check that the website is accessible, the certificate was issued today and the SHA1 fingerprint is different (because the certificate has been reissued).

Remove “–force” from the script.

All done!

1 Like

Cool, that sounds like it should work.

You might also be interested to know that acme.sh has --pre-hook and --post-hook options similar to Certbot’s, so you could use those to stop and start Apache and the default cron job should then work as well. But hey, no need to mess with it if it’s already working.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.