Command line tool

[tbro]

I've seen some talk about the possibility of bringing a command-line-tool to rcgen. minica is an example of this kind of tool for Golang. I recently wrote myca to address my own needs. It uses rcgen library. My hope with this issue is to spark a discussion about bringing a CLI to rcgen. The first question might be to ask if rcgen wants such a thing? If it does, then we can discuss what it should look like. I think it would be relatively easy to provide a tool to create throw away keys and certificates for use in development and testing. And that is what I have tried to solve for myself. Once that bridge has been crossed, it shouldn't be much more effort to provide a few options and switches for compliance in more restricted contexts. I might be oversimplifying and I'm sure there are other opinions. Discussion is welcome.

[djc]

rcgen already includes a CLI; check src/main.rs. So the question is, how can we better document that a CLI exists, and how can we evolve the CLI to support your use cases?

[tbro]

Oh yes sorry for my poor phrasing. As for evolving the existing CLI, I imagine such a tool could accept some parameters to set common parameters. The first thing that comes to mind are setting the DnsName and signing/encryption algorithm. It would probably be useful to allow the user to provide an output directory as well.

[cpu]

The first question might be to ask if rcgen wants such a thing?

I'm interested! :-) Thanks for opening the issue.

I think it would probably make sense to offer in a crate separate from the main library, but in the same project workspace/repo. There might be cause for taking quality of life dependencies for the tool that wouldn't be appropriate for the library (and it would help keep us honest w.r.t using only the public API of the library) (Edit: though I suppose the main.rs already can't access pub(crate) items, so nevermind me).

rcgen already includes a CLI; check src/main.rs. So the question is, how can we better document that a CLI exists, and how can we evolve the CLI to support your use cases?

The existing tool can only spit out a self-signed certificate with a hard-coded set of names. I think it would be better to frame it as an example as opposed to documenting it as a tool for end users. Its scope of usefulness seems fairly narrow in the current state.

As for evolving the existing CLI, I imagine such a tool could accept some parameters to set common parameters. The first thing that comes to mind are setting the DnsName and signing/encryption algorithm. It would probably be useful to allow the user to provide an output directory as well.

Both of those ideas sound good to me. Looking at minica for inspiration it seems like it would also be helpful to consider IP address subjects as well as domain names.

Given rcgen's new home in the Rustls organization I think we should also aim to make the output immediately usable with Rustls. At a minimum that means creating a CA certificate and a separate end entity certificate issued by the CA certificate. Rustls w/ the webpki verifier won't support the self-signed certificate being generated by the tool today.

[est31]

If you look at the initial commit 82a6157, you'll see that rcgen actually started out as a binary that I moved into a library piece by piece: the target was to make a library though I just used the binary to make the bootstrap process easier. The current main.rs is the leftover of that process. As pointed out by @cpu , it's absolutely not in an advertiseable state as a binary tool to cargo install, more as something you edit, add your domain name, and then you do cargo run in a checkout of the repo. It's easier to do cargo run than to do cargo run --example example-name. I'm open however to move the main.rs to an example instead.

As cargo doesn't support binary-only dependencies (yet), I'm not in favour of adding dependencies that are only used by the binary. As there is plenty of useful binary-only dependencies one might want to use, we should therefore put serious binaries into a separate crate, so I agree with @cpu. As for whether to put it into this repo or a different one, I think for CI purposes it's better to have it in one repo, but willing to hear more opinions on this.

Some more history: years ago, passcod's certainly switched from openssl to rcgen as one of the first outside users of rcgen. I was reluctant to work on a tool at the start because I didn't want to compete with one of the first users (also because it wasn't a priority). Now that the repo is archived I suppose we can just create our own tool :).

[est31]

Rustls w/ the webpki verifier won't support the self-signed certificate being generated by the tool today.

Are you sure? I used rustls with self signed certs before, but that was years ago. However webpki is still okay with it as the testsuite uses self signed certificates heavily. You just need to add it to your "root store".

[djc]

I think a separate crate within the same workspace/repo makes a lot of sense for this. Moving the current main.rs to an example is also a good idea.

[cpu]

@est31 Thanks for adding some history, that's interesting context 👍

I think for CI purposes it's better to have it in one repo, but willing to hear more opinions on this.

Agreed. So it sounds like everyone is on the same page here. @tbro Are you interested in starting on this work?

Are you sure? I used rustls with self signed certs before, but that was years ago. However webpki is still okay with it as the testsuite uses self signed certificates heavily. You just need to add it to your "root store".

I was 95% sure, but to be 100% sure I wrote a quick unit test 😅 rustls/webpki@53da35c

I can't speak to the historic state but I'm certain you can't use a self-signed certificate with webpki in isolation, or Rustls w/ webpki as a verifier (default) today. The test adds the self-signed certificate to the trust store and it still fails with the expected error: Error::CaUsedAsEndEntity (generated in the check_basic_constraints fn of the path building logic).

[tbro]

I am interested! 👋

[tbro]

I currently have some bandwidth so its good timing for me. I can see this evolving quickly but in small steps. It sounds like some first steps would be:

• add [workspaces] to Cargo.toml
• create a new create crate in a new workspace
• add a minimal main.rs and get it to compile
• tinker with CI

I could see just that as a first PR b/c there might be some discussion about naming and CI breakage, or at least some change to get the minimal binary to build in CI. Either in that PR or a second one would add some basic params:

• DnsName/Ip address
• signature algorithm
• output directory

Since the above will involve discussion (choice of dependencies, design choices) that could probably be a PR. After that future PRs would mostly be add features/refining things.

[cpu]

Those steps sound good to me. Maybe also add a step near the beginning that moves the existing src/main.rs to be an example for a self-signed certificate?

[est31]

@cpu there is this test that does work with webpki and a self signed cert. Maybe it's because rcgen's test really just uses the default parameters, so the extensions are what cause the problem. Maybe it's because the webpki test also checks for further things, idk.

[cpu]

Maybe it's because rcgen's test really just uses the default parameters, so the extensions are what cause the problem

Aha, I see the difference. The self-signed certificate in the rcgen test sets CertificateParams.is_ca = IsCa::NoCa (from the defaults). This avoids webpki considering it a CA certificate when using it in the context of an end entity certificate.

I believe this cert should be rejected as a trust anchor, since RFC 5280 says:

If the basic constraints extension is not present in a version 3 certificate, or the extension is present but the cA boolean is not asserted, then the certified public key MUST NOT be used to verify certificate signatures.

However, this isn't enforced by webpki::TrustAnchor::try_from_cert_der when constructing the trust anchor from the certificate to use to verify the end entity signature. It's even called out in its doc string:

Interprets the given DER-encoded certificate as a TrustAnchor. The certificate is not validated. In particular, there is no check that the certificate is self-signed or even that the certificate has the cA basic constraint.

I'm not sure why this function doesn't enforce these invariants. It probably should?

[cpu]

In either case I believe the new tool should emit a CA certificate and a separate end entity certificate.

[tbro]

In either case I believe the new tool should emit a CA certificate and a separate end entity certificate.

I agree. Though it seems reasonable to provide a switch that would override this default behavior and output a single self-signed certificate. But that wouldn't be a priority, to my mind. and could be added sometime in the future.

[cpu]

I'm not sure why this function doesn't enforce these invariants. It probably should?

Pulled out a separate issue for this so we can keep this one focused on the CLI tool: rustls/webpki#200