I want to get properly maintained certificates on a set of phones.
The ACME HTTP challenge mechanism appears to support communication on the HTTP standard port 80 only. I can set up a web server on my phone, but not on port 80.
Are there ways to get this to work ?
DNS authentication may be more effective in your case.
Provided that your DSP allows for DNS updates via API.
[Or you can delegate the DNS requests to a DNS server that does support updates via API]
Quick question: what's the function of the Let's Encrypt certificates on those phones?
I want them for mutual authentication.
I'm afraid I don't understand. To satisfy my curiousity, could you please explain further?
I am building a home alarm system on esp32 devices, already have ACME running on those. Now I want the same thing on our phones for secure remote communication without silly stuff like passwords which everyone says is outdated.
Ah, OK, just a fancy name for the old-skool "client authentication". I'm not sure if Let's Encrypt is the right choice for client authentication certificates. They can be used for that purpose, but Let's Encrypt certificates can only contain hostnames.
So how would you envision a client certificate based purely on a hostname?
Personally, I have my own private CA set up where I have a root certificate and I can sign my own private user certificates.
I will admit I did not read though the project thoroughly, but I did find it... strange that it uses a separate client cert from the server cert on the same system.
If that (separation) is a requirement, then the LE cert may be a problem; as it has both in the single cert.
Good responses so far, I'd just like to suggest smallstep as a way for you to manage your mTLS PKI.
Whether it's running commands manually (https://smallstep.com/docs/cli/certificate/create/) or running your own ACME server on your own choice of HTTP port (https://smallstep.com/blog/private-acme-server/), I found it quite helpful for setting up mutual TLS at work.
The example seems strange because it's a simplified context.
The general idea is that it is mutual ssl authentication - each side of the conversation verifies the other. The client wants to know it is talking to a specific server, the server wants to know it is talking to a specific client. LetsEncrypt certificates are typically used in a way that theyonly authenticate the "server".
All certs have both or only one, it's just the context of how they are being used.
LetsEncrypt is the wrong tool to use for this though. The Server could use a LE certificate, but the phones should use a self-signed cert that is good for 20+ years -- otherwise they need to install certificates every 2-3 months on the mobile devices.
IMHO, the usage case the OP wants would be better handled with the client using ssh key based authorization and the server using LetsEncrypt.
Thanks to all for contributing.
Which knowledge about the clients should I then put in the server ?
Each client gets their own SSH Key (or Self-Signed Certificate). That information is then enrolled on the server, and used to prove the client's identity to the server.
The Server can then use a LetsEncrypt certificate, which auto-updates every 2-3 months, to prove the server's identity to clients.
You could use the LetsEncrypt certs on the clients... but then you have to manually provision and reinstall them every 2-3 months. It will get old fast.
I guess the next question (after WHAT) is HOW?
I can't say that I have done this myself, but a simple web search for "using ssh keys for authentication" returned lots...