certificates
certificates copied to clipboard
smallstep
Add local logging (reporting capabilities e.g. daily report)
What would you like to be added
Is it possible to add tooling that will pull out a list of certificates issued by the CA and output to CSV or JSON, ideally signed by the CA. This is not for CT, this is for auditing certificates issued, also certificated rejected would be handy.
Why this is needed
Right now if I need to revoke a certificate I need to shut down smallstep to get a handle on the database, write code to extract certificates issued and then figure out which ones to revoke. This is a huge pain during audits. This is separate from CT, as I don't want this published in CT infrastructure, I just need an easy interface to locally issued certificates for audit and revocation purposes.
Adding conversation from gitter
yeah, and its not even full CT we need, i just need to be able to know what certs were issued so I can revoke them later or if we get audited
so even an option in smallstep to have step ca read the database and give me results
to a CSV and I'll be happy
Max
@dopey
11:46
Yep, that’s also fair. Good data point. Thanks for sharing the use case! Helps us understand whats important and where to focus.
Shane St Savage
@shane-axiom
11:55
so even an option in smallstep to have step ca read the database and give me results to a CSV and I'll be happy
+1, json option would be nice tho
Evil Mog
@Evil_Mog_twitter
12:03
yeah json, csv, some kind of local log I can view when I get audited, if you want to go for bonus points split it into daily or weekly files (configurable) and sign it with the root ca cert (or the intermediate)
that would be a higher priority to me than CT, also a separate rejection log
Max
@dopey
12:06
@Evil_Mog_twitter Do you think you could create an issue for this?
This is separate from CT, as I don't want this published in CT infrastructure
Why are you opposed to using an internal certificate transparency list for this? It feels like the right answer to me since it would also address availability, scalability, and issues with verifiability and log tampering. It would also work across a large PKI that may have multiple CAs.
To be clear, I'm imagining an internal CT infrastructure. You wouldn't be publishing your certificates publicly.
In the meantime, I understand the need for a stopgap solution short-term and possibly for a lighter weight solution longer term. I'm hesitant to start adding stuff like signing though, as it starts to overlap with CT functionality and it seems like, if you want that, just use CT since it more comprehensively addresses the underlying requirements that I think are motivating this desire..?
I'm not sure where this should live. It could go somewhere in step under the step ca command group. But it might be better to just make it a standalone tool, at least while we figure out what the final form will be. @dopey pointed me to a bit of code that he wrote to pull basic stats from the badger DB. It would be pretty easy to build on this for exporting the info we're talking about here.
Realistically this should be available while the CA is online, right now 2 processes can't have access to the DB so I have to take down the CA. Without access to an online Log of whats issued I can't put this into production.
On Wed, Apr 29, 2020 at 5:52 PM Michael Malone [email protected] wrote:
This is separate from CT, as I don't want this published in CT infrastructure
Why are you opposed to using an internal certificate transparency list for this? It feels like the right answer to me since it would also address availability, scalability, and issues with verifiability and log tampering. It would also work across a large PKI that may have multiple CAs.
To be clear, I'm imagining an internal CT infrastructure. You wouldn't be publishing your certificates publicly.
In the meantime, I understand the need for a stopgap solution short-term and possibly for a lighter weight solution longer term. I'm hesitant to start adding stuff like signing though, as it starts to overlap with CT functionality and it seems like, if you want that, just use CT since it more comprehensively addresses the underlying requirements that I think are motivating this desire..?
I'm not sure where this should live. It could go somewhere in step under the step ca command group. But it might be better to just make it a standalone tool, at least while we figure out what the final form will be. @dopey https://github.com/dopey pointed me to a bit of code https://gist.github.com/dopey/89ec20f22c66c1333bf38c9b19b89758 that he wrote to pull basic stats from the badger DB. It would be pretty easy to build on this for exporting the info we're talking about here.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/smallstep/certificates/issues/239#issuecomment-621529308, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZBQUUTABA64VYVFU6MC6LRPC4UHANCNFSM4MTD6Y3Q .
@evilmog oh yea, I forgot about that in my response. It seems like there should be some workaround for that. If badger is append-only with atomic writes one solution could be to copy the database, read from the copy, then remove the copy. Seems clunky, but "use cp" is the recommended "snapshot" approach for some other log-structured merge key-value databases, so it is a pattern.
Depending on how gnarly this database contention issue is I suppose I could imagine the CA growing some limited APIs for audit / introspection. That feels like a rat-hole though. To start we'd need to figure out how to authenticate/authorize that API and we'd need pagination (and even then I'd be concerned that you could pin the CA process by hitting these APIs too hard). Were you thinking it'd be an API, or did you have another idea?
Honestly a rate limited API tied to a provisioner token is just fine, I would call this once a week, maybe once a day at most. I just need to get a list of certs, serial numbers, principals and dates out of the db. I just need some way of accessing its audit log before I put it into production. Give me the option to pull summary data and if I need more details the option to pull those once I positively id a record. I am even ok if I have to login to the CA box to pull it.
On Wed, Apr 29, 2020 at 9:23 PM Michael Malone [email protected] wrote:
@evilmog https://github.com/evilmog oh yea, I forgot about that in my response. It seems like there should be some workaround for that. If badger is append-only with atomic writes one solution could be to copy the database, read from the copy, then remove the copy. Seems clunky, but "use cp" is the recommended "snapshot" approach for some other log-structured merge key-value databases, so it is a pattern.
Depending on how gnarly this database contention issue is I suppose I could imagine the CA growing some limited APIs for audit / introspection. That feels like a rat-hole though. To start we'd need to figure out how to authenticate/authorize that API and we'd need pagination (and even then I'd be concerned that you could pin the CA process by hitting these APIs too hard). Were you thinking it'd be an API, or did you have another idea?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/smallstep/certificates/issues/239#issuecomment-621589778, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZBQUSXFVRVJ5PT5FDFA4TRPDVLTANCNFSM4MTD6Y3Q .
can confirm this is needed as well! would be huge add for enterprise use cases.
Hey, following up as we spent some time discussing this feature earlier today.
We'd be interested in adding an API endpoint that could dump all the certificates for the DB. However, we don't currently have the time to work on this. If someone from the community has the need / time we'd be more than happy to accept a PR. There's a few things to work out (e.g. how to page through the DB, what format to dump the certs in, etc) and we'd be happy to work through those with anyone looking to contribute.
Note: It's on our mid term roadmap to switch to SQL type storage for the DB (as opposed to key -> value) which will make it easier to query the DB w/out special scripts or APIs.
+1 for any way to query the ca for the issued certs. I need a way to revoke a cert from a client (or the ca server) where the file was generated/lives. In other words,
- Login to ca server
- List certs
- Revoke a specific one.
Hey, circling back on this issue - we've released certificate observability (visibility, alerting, monitoring) as part of our hosted product. You can "link" an open source CA to the hosted product and start seeing new certificates in the UI.
Linking a single open source CA is free. Sign up here: https://info.smallstep.com/certificate-manager-early-access-mvp/, and follow the directions to link an existing CA. Encourage anyone looking to get visibility into their step-ca PKI to try this out and give us feedback. cheers!
Note: you'll need to recreate your provisioners using the new step beta ca provisioner subcommand group. Let us know if you're having any issues there and we'll be happy to help. For real time help, come find us on Discord - https://discord.gg/ypu2T7qg9y.
@hanssl we're currently working on CRL/OCSP so expect that to be released soon. It's likely to be a feature of the paid product. However, there will be hooks in open source for those who want to implement it themselves.