Open Ludea opened 1 year ago
That is a pretty cool idea, I didnt know mkcert. I am open to adding it, however I do want to be sure it makes sens within the scope of the project. Could you explain why its useful to have both certificate renewal/requests and local cert generation in the same CLI app?
Further more to me it seems a bit to dangerous to have system trusted CA private key lying about. How would you feel about storing only the public root ca cert? We would not store the root ca key therefore it can not be reused. That would mean adding another root ca certificate to the system for every local cert. But it is significantly safer.
It should be easy to figure something out that prevents the systems root ca store from getting filled with useless root ca's.
That is a pretty cool idea, I didnt know mkcert. I am open to adding it, however I do want to be sure it makes sens within the scope of the project. Could you explain why its useful to have both certificate renewal/requests and local cert generation in the same CLI app?
You're right, I thnk it's out of scope of this project. https://github.com/est31/rcgen does the job
Further more to me it seems a bit to dangerous to have system trusted CA private key lying about. How would you feel about storing only the public root ca cert? We would not store the root ca key therefore it can not be reused. That would mean adding another root ca certificate to the system for every local cert. But it is significantly safer.
It should be easy to figure something out that prevents the systems root ca store from getting filled with useless root ca's.
I don't know nothing about certificats creation / root CA, I just follow some examples code
You're right, I thnk it's out of scope of this project. https://github.com/est31/rcgen does the job
I gave it some more thought and it might actually fit. Since my goal is to make certificate renewal as easy and friendly as possible why not add a development mode. The same safeguards that I currently have to prevent accidentally replacing production certificates with staging ones would apply to "fake/self signed" certificates.
Maybe it would work as a subcommand fake
:
so renewc fake --domain example.org --path ~/Documents/my_awesome_app
And then when you are done you could use the same command to get a real certificate just swapping out fake
with run
.
So I think you where quite right to suggest the feature, however right now I do not have the time for it. Im gonna figure out a label and leave it open.
You're right, I thnk it's out of scope of this project. https://github.com/est31/rcgen does the job
I gave it some more thought and it might actually fit. Since my goal is to make certificate renewal as easy and friendly as possible why not add a development mode. The same safeguards that I currently have to prevent accidentally replacing production certificates with staging ones would apply to "fake/self signed" certificates.
Maybe it would work as a subcommand fake
:
so renewc fake --domain example.org --path ~/Documents/my_awesome_app
And then when you are done you could use the same command to get a real certificate just swapping out fake
with run
.
So I think you where quite right to suggest the feature, however right now I do not have the time for it. Im gonna figure out a label and leave it open.
perfect, thanks ! Do you plan to add this feature as public ? to embed it into another crate ?
Do you plan to add this feature as public ? to embed it into another crate ?
NVM I just see https://github.com/dvdsk/renewc/blob/main/main/src/lib.rs
Oh the lib.rs is just there to allow easy testing. (It allows me to mock stdout and an ACME implementation). If/When I add it it will not be exposed publicly. This project is purely a command line interface app for scheduling/easy certificate renewal.
No plan to use it as lib ? :(
I do not really see a use case to be honest. Certificate renewal, even if "faked" with a self signed one is difficult to get right. The goal of this project is to build a CLI that can run anywhere that makes it hard to go wrong.
I estimate that only about 5, maybe 10% of the code is actually requesting/renewing a certificate. That part is quite simple given all the great libs we build on. Most of the code is there to help the user out when things go wrong, as they always do.
You could take out that 5 to 10%, but it would form a tiny library on its own. Not really worth doing and maintaining if you ask me. However if you see a use case feel free to go do that!
All the code is GPLv3 licensed. That means you are free to take any part as long as your work is also GPLv3 licensed and you attribute where you got the parts from. It will probably be easier to build things up from scratch. You can find the needed parts in Cargo.toml
.
It would be awesome if you could support local cert, like https://github.com/FiloSottile/mkcert