SEC_ERROR_BAD_DATABASE 3.6
Sam McCormick
some of our client cannot gain access to our NSES 3.6. This happens
only to some clients but not all There is very little information on
www.mozilla.com regarding this error or it resolution.
Does it have anything to do with a corrupt cert.db or key.db ?
If I have to remove and reinstigate the SSL security on the server will
my exisitng clients be locked out and need to be reissed with new
certificates ?
Thanks
Sam
Nelson B. Bolyard
Since you wrote about issuing certificates to clients, I take it your
server requires SSL client authentication using certificates.
Did your client certificates come from a CA whose root CA certificate has
expired and been superseded by a newer one in the last year, by any chance??
Did your client certificates come from a Verisign CA by any chance?
(Please reply to the the netscape.dev.ssl newsgroup, thanks.)
--
Nelson Bolyard Sun / Netscape Alliance
Disclaimer: I speak for myself, not for Netscape
Sam McCormick
We are our own CA and we issue the certificate to our clients using our own
root certificate.
Also note I have created another set of key and cert dbs and mapped the security
to the database and re-generated the server-cert and imported the root
certificate - the problem still exists.
I there any way of testing outside of Netscape ES if a certificate and its
issuing root certificate are working.
Sam
Nelson B. Bolyard
>
> No
>
> We are our own CA and we issue the certificate to our clients using our own
> root certificate.
Have you ever in the past created more than one root CA certificate for
this CA? Have you ever created a test version, or a cert with the same
name and public key but different attributes (e.g. expiration date, or
usage extensions)?
Is it possible that some clients have a root CA certificate for this CA
that is not absolutely identical to the root CA certificate for this CA
that is stored in the NES 3.x server? Based on your description of the
problem, that seems to me to be the most likely explanation.
Are you able to correlate what clients that don't work have in common,
that is different from what clients that do work have in common?
Are the clients that exhibit the problem perhaps older (or brand new)
clients? (e.g. 3.x clients, or clients from a third party?)
Do you have more than one root CA certificate marked as trusted to issue
client certificates in the server's cert DB?
Does your server ever do "server-to-server" communications, where your
server acts like an SSL client and contacts another secure server (e.g.
ldaps or https)?
Can clients do anything that will make your server try to fetch data
from another secure server?
Do some clients use a proxy server and others not?
Do you operate a "reverse proxy" server?
> Also note I have created another set of key and cert dbs and mapped the
> security
> to the database and re-generated the server-cert and imported the root
> certificate - the problem still exists.
Do you use the same CA to issue server certs and client certs?
> I there any way of testing outside of Netscape ES if a certificate and its
> issuing root certificate are working.
I don't think the question is whether the certificate is working, but rather
is whether NES is correctly processing it. I don't know of any way to test
NES 3.x databases outside of NES 3.x and its admin server. There are some
external tools for iPlanet web server 4.x, but I don't know of any for 3.x.
Here's some more info that may be of help.
All Netscape (and iPlanet) web servers have two certificate databases.
One is the "permanent" DB, a disk file (e.g. certN.db, where N is the
version number). This file is opened read-only by the server, and any
corruption in that file is likely to be detected early in the execution
lifetime of the server. The other one is the "temporary" DB, kept purely
in memory. Certs are added to and deleted from the temp DB as the server
operates. Certs are added to it from the permanent DB, and also certs
received from clients are added to and removed from this DB. This DB
starts clean each time the server is started. Any problems with the temp
DB are eliminated by restarting the server.
There is only one set of error messages for both DBs. So, when you get a
"bad database" error, it could be for either one. Problems with the
permanent cert DB usually show up right after starting the server.
Since the perm DB is read only, if you get a bad DB error after the server
has been running for quite a while, odds are good that the problem is in
the temporary cert DB in memory. A problem in the temporary cert DB cannot
harm the permanent DB. It is not usually necessary or helpful to modify the
perm cert DB after a problem with the temporary cert DB.
The cert code in Netscape's 3.x servers is now over 4 years old.
I've been at Netscape over 4 years, and that code predates me.
I think (not certain) that the 3.x servers are no longer supported.
It seems likely that you're running into some sort of bug in the old
NES 3.x code. Unless you can live with it indefinitely, you will
probably need to upgrade to a newer supported product.
Over those years, numerous fixes to the cert code have been made.
Those fixes are available in the newer Netscape (now iPlanet) 4.x servers.
I'm suggesting that it is possible that you would not see the problem
you're seeing if you were running a 4.x (e.g. 4.1) web server.
(please continue to post followup messages to this newsgroup. Thanks.)
--
Nelson Bolyard iPlanet, the Sun / Netscape Alliance