Revocation of successors of compromised certificate

[vulnbe]

Hey team.

Suppose a short-lived certificate is issued. The certificate and key are compromised and the attacker issued a new certificate using the old one: step ca renew compromised.crt compromised.key --out=new.crt

We revoke the compromised certificate: step ca revoke --cert compromised.crt --key compromised.key

Meanwhile, the new certificate is still valid. So the attacker will re-issue himself certificates as he needs.

It seems such dependent certificates should be revoked automatically.

Also, how can we review of all issued and valid certificates using step ca?

[rmhrisk]

This is dangerous; you can not tell if the second key was requested by the authorized user as a means to keep availability once the revocation happens (replace and revoke). If you have an indication that key1 was revoked for key compromise reason AND you have a record that the subsequent certificates were issued using the revoked key after the revocation then you could prompt and ask but I would not do revocation automatically, there are plenty of outages related to related behavior in other software.

[dopey]

Hey @vulnbe thanks for opening the bug report! Hadn't completely thought through this use case / eventuality before.

@rmhrisk your'e totally right (didn't immediately see it w/out your comment, so thank you). There are many reasons to revoke a certificate when it hasn't been compromised. In fact, the standard operating procedure that we encourage is to revoke a certificate any time you are done using it. The standard lifecycle of a certificate should end in revocation. Before it's revoked, it generates it's successor.

I agree with @rmhrisk that the feature here would be offering to revoke all certificates in the compromised chain, iff the key is known to be compromised and the descendants can be clearly tracked.

We're not currently storing that data (provisioning cert, provisioning pub key identifier), but we should be. I'm going to retag this as an "enhancement" since I think the system works as intended, however, we could be doing more in regards to revocation.

[dopey]

As to the second question (about reviewing all valid certificates), there is this open issue: https://github.com/smallstep/certificates/issues/239. Would you mind leaving a comment in support (or just a +1), assuming you are interested in that functionality. Community support / engagement for an issue plays a big role in helping us prioritize the roadmap.

[vulnbe]

@dopey Thanks for reply! This issue not about standard revocation of a certificate but revocation of successors which renewed using compromised.

In current version it is required to stop CA and extract serials of certificates manually from database. I did not try to do this, so I do not know if there is enough information in the database.

[mmalone]

Thanks for raising this @vulnbe. Also, thanks @rmhrisk for the insight around availability issues. I hadn’t completely considered this.

I have a couple thoughts here that I’d love feedback on from the community:

1. Currently you can renew a certificate multiple times as long as it’s 1) not expired, and 2) not revoked. So if you have foo1.crt you can “renew” it twice and get foo2.crt and foo3.crt. I’ve been considering whether we should change the default behavior (or at least add an option) to “auto-revoke on renew”, which would prevent multiple renewals. This seems like good hygiene, but @rmhrisk’s comment about availability issues makes me question whether this is wise.
2. As @dopey pointed out above, we’ve had a few requests for better reporting on issued certs from the CA. Internally we like certificate transparency for this, but we also recognize that people would appreciate a lighter weight solution as well. One thing I would like to see is a mechanism to request what @vulnbe called “dependent certificates” — basically, I’d like to be able to pull certificates from the CA by “lineage”. For example, “give me all certificates that are descendants of certificate X”. @vulnbe, if an API like this were available would that satisfy your use case? It seems like you’d be able to easily script the behavior you want, and you’d be in a better position to address the availability risk that @rmhrisk has identified (i.e., the CA may not be able to generically tell whether a certificate is legitimate, but you probably know).
3. We’ve been mulling over an administrative “override” feature that would allow you to re-enable renewal for a certificate that’s expired (and/or revoked). This has come up primarily around connected-device and endpoint use cases where devices have intermittent connectivity or sometimes go offline for long periods of time. There needs to be a workflow to bring a device back online, and the most straightforward thing I can think of is to allow “renewal-after-expiry” in these cases. This might also help address any availability issues that arise here, as they could be easily and safely remediated from a central location. One alternative we’re looking at is something like ACME-STAR, where the CA actually auto-renews certificates that haven’t been revoked automatically and makes the new certificates available publicly. Right now we’re thinking we’ll probably do both.

Feedback / thoughts very welcome on any of these points!

[dopey]

Following up --

Rather than auto-revoking the logical descendants of a particular certificate or key, we want to empower the user to make those decisions. Our plan is to build observability tooling that will allow admins to query across multiple attributes of a certificate. Some examples of queries we plan to support:

• query for all certificates with public key XYZ
• query for all certificates that are logical descendants of a certificate X with serial 123
• query for all certificates that will expire soon and have not been renewed
• query for all certificates that expired without being renewed

Tracking the successors of compromised certificates is an important feature. I can't give an estimate for when a robust implementation will be available. However, we do plan to release some quick and scrappy scripts for scraping the database in the short term.

[anthonyjlmorel]

Hi Guys,

Do we have an update about this? Even the scrappy scripts to explore logs/db could do the trick for a start :smiley_cat:

[dopey]

Hey @anthonyjlmorel appreciate the reminder. We've actually been hard at work on this. We're releasing a certificate observability feature within the next month. You'll be able to "link" your open source CA up to our hosted platform to see issued certificates, lineage, set up alerts, and webhooks. Linking a single open source CA will be free. We'd love to get your feedback on it once it's live.