Ok but how would you solve that?
the right ways: you should embed a acme client into program and their own certificate subdomain. (and request rate limit increase for that base domain., but it's 50/week new server is enough you may able to run away without it because renewal isn't included in this ratelmit iirc)
but you didn't said anything about your domain so who would know your domain and revoke it? it will buy time until someone decomplie your java program and found embedded key.
but it looks like you may want to verify the server is actually client's - do you have auth to verify it's really same client's server one requests?
Well if that is the case.
At 50 per week without considering renews from old ones, my initial concerns would be rather theoretical.
I think that's ok.
But I have to ask again now so that I don't go the wrong way ..
I would install CertBot on the CustomerServer and carry out the necessary renew via CronJob. So exactly the same system as I am already using and testing.
I could start up 50 servers / week and the renews of the old ones wouldn't touch this limit.
Did I understand that correctly.
Um.. I do about the same thing. I just use rsync to copy the
LE files from one machine to another, and a cronjob to restart whatever daemons need restarting on the second server. Just about a half-dozen lines of script ... . As it happens, if A gets the certs, then a cronjob on B fires off both the transfer from A to B, and the reloads on B. That way if B happens to be down, nothing happens to A. Haven't touched it in years.
if your client is java program this java client GitHub - shred/acme4j: Java client for ACME (Let's Encrypt) may be easier to include. but didn't run it myself so I don't know how it works.
@joob Please ignore my comments at the start of this thread.
Back then I thought you were doing some sort of hosting service on servers you managed.
I now understand that (from your post #18):
- You have a java app that runs on your customer client machines.
- You have some sort of service or app on the customer server.
- You plan to manage CA certs on the customer server for secure connections between your apps on their premises
- For all (1000) customers, you want the certs to be subdomains of the same apex domain.
Have you considered using a self-signed cert on the customer server instead?
That provides encryption between your client and server.
You could build a way to confirm your java client is talking to your authentic server
It is just a thought experiment. Distributed application design is a complex undertaking.
that's an interesting idea.
I have to make a decision then.
- Cerbot on every customer server
- Restriction: 50 new servers per week (that's no problem)
- no dependencies
- Cerbot only on the header server
- no restrictions through limits
- possible dependencies and problems with the distribution
- Your suggestion
- I have to think about what has to be taken into account
Can you sum it up like that?
Thank you very much for this thought, something like that easily gets lost in all the considerations.
Generally speaking, a popular way to solve problems like this is to centrally manage the certificates and then push or pull them to the servers.
For example, you might have a local machine handle all the challenges via DNS-01, then a script will upload them onto each server and reload the web server; or the servers might load the new cert daily from a local server. Some people even use a network mounted volume on each server to host the certificates, so there is one write and 1000 reads.
You can also centrally manage HTTP-01 authentication by using redirects or proxying all requests to
/.well-known/acme-challenge on your system into a single server.
I wrote/maintain a system for scalable (domains or nodes) ACME deployments. It is a centralized certificate manager that creates a local API for your servers to request/deploy certificates through, either through a programmatic API or a custom openresty/nginx module : GitHub - aptise/peter_sslers: or how i stopped worrying and learned to love the ssl certificate
OR use any free domain (already included in the PSL) without such a limit.
[like as a 2FA beyond just user/pw interaction]
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.