That was the "conclusion" of your starting post. Isn't that contradictionary?
But you do want some kind of method by the ACME client (such as certbot) so that the local development server would get the certificate somehow anyway:
Contradictionary again?
In any case, you would like for your "production website" certificate to contain a local subdomain too and somehow copy that certificate to a local development server. That's what I understood anyway.
I think there are many, MANY setups of production servers and local development servers possible and that any client, like certbot, wouldn't be able to implement your suggestion for all those setups. I'm afraid there's no "one size fits all" in this one. And therefore, such setups would need to be custom build.
Luckily, that would be a piece of cake by anyone remotely skilful in the IT department.
But this is just another way to obtain a new Letâs Encrypt certificate. I want the same certificate that is on the production server to be copied to the development server whenever the certificate is renewed.
I donât think Iâm being contradictory. I want the same (identical) certificate on both servers after every renewal. Automatically, as part of Acme. For everybody. So nobody has to roll their own. Secure websites for everyone, including development and testing websites!
So every developer should have the exact same setup of local development and production systems? Or should an ACME client support a few hundered different types of setups? How do you envision such a thing practically?
I don't know why that's so important, though, if they both let you securely access your site. But there's absolutely no way to handle everyone's arbitrary idiosyncratic network design, so there's no way to make such a tool to automatically handle distribution. That's why post-hook exists, and if some kind of firewall issue exists to prevent that, then you can poll in cron from the other side. Just a basic rsync/sftp, and if you need more, thousands of synchronization tools exist.
As I said, I am not offering a design. I am suggesting that development servers be included in Letâs Encrypt. I am not envisioning everyone having the same setup. Letâs Encrypt currently works with a variety of hosting and website systems, so I imagine that storing the security files locally in a pathname specified by the developer would not be complicated, as you seem to fear. How impractical do you imagine it is it to store two files?
I donât understand the need for synchronization. What needs to be synchronized? And what does network design have to do with storing two files locally? As for your post-hook/firewall/cron complications, donât want them and donât need them. Certbot just works (to create and renew certificates), and copying two files can just work too. I just want Letâs Encrypt to include local development servers in Acme (or Certbot alone) as it currently uses Acme to create and renew certificates.
If the Subscriber Certificate will contain an extendedKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
A local development server is equivalent to a private PKI. You don't need anyone else to do that for you, there are thousands of those, as well, and some of them are even built into your favorite OS of choice.
I feel more confused every time I read a reply, instead of more clear.
Prohibiting subscriber key pair generation doesnât seem the same as forbidding copying a private key and certificate from remote computer to local. And, in fact, this is exactly what we do to securely connect by FTP or puTTY! If you use either of these common programs, you probably have copied these internal secret keys to your personal computer!
I donât know if it is easy to script or not. I am simply suggesting that when Acme creates or renews a certificate, it have the option to store two files. The reason is to encourage everyone to use HTTPS, which is the mission of Letâs Encrypt.
The problem is that any sort of a potential --downstream-clients option requires a client-and-server relationship, which enormously complicates everything. Certbot is a client, asking it to act as a server is way out of scope, whichever side it lives on. You already HAVE a server, which can serve the certificate to your downstream clients. Thatâs all you need.
This isnât an ERP system. Itâs just a simple tool.
Are you actually saying that there is a way to get a production server to serve its own secret key and certificate to the development server? How would that be done, and can it be made part of Certbot?
Exactly. I am asking Let's Encrypt to make them part of their mission.
I will discuss at Certbot, as you suggest. But they could complain that it is not part of the Let's Encrypt mission, which is why I had to post here first.
as thought about it, as le keep reusing successful challenge for a month, so it you copy LE client setup and delay renew about a day wouldnât it get new cert from LE as production server already made the challenge and dev server use same acme account?
If nothing's looked appealing so far, then how about SSHFS? Just mount your production server's entire certificate folder over SSH, so it updates instantly. There's just so many ways a server can serve files.
A general concept of "certbot should do this" doesn't do much. Experimentally-found pros and cons of actual implementations brought forward are what's going to be interesting. When it comes to hard to design things, a fully-specified idea with a reference implementation is always taken more seriously.
Why?
Certs are certs.
Any valid (similar) cert should do.
Even one with the exact same name can be had by up to 5 unique systems.
Then how would you get the exact same cert installed in two places?
It already allows for hundreds (possibly thousands) of certs to be issued under the same domain.
How much "more" is required?
That sounds like it should just make two independent requests:
"domain.normal"
&
"dev-test-local.domain.normal"
As long as both names resolve to the same global DNS IP, that can be done today.
Two certs in your production system - yes today.
[right now if you like]
But how will YOU get the second "local" cert to the "local" dev system?
You want certbot to do that for you?
You want the ACME protocol to cover this type of "hand-off"?