Mike wrote: > The reason we need to change certs "on the fly" is because we have > system requirements saying that passwords and credentials must be > renewed every 90 days. So user passwords and their LDAP certs are > subject to this. Now, I don't know if the expiration is enforced > inside the certificate, I'd have to ask our Unix folks. What I do know > is that it's a possibility, and in fact very likely right now, they > will run a script to generate the new cert for a user when the old one > expires.
There's still a lot I don't know about how things work in your environment, but I'm going to guess at a few things in a way that I think is consistent with the info you presented. 1) I'll bet that your DS keeps a DB of the authorized certificates. When it is presented with a client certificate, I'll bet it checks in the DB to see if that cert is authorized, and if not, it reports INVALID_CREDENTIALS. 2) I'll bet that his cert validity checking is only donewhen a cert is presented to it, e.g. at the beginning of an LDAPS connection (SSL session), when the SSL client authentication is done. 3) Whe your Unix folks run that script that generates a new cert for a user, I'll bet that it updates that server DB of authorized certs to show that the cert for user XXX has changed, and the old cert is no longer authorized and the new one is. This is a kind of cert revocation checking. > What's interesting to note in all of this is that it's only a problem > when DS closes the connection and the app tries to rebind. And the cert has been reissued prior to the rebind. > our DS closes > inactive connections after 90 seconds. So I ran two tests. First, I > have a test driver that connects and adds an entry, sleeps 100 seconds, > then deletes the entry and exits. I had one of our Unix guys recreate > the certs during the sleep, so when the app tried to delete the entry, > it saw the connection was closed and tried to rebind, and that's when I > got INVALID_CREDENTIALS. Right. I's guessing that when the client tried to rebind, it presented its same old certificate to the server, and the server said "that certificate is no longer authorized." > Next I changed the sleep to 30 seconds, and > again re-created the certs during this sleep. This time the app tried > to delete entry and the connection was not closed, so it proceeded > normally -- eventhough it's credentials we're technically invalid. In this case, since the connection had not been closed, no new client authentication was performed. The delete request came through the channel without its credential being rechecked, since it was the same connection previously authorized. So the request came through an authorized channel and was honored because the channel's credentials were not re-checked at that point. > Not sure if this is intended behavior or a bug, but it's definitely > interesting. > > I think you're third suggestion, creating a new cert and key db and > then doing a phased migration, is probably the most feasible. We could > maybe setup some logic where if sasl_bind returns INVALID_CREDENTIALS, > we try again with the "second" cert and key database. If the client is not particularly performance sensitive, if a couple extra milliseconds on each bind operation is tolerable, then you might very well check for the presence of a new cert DB at the beginning of every bind, and switch over to the new one whenever a new one is available (prior to the bind) simply because a newer one is available. (This is a natural way to handle phased switchover, BTW, because different apps attempt to rebind at different times.) > When these > become invalid, we switch back to the original. In a sense, we just > rotate between two sets of databases, where one always has the most > recent (and valid) credentials. Or perhaps we could utilize the prefix > for the databases to just keep creating new ones. Yeah, you update these quarterly. They're pretty small, generally less than a megabyte. So you could give these files a file name prefix of the form yyyyQn- (e.g. 2006Q3-cert8.db) and just keep creating new ones. This way, you can always go back and see the cert you used way back when. A couple hundred KB growth per user per year is pretty inconsequential, IMO. > But really I think > the most plausible solution for us, given how our apps run and the > amount of effort it could take to implement any sort of multiple > database scheme, may very well be changing requirements for how often > our certs expire. The usual reasons for giving certs short lifetimes are a) to bound the amount of revocation information that must be kept on hand (you don't have to remember that you revoked a cert after it expires), or b) in the absence of revocation checking, to bound the amount of time that a "bad" cert can be used after it should have been revoked. In your case, if (as I surmise) your server has a DB of authorized certs online at all times, then it has perfect revocation information at its disposal. In that case, you don't need to reissue certs frequently, because you can always revoke them at the server at a moment's notice. -- Nelson B _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
