kaikramer / keystore-explorer

KeyStore Explorer is a free GUI replacement for the Java command-line utilities keytool and jarsigner.
https://keystore-explorer.org/
GNU General Public License v3.0
1.69k stars 273 forks source link

Display revocation status of certificates in list view #411

Open aner-perez opened 1 year ago

aner-perez commented 1 year ago

Is your feature request related to a problem? Please describe. When using kse as a simple certificate authority (e.g. for end user OpenVPN certificates), it would be extremely useful to see which certificates are currently revoked by including a column for this in the certificate list view. Many users are added and later revoked when their affiliation changes so the list becomes cluttered with users that are no longer active.

Describe the solution you'd like KSE keeps track of the revoked certificates for a keystore using a .db file. This file could be loaded if present when opening the keystore to populate a "Revocation Status" column on the certificate list. This would allow seeing at a glance which certificates are revoked/active.

Describe alternatives you've considered The only way I have found to do this currently is to choose the Verify action (from View Details dialog or the right-click context menu on the certificate), select "CRL file" and choose a previously export CRL file and then press OK. These steps must be done for each individual certificate you want to verify/audit. It does not offer the option to use the revocation ".db" for the keystore or prefill the last CRL file used to verify a certificate. If showing revocation status on the certificate list is considered too expensive then allowing the revocation .db file for the repository to be used when verifying the certificate would be a small improvement although it would still be painful to use for a large number of certificates.

kaikramer commented 1 year ago

I think that's a good suggestion, but it will be difficult to get this "right". A few first thoughts:

Being too expensive is probably not a problem when using the .db file. But what about the other sources for revocation data, like an HTTP URL in the CDP extension or a OCSP responder? There is not only the use case of KSE acting as a simple CA.

Sometimes there is a .db file sometimes not. What happens to the "revocation" column if there is no .db file? Leave it empty? Remove it? Try to fill it with revocation infos from other sources?

Maybe it's a bad idea to mix something into the main table (which is supposed to show the content of the keystore), that is not part of the keystore.

I could imagine something like selecting multiple files in the main table, then click the verify menu entry and then you get the result for all the selected certificates in a new table.

But if we create a new window with a new table that contains the revocation status, then there will be restrictions regarding what you can do in this new table. This might be fine if you just want to see a status list, but what if you want to delete all revoked certificates from the keystore?

aner-perez commented 1 year ago

Good points, as an end user you end up so focused on your own use case that you miss how it might affect other ways to use the system.

I like the idea of showing this information on the existing table because it is a relatively small visual change and can piggy back on the existing functionality of the table such as the actions available and the sorting, etc.

Would it be possible to have a verify action at the keystore level so when the user selects that action it prompts for the source of the revocation data and then checks every certificate and adds a column to the existing table? It should also give the option of selecting the .db revocation file as the source of revocation data (here and on the other Verify actions).