certificates
certificates copied to clipboard
smallstep
Certificate Revocation List
Hello,
I installed and configured a Linux intermediate CA from a Windows Root CA, and working perfectly thanks to your documentation. It is a CentOS 7 version 1708.
When I revoke actively a certificate, I am not able to find the CRL or place where the revoked certificates are listed.
The goal of this is to have the revoked certificates by the Linux intCA in the same CRL as the Windows intCA, to work with only a unified CRL. In fact, in the Linux intCA certificate, I see that the CRL distribution point is the same as the Windows intCA.
Thanks so much.
Hello,
Do you know any way to insert a CRL Distribution Point in the ACME generated certificates? With this would be enough for me.
Thanks!
Hey, apologies for the radio silence. We've been heads down for a little while and have let a few issues get away from us.
Unfortunately CRL and OCSP are, as yet, unimplemented in the CA. Even in so much as just adding the right extension to a newly minted cert. However, CRL and OCSP are on our short to mid term roadmap. We'll circle back to update with timeline once we've had a chance to prioritize the roadmap in a few weeks.
Hello Max, thank you for the response. Please, no apologies, you do a great work for the community and give us a private ACME platform that works like a charm. If you need some guidances to install and configure the platform on CentOS 7 for users, ask me :) Great news for a mid term, I will stay tuned to this possible feature.
Funny you should mention that. We definitely want to build rpms for centos7/8 along with the existing release packages. No one on the team uses centos so we just haven't gotten around to it. If you have any recommendations / examples that would definitely help a lot.
Hello Max, the step-ca can be installed with the dpkg software installed in CentOS, and works fine. The step-cli, used to initialize the PKI, need to be downloaded as tar.gz and executed every time as a bash in the folder where is uncompressed. Once initialize, following your steps, I be able to change the self-signed certiticates by my RootCA cert and create a specific SubCA for this PKI. As ACME client, I use certbot in Linux and win-acme in Windows, working fine in both cases. If I could provide you with more technical information, tell me.
I see this PR is closed, is this still expected to make it on the roadmap? Trying to find where I can follow this issue to see when it gets implemented, this would be a MUST have feature for enterprise adoption.
@mkkeffeler - CRL & OCSB are still on the roadmap. It's helpful to understand the use case you are targeting as implementations can stray from standards. Can you (or anyone else reading this issue) share your target use case? Offline is fine as well, I'm at [email protected]. thx
At present I don't see another issue that more succinctly requests CRL. I'm gonna go ahead and reopen this for the time being so there's a public place for folks to express interest & give feedback.
@mkkeffeler, CRL and OCSP (CRL reporting, CRL management, CRL serving, OCSP reporting, OCSP responder, OCSP stapling) are all gonna happen eventually. That's all on our internal backlog. To reiterate what @mikemaxey said, specific use cases are helpful.
We're big fans of short-lived certificates and passive revocation (see https://smallstep.com/blog/passive-revocation/). We're more inclined towards improving support there versus adding CRL and OCSP. If there's a way we can make that pattern work for your use case, we'd love to hear about that.
But we recognize that, for a variety of reasons, CRL and OCSP are requirements for some folks. If that's the case for anyone reading this, a +1 helps us prioritize. A short comment (or email) explaining your use case is even better (and we understand that, for some orgs, the reason is that "because organization policy says so" or "because control X.Y of regulation Z says so").
Full disclosure: interest in this project is growing fast and we're spread pretty thin right now, so we're having to ruthlessly prioritize. I'm hesitant to mention this here, since it's sort of mixing religion with politics, but one thing that would accelerate this work is a customer who is actually demanding this feature. So far we've been able to talk customers out of this requirement when it's come up, so we haven't been "forced" to do it ;). That's not a hard requirement -- we do lots of stuff because it's the right thing to do -- but this particular feature is just slightly off of our utopian vision for the way we think PKI should work so it's a little harder to get excited about doing it without some encouragement. Again, not a requirement, but if anyone really needs this we're happy to discuss.
Aside from all that, there are some technical decisions to be made. One question I have is whether these features belong in step-ca core or if they're actually separate infrastructure that step-ca (and other CAs) can report to and that relying parties can utilize to determine revocation status. Any thoughts there are also welcome.
Our main use case is that we still work with lots of legacy clients and as such getting them to move to ACME is likely not a matter of prioritization but rather just not possible. Because of that we sign certificates for some clients for a longer term, such as 1 year or even 3 years in low risk cases. As such, the ability to passively revoke is irrelevant due to the length, so we need an active revocation strategy. I would also argue that for enterprise situations the ability to revoke all very large number of certificates and have that take effect immediately is a must have to properly secure the enterprise in a disaster event/security breach.
Would be happy to help drive this to completion in any way I can and coordinate/develop this.
Hello, I am happy that the issue is reopen if it will help to accelerate the implantation of a scenario with CRL. I want to send a diagram of my environment to help to understand my need, but I have no way to send you right now.
We are interested in use a short-lived automated certificate, but with a CRL to the quickly revocation of the certificates. We use a unique Root CA for Windows PKI and Linux PKI/ACME server, and a issuing CA in each environment. The important idea is that the certificates issued with ACME can have published the CRL, to allow the users and machines to know if the certificate is revoked. The revocation itself is relevant, but we can revoke the certificates by another ways, like openssl.
Hope that understand my explanation, I wil try to post later the complete diagram to help to understand better the case of use.
Thanks so much!
@mkkeffeler that makes sense, with the caveat that ACME isn't your only option. I'm assuming that your legacy clients can't use any sort of automated certificate management, ACME or otherwise? If that's the case, yea, I get the need for CRL and/or OCSP.
@Hardcorian if your diagram is confidential feel free to email me. I'm mike at smallstep's domain.
that is correct @mmalone, we are having to accept the request via a ticketing system and manually sign it today. With this tool we could put ansible around it and automate the provisioning part, all that would be left is our manual review and then after approval the implementation could be automated, but to do that we would like to have a CRL.
How can I help get this implemented? is this a prioritization thing or is there work that I could do in my spare time on this?
Hello,
I attached a little idea of our PKI with ACME v2 integrated, and two cases of use that requiring active revocation to work correctly.
As I said previously, the best option is to have a complete CRL (or OCSP) configuration in the PKI created by step, but a first good approach would be publish the CRL Distribution Point in the certificates with a flag like --crl http://cdp.corporation.es/example.crl when the certificate is created. In this way, if we need to revoke the certificate according to the cases of use, we are able to use openssl (for example) to revoke and add to this CRL.
Let me know if these cases of use are compatible with your roadmap, and if need further information.
Certificates revocation - Cases of use.pdf
@mmalone @dopey Hello! Have you any update/planification about this issue? I need to know for a short-term, and assume the current scenario if we want to implement ACME if the planification is for long-term. Thanks!
Hey, apologies for the delay. We're in the process of roadmapping as we speak. This project has gained some popularity recently. Enough so that deciding where best to allocate our limited time has become complicated (and contentious - we love to politely disagree with one another 🤪). It's a good problem.
As of right now, I can't give an accurate timeline for addressing this issue. Hopefully I'll have a more concrete update in a few weeks.
To give a bit of insight into our decision making process: we discussed both CRL and OCSP this morning. Basically, our opinion on both is ... nuanced. We believe that the right default for "most" use cases is passive revocation with short lifespan certs. Nevertheless, we understand that there are use cases where CRL and OCSP are must-haves. So we're left weighing the importance of those "non-default" use cases against other open issues that may have broader reach.
More input from the community (in the form of 👍 or comments on the issue) helps to make these decisions easier.
Hello, yes, I know your general position regarding the active revocation, but in our current environment is useful to have the CRL implemented. For this reason, have a flag like --CRL is a simpler way to have the option to integrate inside the ACME server without a complete change of your position or code. But I understand the time is short for everybody, even the minimum change in a code requires effort.
Thanks for the feedback, I hope more people helps to take a final decision.
We're also waiting for this support. We have an application which analyses the TLS configuration of our customers services, and we need to be able to generate certificates that contain CRL and OCSP URLs so that we can perform regression testing. We don't necessarily need the ability for step-ca to provide CRL or OCSP data, only the ability to add CRL and OCSP URLs to the certificates that it generates. Being able to set a default for ACME, but also arbitrary URLs when generating certificates via other means would be very useful to us.
Good to know.
@mikehardenize to clarify, it sounds like you just need the right x509 extensions set in the certificate when it's being generated. In this case the crl and ocsp extensions.
If that's the case, then we are starting work on a project that should allow you do this (#300). So, the idea would be that you could configure on the provisioner any extra extensions that needed to be on the end certificate. Let me know if you think that would be enough for your use case.
Hello,
Also in our case, would be useful have a flags to add the rights extensions, like the CRL one. Thanks for the update!
El jue., 25 jun. 2020 19:34, Max [email protected] escribió:
Good to know.
@mikehardenize https://github.com/mikehardenize to clarify, it sounds like you just need the right x509 extensions set in the certificate when it's being generated. In this case the crl and ocsp extensions.
If that's the case, then we are starting work on a project that should allow you do this (#300 https://github.com/smallstep/certificates/issues/300). So, the idea would be that you could configure on the provisioner any extra extensions that needed to be on the end certificate. Let me know if you think that would be enough for your use case.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/smallstep/certificates/issues/206#issuecomment-649720867, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOTTBNRG6TL2ZEOWHD3XLX3RYODD3ANCNFSM4LFJK3TQ .
Great point @Hardcorian. Our plan is to have the templates available on both sides (cli and step-ca). So when you're generating a cert via the command line you could add any extensions by specifying a template (complete with templatized variables).
We're wary of creating flags to add extensions because there are simply too many extensions / attributes in an x509 certificate and we don't want to muddle our commands by adding all those flags.
@mikehardenize to clarify, it sounds like you just need the right x509 extensions set in the certificate when it's being generated. In this case the crl and ocsp extensions.
Yes, that is the case. Ideally step-ca would serve up the CRL and OCSP responses, but I realise that's a bigger job and we have a workaround for that. Our main requirement is getting arbitrary CRL/OCSP URLs added to the certificates.
If that's the case, then we are starting work on a project that should allow you do this (#300). So, the idea would be that you could configure on the provisioner any extra extensions that needed to be on the end certificate. Let me know if you think that would be enough for your use case.
Yes, that would solve our use case, thanks. I'll keep an eye on that issue.
Is there any docs on generating a CRL on your own? or the equivalent OCSP? we are looking at hosting it somewhere else, and if we cant have this will use the cert templates as an alternative. this would be a huge feature, though as we are just building workarounds to having this.
I would just like to share our use case as it might interest some people. We plan on using smallstep for certificates on both our servers and staff machines such that when a staff machine talks to an internal service, they can mutually authenticate each other.
Using passive revocation with short lived certificates is fine for our servers. However it is problematic for staff machines which are turned off every night, weekend, or even weeks for holidays. Thus we would like to have certificates lasting ~6 months for staff machines and generate a CRL file we can push (via devops) to all our services to check potentially revoked staff certificates (which can happen if their machine gets compromised or if they leave the company).
I would be happy to provide a simple PR which adds a command to locally generate a PEM CRL file on the CA, if you are interested? Hopefully you can then use it as a building block to develop CRL further (CA endpoint/ distribution info,...) for those who need it.
@mkkeffeler unfortunately, I don't think we have any documentation on creating a CRL or setting up OCSP anywhere. Maybe someone else in the community can help. If you figure out a solution I'm sure others would appreciate hearing about it (I know I would).
@0xjac thank you for the feedback / use case. We are interested in adding active revocation functionality. At the moment we don't have a spec or architecture in mind. If you were to add a command to locally generate a CRL from the CA that'd be a decent start. I'm assuming you'd just pull the certificates that have been revoked (e.g., using step ca revoke) and add them to CRL? At the point you should be able to host the CRL on something like S3, and you should be able to use the upcoming certificate templates functionality to add the CRL distribution point to your certificates. I'm fine with you submitting a PR for this to unblock people who need this functionality. We may evolve the implementation and interface over time as we flesh out active revocation, but I'm sure lots of people would appreciate something like this added short-term.
@0xjac one other note regarding your use case... problems with cert renewal for "intermittently connected devices" (usually endpoints or IoT devices) come up pretty regularly. We're considering adding support for ACME-STAR renewal (or something ACME-STAR-like) [RFC8739] as an alternative renewal mechanism. The tldr is: instead of waiting for a client to request a certificate renewal, the CA would automatically renew any "active" certificates (i.e., certs that have not been revoked) and make them available at a well-known URL. That way fresh certificates are always available when a device comes back online, so long as devices retain their private key material between reboots. I still think we need active revocation, but would this functionality address your use case? Would you prefer it over longer-lived certificates?
@mmalone Thanks for your reply, Something like ACME-STAR would be indeed very interesting for us. (Tho I understand that this might not happen in the short term, and unfortunately we need a solution soon...)
Regarding the CRL, yes I would use step ca revoke to figure out which certificates are revoked an put them in the CRL. The file would just be generated on the CA. Then yes you can host it yourself on S3, (or as in our case, push it to the relevant services via Ansible) but I would consider there that out of scope of the step ca command.
@0xjac yea that all makes sense. If you added something like you're describing we'd accept it (modulo code review and approval, of course).
Regarding renewals: the other option we've considered is allowing renewal-after-expiration. I think this would have almost identical security characteristics as ACME-STAR, and would probably be easier to implement. We'd probably want it implemented as a provisioner option. Whether we do ACME-STAR or renew-after-expiry I think it'll require CA users to be much more diligent about revocation: a private key effectively becomes useful forever (until all associated certs are revoked) with either of these features enabled.
@mkkeffeler I am working on an OCSP solution using cfssl. I am using cfssl as an ocsp responder which looks in to a table containing prebuilt ocsp responses for all non-expired certificates issued by step-ca. I am writing a go script to periodically populate the responses table. I will upload the script once i am done. Sidenote: I configured step-ca and cfssl to use mysql db. They both only have mysql in common.
Hello, unfortunately, I have not documented the process, but I created a PKI with OpenSSL replicating the name configuration as the production PKI, and later create the CRL. Also with OpenSSL, I was able to revoke actively the certificates created by the ACME PKI, and maintain in a CDP. The problem, in this case, is that I cannot show this CDP in the certificates generated by ACME.
@dharanikumar-s ha, so you have cfssl acting as an OCSP responder for step-ca? That's impressive... Sorry you had to go through all that hassle.
@Hardcorian certificate flexibility (https://github.com/smallstep/certificates/issues/300) should drop soon and you should be able to use that to add CDP to your ACME certs. I'm not 100% certain whether templates are going to work with ACME in the first code drop. I think they are, and if not it'll be a fast follow. @maraino will know.
@Hardcorian certificate flexibility (#300) should drop soon and you should be able to use that to add CDP to your ACME certs. I'm not 100% certain whether templates are going to work with ACME in the first code drop. I think they are, and if not it'll be a fast follow. @maraino will know.
Yes, you should be able to add the CRL distribution point using templates, for example, with the current version in https://github.com/smallstep/certificates/pull/312 a CDP can be configured in a template like this one
{
"subject": {{ toJson .Subject }},
"sans": {{ toJson .SANs }},
{{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
"keyUsage": ["keyEncipherment", "digitalSignature"],
{{- else }}
"keyUsage": ["digitalSignature"],
{{- end }}
"extKeyUsage": ["serverAuth", "clientAuth"],
"crlDistributionPoints": ["https://crl.example.com/cacrl.crl"]
}
