Smallstep: End-to-end encryption for distributed applications and the people who manage them. (we’re on Pacific Time)
Hey @SahanaJC there’s a few things going on here, but the main issue is that
step ca revoke is tied to step ca renew. What I mean by that is, if you use a different method to renew the cert then it doesn’t actually go through the same processes. For example, regular ACME client renewal does not work the same way that step ca renew works. In the ACME protocol when you renew a cert you don’t send in the old cert. You just go through the ACME protocol once more with the same information.
Basically,
step ca revoke only works if you plan to use step ca renew for renewals. For other clients it “probably” will not work because other clients do not send in the old certificate as part of the renewal flow.
Does that make sense? Consider renewing certificates using
step ca renew. It has all sorts of useful flags that allow it to run as a daemon, periodically attempt renewal, etc.
That’s only if you are relying on the revocation. If you can get by without the revocation then you can continue to use dehydrated with the knowledge that the revocations will not be respected by your ACME client.
Hey @wid we have a few open issues in opening source tracking that type of feature. Here’s an example: smallstep/certificates#239. The short answer to your question is “no, no one is currently working on this”. If someone from the community would like to pick it up we’d be happy to work with that person or team to point them in the right direction. The longer answer is that this feature will likely be making it into our hosted offering (in the next few months) before we have the time to implement it in open source.
The biggest hurdle in open source is that we store data in a nosql format (key - value), making it difficult to run any sort of query against the data without writing bespoke scripts to enumerate all values in a table, etc. So if someone wanted to take a look towards converting the storage layer to a SQL backend, that would be a good first step.
Hello,
In my GCP account, I have distributed an instance of Smallstep ACME Registration Authority for CAS to test the product. The sensations are very good; the deploy has been very fast and easy. Congratulations on the product. One question, can an ACME smallstep server only issue final certificates from a subCA generated in Google CAS? In other words, is the caCAS value unique? Can't it have several values? I mention this because if an enterprise's PKI infrastructure is generated in Google, it is very likely that it is made up of several SubCA's ( my on-premise PKI is made up of four SubCA's, for example, for compliance needs among others... ) Thank you.
Hi @thidalgosalvador, at the moment one ACME RA only supports one CAS CA, to support multiple ones, multiple instances are required. As we support multiple ACME provisioners it would be possible with code changes to support multiple ones, can you add an issue in https://github.com/smallstep/certificates with your use case?
I think this is essentially the same thing.
Not sure if we need another issue to track it (although this is a more specific use case).
You can play with
step ca token to work out the sort of token you'd want your server to generate.
(then run
step ca certificate using --token to request a certificate from the CA using a token)
There's an example in our docs that includes a bash script that uses the encryption key for the provisioner to generate a custom JWT for the CA. This is basically what you'd want your token server to do, if the user is authorized.
Hey @etudurd we don’t have any docs for that at the moment, but we do have this open issue smallstep/certificates#110 tracking docs for keycloack, and other OIDC providers.
Hey @korhojoa I’m not really sure what you mean by intermediate CA in the context of SSH certificates. SSH certificates don’t have a “chain of trust”. Just a signing key (root key) that signs SSH certificates. So not sure it would make sense to have
step-ca be an intermediate in that sort of setup.
thank you :0
:)
Hey @etudurd I believe that KeyCloak is possible, we just don’t have documentation for it (yet). We have this open ticket — smallstep/certificates#110. If you follow through with the KeyCloak integration we’d love to hear about it. KeyCloak, being an OIDC provisioner, should work similarly to Gsuite, Okta, Azure AD, etc.
https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/ — we're partnering with yubico to give away five build kits for TinyCA run on a raspberry PI with a yubikey. Details in the post!
ill publish it in January, probably with an all internal acme solution, if testing proves successful
BTW, I want to say thank you to the smallstep team for building such a solid system. I don't have any huge deployment or complex configuration, just a little homelab I was tinkering with over the holidays, but smallstep was easy to set up and start distributing certs. Took a bit to fully grok the relationship of how cert requests work and how to maintain everything, but once I did it's a breeze. I ended up wanting to distribute ssh host certs in k8s, so I expanded autocert to support them, and put up a pull request at smallstep/autocert#24
As follow ups to that PR, I'd like to add more testing, and to add support for sending SIGHUP signals to the primary pod process to reload the certs. I'll wait until you have a chance to review that PR first, as both pieces require touching controller.go, and I don't want to keep moving the review goalposts
Hello, I have been trying to get the tiny-ca rpi system up and running but I am having some issues after getting everything installed and configured. I made a post of r/homelab, link here.
I have gotten some issues worked out like the ca not using my internal dns server, but now I am stuck on the following error.
I have gotten some issues worked out like the ca not using my internal dns server, but now I am stuck on the following error.
error validating ACME Challenge at https://tinyca.lan/acme/acme/challenge/Rrk1iKFeEjDRkFu0w025Ogty17RsL2R0: client GET https://tinyca.lan/acme/acme/new-order failed: Post "https://tinyca.lan/acme/acme/challenge/Rrk1iKFeEjDRkFu0w025Ogty17RsL2R0": stream error: stream ID 17; INTERNAL_ERROR
47 replies
any help would be super useful
same with an fqdn
it works but the ssl is not verified
@Tony-The-Developer ^=