acme.sh VS lexicon

Huh, the environment variable thing was specifically aimed at acme.sh which rather arbitrarily changed the config value from ACMEDNS_UPDATE_URL to ACMEDNS_BASE_URL, never acknowledged this in a changelog and then silently failed after an automatic upgrade as recommended by the default install:

https://github.com/acmesh-official/acme.sh/commit/2ce145f359...

It's also cleared out my .account.conf files when run on the suggested cron.

I've started using updown which also monitors my TLS certs simply because I no longer trust the process to work as documented.

It depends on your provider though. I can tell from experience that with OVH and their API, it's been easy to set up the automatic renewal via DNS verification. Apparently, the official client has support for the DNS API of 159 providers: https://github.com/acmesh-official/acme.sh/wiki/dnsapi

For the few people here that happen to run a self-hosted email server with acme.sh for TLS key/cert generation and Cloudflare for DNS management, I have made a tool that i personally use to get a perfect 100% score on Internet.nl's email test.

acme.sh is a lightweight Unix shell script for automatic issuance and renewal of free certificates in a Unix environment. It's compatible with Bash, dash, and sh; Docker/IPv6 ready; requires no external dependencies; and can issue, renew, and install certificates without the need for root or sudoer access. Thanks for this recommendation go to blitznogger.

Error troubleshooting: 1.Failed to obtain Github files, please wait for Github to recover and try, the recovery progress can be viewed at [https://www.githubstatus.com/] There is a bug in the 2.acme.sh script, see [https://github.com/acmesh-official/acme.sh] issues

My vps is located in Japan so there shouldn't be any trouble grabbing files from github and such but it obviously timed out every time the script tried to grab acme.sh's repository. Has anyone tried this script lately with success?

you may wish to use certbot instead:

https://github.com/acmesh-official/acme.sh/issues/4659

like https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mo...

If DNS-01 is not an option or to complicated, this saves you from exposing a host to the internet for no good reason.

Caddy where possible, and acme.sh or lego where not.

The SSL certificate for my wildcard domain is currently managed by the acme.sh script running as a Docker container until the issue with NPM and Azure DNS certificate management is resolved.

A reminder that if you an internal-only server where the typical http-01' verification connection method will not work, especially if you cannot easily/dynamically update DNS records, one can use dns-01* by using DNS aliasing/CNAME:

* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

So if you want a cert for www.internal.example.com, you will first have do a one-time change to have a _acme-challenge.www.internal… CNAME created to point to any other (sub-)domain where you can easily update things dynamically, e.g., www-internal.example-dnsapi.com.

When request the cert for "www.internal…", LE/ACME will look up the corresponding _acme-challenge record, and go to "_acme-challenge.www-internal.example-dnsapi.com. The nonce token will be there in the 'final' destination following the CNAME in a TXT, which shows LE/ACME that you control the DNS chain.

To do the DNS updating, you can use a CLI/Python library like Lexicon, which supports dozens of APIs:

* https://github.com/AnalogJ/lexicon

This leverages the ACME DNS server which has a REST API:

* https://github.com/joohoi/acme-dns

If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel:

* https://github.com/AnalogJ/lexicon

* https://pypi.org/project/dns-lexicon/

* https://dns-lexicon.readthedocs.io/en/latest/user_guide.html

> It even comes preconfigured for various DNS providers[2]

Also, CLI utility that supports a bunch of APIs:

* https://github.com/AnalogJ/lexicon

DNS alias mode:

* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

* https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

You want the name "internal.example.com". In your external DNS you create a CNAME from "_acme-challenge.internal.example.com" and point it to (e.g.) "internal.example.net" or "internal.dns-auth.example.com"

When you request the certificate you specify the "dns-01" method. The issuer (e.g., LE) will go to the the external DNS server for the look up, see that it is a CNAME and then follow the CNAME/alias, and do the verification at the final hostname.

So your ACME client has to do a DNS (TXT) record update, which can often be done via various APIs, e.g.:

* https://github.com/AnalogJ/lexicon

You can even run your own DNS server locally (in a DMZ?) if your DNS provider does not have an convenient API. There are servers written for this use case:

* https://github.com/joohoi/acme-dns

* https://github.com/joohoi/acme-dns-certbot-joohoi

* https://github.com/pawitp/acme-dns-server

Not meant to be comprehensive but hopefully a nudge in the right direction, I’ve found the least painful way to deal with the TLS certs is LetsEncrypt verification over DNS. There is a tool called dehydrated that implements the protocol. Then what you need is a domain, and a registrar that supports some kind of API, cause you don’t want to be renewing the certs manually every month. There is a tool called lexicon that provides programmatic access to tons of registrars.

I don't disagree, but in the meantime, a handy CLI utility that can handle a bunch of APIs:

* https://github.com/AnalogJ/lexicon

This way you only have to write one set of boiler plate in case you use multiple providers (or want to change providers).

> If you want to use the www auth you need to allow outbound connections to any IP

Only for the time period when you're requesting the cert though: it does not have to be open to the entire Internet 24/7. While this not satisfy your personal / particular level of security concern, it is something. Using the dehydrated client as an example, the web server could be started and stopped (or the host's firewall rules altered) in the startup_hook() / exit_hook() functions, or the deploy_challenge() / clean_challenge() functions:

* https://github.com/dehydrated-io/dehydrated/blob/master/docs...

> otherwise you have the DNS option which means giving the server access to modify the DNS records which is also unsafe should the box get compromised.

Are you aware of LE/ACME's "DNS alias" mode?

* https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

Let us say you with to get a cert for foo.example.com. Letting an ACME client change the value of that could be a risk as you state. So what you can do is create a CNAME _acme-challenge.foo.example.com, and point that elsewhere, like _acme-challenge.foo.dnsauth.example.com. You then allow the ACME client to alter (just) the TXT records of _acme-challenge.foo.dnsauth.

People have ever written simple DNS server that allow for updating of records via a RESTful API, so you can server just the (e.g.) dnsauth sub-domain from it:

* https://github.com/joohoi/acme-dns

There's also a CLI utility that can handle access the APIs of several dozen DNS companies so you don't have to roll your own:

* https://github.com/AnalogJ/lexicon