cryanwork wrote:
I am trying to recover a CMS 4.2 system where the administrator
certificate used to approve new requests has been lost. Yes, there was
only one. I have thought of two approaches and can't seem to make the
first work. Any help on why would be greatly appreciated as well as
thoughts on approach 2.
CMS is one of many applications that use NSS. I'm not a CMS expert, and
I cannot advise you on the probability of success with either approach,
but I can help you with the NSS utility programs.
Approach 1:
generate a new admin cert using certutil and add to admin user group in
CMS.
tried certutil -R to create a binary certificate request file (successful)
tried certutil -C to create new binary certificate
(failed)
C:\iPlanet\Servers\bin\cert\tools>certutil -C -c cert-suncms -i
newadmincertreq.bin -o newadmincert.bin -d ./
certutil: could not find certificate named "cert-suncms": security
library: bad database.
certutil: unable to create cert (security library: bad database.)
I see you're doing this on a windows/DOS system (maybe OS/2 :-) and those
systems generally are not as forgiving of double slashes in path names
as Unix systems are. So the problem may be that you specified a
directory name of "./" instead of merely ".". certutil appends a slash
and the name of the file it's trying to open, so it probably tried to
open .//cert7.db and that probably failed. So, try it with a path name
that does not end with slash.
Make sure the directory and files are writable by your user. If they're
not writable, you will see failures like the one you saw. Be sure to
back up your DBs before you attempt to modify them.
Also, before trying to make any modifications to any DBs, first just be
sure you can get the NSS utilities to read the DBs. Try
certutil -d . -L
and see if that can succesfully list the certs in the DB. After doing
that, you will know whether certutil is not finding the cert because it
just isn't there, or it has a slightly different nickname, or there is a
problem with the DB (least likely, IMO).
A related thought. You're apparently using an old version of CMS that
uses an old version of NSS, which uses cert7.db. Modern versions of
NSS use cert8.db (new file format), and will attempt to upgrade an old
cert7.db to the newer cert8.db if you attempt to make any changes.
Be *sure* you're using a version of NSS utilities and libraries that
use the same file version (e.g. cert7) as your CMS uses. If you use a
newer version of NSS, it will create a cert8.db (with the info from your
cert7.db) and then make the changes to cert8.db, which won't be helpful
to any programs that use the older cert7. If you find a new cert8.db
file in the directory after running certutil to modify the DB, you're
running a newer version that is probably incompatible with your old CMS.
I had copied the cert7db and key3.db files to the tools directory to try
this. Interestingly, attempting the above but pointed at the original
certdir seems to find the named issued cert
It might be that when you named that directory, you didn't have a trailing
slash on the directory name.
but still wont allow the signing.
Won't allow? what specific error do you encounter?
Thanks,
Chris
--
Nelson B
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
