https://github.com/kevinmgranger/cert

https://github.com/kevinmgranger/cert

Last synced: 12 days ago
JSON representation

• Host: GitHub
• URL: https://github.com/kevinmgranger/cert
• Owner: KevinMGranger
• Created: 2022-09-19T18:25:21.000Z (over 2 years ago)
• Default Branch: main
• Last Pushed: 2024-06-18T12:25:30.000Z (6 months ago)
• Last Synced: 2024-06-18T19:35:00.476Z (6 months ago)
• Language: Python
• Size: 82 KB
• Stars: 0
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# cert: generate x509 certificates for testing.

Like [`mkcert`](mkcert.dev), but with slightly more options, 

# command hierarchy

- [ ] consider: does it make more sense to think in terms of "intermediate / leaf" rather than "ca / leaf"?

## nested, see below

- key

  - new

  - view

- ca

  - new

  - sign

    (do we use this for any csr? anything special for cross-signing? in the latter case it's a cert rather than a CSR)

- leaf

- vault

- serve

or do we not do subcommands? verb-noun form? leaning towards that more. Sometimes arguments rather than options make sense.

_plugins / domains_ like vault make more sense as a sub-subcommand.

## flat, verb-noun

- new-key

- view-key

- CAs go here, but...

- TODO: do we work in terms of CSRs instead? with piping?

- let's see if we can make the workflow as similar to vault as possible

- sign-cert

- TODO: is cross-signing a different thing entirely?

- hmm, is the fact that you can "sign" a cert builder already a shortcut, instead of a CSR being created?

- test-trust

- import

# vault support

- do we make this limited? we don't set up anything for you, just let you integrate?

- or the opposite, let it do a full "we'll set up a dev CA for you"

- OOOOOH, we implement actions as reified-- if we do requests ourselves instead of using HVAC,

  then we can also dump it in terms of vault cli commands-- it's a relatively easy conversion!