Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for CSR in the dump function #203

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

prateeknischal
Copy link

Add support for CSR when using the dump command by implementing a flag --csr that would look for CSR(s) in the file and then parse it. Usage could be like:

$ certigo dump --csr <file.csr>

It supports the --depth, --json and --verbose flags.

Add tests for the same.

Added another flag --depth to connect and dump to limit the number
of certificates to be printed in --json or --pem flags to make is
easier to ignore if only the leaft certificate is required.

Old vs New Commands:
* dump just the leaf cert
old : certigo dump cert_chain.pem --json | jq '.certificates[0]'
new : certigo dump cert_chain.pem --json --depth 1 | jq
Similar with other flags eg --verbose or short
description

* connect to get just the leaf cert
old : certigo connect hostname --json | jq '.certificates[0]'
new : certigo connect hostname --json --depth 1 | jq

old : certigo connect hostname --json --start-tls ldap | jq
'.certificates[0]'
new : certigo connect hostname --json --start-tls ldap --depth 1 | jq

This option is not implemented in verify and can be added if there is a
good response to this commit.
lib/encoder.go Outdated Show resolved Hide resolved
Add support for parsing a CSR in the --dump flag using a --csr flag.
This flag would only read the Certificate Signing Requests in the file.
@alokmenghrajani
Copy link
Contributor

Do we need a --csr flag? The tool is simpler to use if it just figures out what the file is and dumps the contents. We can put a message saying "here is the content of your CSR" vs "here is the content of your cert" if we are worried about anyone getting confused.

@prateeknischal
Copy link
Author

prateeknischal commented Jan 26, 2020

@alokmenghrajani that's a good point. The direction from where I am coming is, this tools only scans for x509 certificates right now. If we let the PEM parser decide what is the type of the block, then it might have to be designed in such a way. The code is written in such a way that it will only accept x509.Certificate objects. I have tried to have as small disruption as possible in the signatures and change signatures where it is sufficiently abstract (for which I may be wrong as well).

If this seems to be a good feature, to let the parser understand the type of the block, then I can work on getting the CSR within the above frame and not have a --csr flag.

I was looking at the code and I can think of using the output of ReadAsPEMFromFiles to determine the type since it has the param pem.Block which has the Type attribute and that can be used to use an appropriate parser.

@prateeknischal prateeknischal requested review from a team, mweissbacher and isemaya-square and removed request for mcpherrinm January 11, 2022 00:47
@CLAassistant
Copy link

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants