and localhost.cert to fullchain.pem
to match the widely used standard used in letsencrypt
aim is to take some of the pain out of creating a cert
other systems (eg jitsi) do this automatically for you, this is just a first step
I would like to work on this issue, seems like a great idea.
Great, thanks a lot, @PakanaProjects !
@kjetilk Thanks for the opportunity to participate! Also. using my real name now instead of 'PakanaProjects', that just looks weird.
I updated the README.MD and EXAMPLES.MD documentation for setting up a self-signed certificate and key. A single-line command will explicitly generate PEM certificates. I also updated the 'config.json-default' file to reflect using 'privkey.pem' and 'fullchain.pem' as naming conventions.
@melvincarvalho I hope this is a useful first step.
Is your intention to propose adding an ACME protocol client or integrating with one of the existing ACME client providers for Let's Encrypt then implementing CertBot?
@steven-tomlinson wonderful, do you have a pull request?
Anything that streamlines the install process I think is a plus. I recall Tim did ask us to use ACME in the longer term.
Perhaps further work for a future PR is :
Moving
../localhost.key -> ./localhost.key
Im unsure why it goes in the parent directory -- perhaps the assumption is that you are already in bin.
Im unsure why it goes in the parent directory -- perhaps the assumption is that you are already in
bin.
The reason is that people don't accidently add those files to Git.
@melvincarvalho this would be my first PR, just wanted to make sure I was solving the correct problem before wasting anyone's time. I will set it up now.
@megoth and @melvincarvalho ... the guidance set forth in the README, is to place the certificate and key one folder up from the source. In order to prevent accidental check-in, as suggested.
@steven-tomlinson excellent work!
this would be my first PR, just wanted to make sure I was doing solving the correct problem
We very much appreciate pull requests, thanks for diving in.
The only thing I'd say is that since you have changed ./config.json-default the Dockerfile references this. So we could either remove that reference or change the Dockerfile too.
@kjetilk could you point me to the current up to date guidelines for contributing a patch to node solid server. I'd be happy to double check everything looks correct.
@melvincarvalho thank you
either remove that reference or change the Dockerfile too
I don't have much experience with Docker but seems like a fairly trivial fix. I am happy take a shot at it and submit a follow-up commit.
There aren't a lot of strict guidelines, tests will check for style. The author's should indicate that they accept that this is released under the MIT license. And we need to decide whether this is a semver major or a minor issue. In the former case, base the branch on release/v5.0.0, in the latter case on develop.
@kjetilk & @melvincarvalho
The author's should indicate that they accept that this is released under the MIT license.
I updated the pull request comment to indicate that the contribution to Solid is released under the MIT License.
Looks good to me, the only diff seems to be that it's one line instead of 2 and that you have an interactive part. However this is just a README so ought not affect any code.
Thanks for taking it on, and even streamlining it!
Happy to go forward as @kjetilk suggests.
Oh, seems we forgot to close this issue after the PR was merged.