lexicon VS scep

One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)

This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (< 100 LOC) and it worked extremely well.

[1]: https://github.com/dehydrated-io/dehydrated/blob/master/docs...

[2]: https://github.com/AnalogJ/lexicon

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

Then, you can use ddclient, which supports many DNS services (including those providing DynDNS protocol), or you can write a Python script using the dns-lexicon module to manipulate the DNS records over the API.

> You need a PKI which exposes a SCEP endpoint (ejbca or dogtag supports this).

Uhh...

> [...] ejbca [...]

Now you have two problems.

What I mean is, if you’ve been already running EJBCA for whatever reason then this is perhaps reasonable, but if your current setup is at the level of typing `openssl req` into a terminal (whether that’s a good idea or not), this sounds like a lot of additional complexity. (Can’t say anything about dogtag.)

I’ve been waiting forever for somebody to add an ACME backend to the Go SCEP library[1], but it doesn’t look like that happened. In the meantime it makes a fairly competent standalone server at the abovementioned invoke-openssl-by-hand level.

[1] https://github.com/micromdm/scep

The SCEP is working as it has no issue with our Macs and Jamf. Has anyone gotten this https://github.com/micromdm/scep to work with Intune? If so, would be nice to share the exact steps. CA has been added to root and the config to the scep is setup sort of following this https://www.ironwifi.com/help/scep Yet the scep profile fails when it gets pushed out. I just have under assignment status: "Error". The root certificate config profile pushes out successfully.