On 05/19/2010 02:51 PM, Bud P. Bruegger wrote: > Hello, I would like to ask your advice on how to best deal with a > problem related to deleting certificates/keys. > > I'm currently experimenting with creating short-lived certificates for > TLS-client-authentication using the <keygen> element. While it seems > easy to create the keys/certs, I have more problems deleting them. > > Ideally, I would like to delete all certs I created before adding > another one. I can do this from a local app (i.e., it doesn't > have to come over the web which I assume isn't possible for security > reasons). > > I have experimented with certutil -D but I have some doubts about that > approach: > > * can certutil access the database while the browser is running and > using it? (An un-dated discussion mentioned the use of an old version > of Berkely DB where concurrent access was considered dangerous). With the berkeley DB, no. With the sqlite DB yes. Note: PSM appears to hang on to cert references longer than most applications, so I've started seeing some cases where deleted certs don't show up as deleted in the app because it still has the reference to the old cert. (most commonly in the case of cert chains and SSL. > * chosing the cert to delete by nickname is not easy--is the way a > nickname is constructed documented somewhere? I'd prefer to select > certs by issuer, is there a way? > And particularly bad in your case all certs with the same subject are forced to share the same nickname. Unfortunately certutil doesn't have another interface for selecting the cert like other applications do. > * in my reading of the doc, it seems that I don't need to know the > password for accessing the db when deleting. (certutil -h says > "certutil -D -n cert-name [-d certdir] [-P dbprefix]" without a [-f > pwfile] option). > Can you confirm this? > The database is just a set of records. There is no way to prevent someone who has access to that file from deleting any records. In general, the PKCS #11 interface determines what permissions you need, for certs it's no password (with our token), but for keys associated with the certs you will need a password.
Looking at the code, it appears that tokens that require authentication to delete, it won't work. > * Does certutil -D also delete the corresponding keys or do I need to > use certutil -F. Is there a way to delete orphaned keys? > -D will just delete the cert. -F will delete the cert and it's corresponding key if there are no other certs referencing that key. (Note, this will require the password). > Alternatively, are there any better ways for my needs than certutil? > If you are running as an extension inside the browser, you can use the NSS primitives to delete certs and keys (including looking them up by issuer/sn). This will also solve the issue of multiple processes accessing the DB since you are running from the same process as the browser. > Maybe some magic where new certificates automatically replace > older ones with the same Subj DN? You are allowed multiple certs with the same Subj DN. (encryption/auth/signing cert groups usually all have the same Subj DN. Old encryption certs also have the same Subj DN and need to be around to decrypt old email), so no there is purposefully not a way to replace older ones with the same Subj DN (we work to make sure we don't do that;). > Any DB-level-access (Berkeley DB..) > to the db files (maybe with locking)? > Sqlite (sql:) allows multiple processes to access the same database safely. The old Berkeley DB code itself can't handle shared access. > Many thanks in advance for any help! > > -b > > >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
