On Fri, 2018-08-17 at 11:52 -0400, Mark Reynolds wrote:
On 08/17/2018 11:27 AM, Cassandra Reed wrote:
> Hi Everyone,
>
> We are in a sticky spot right now where we need to install a new
> certificate in our 389 Production system, but we do not have the
> password that was used when the system was built years ago. We
> have tried all of the possible passwords that we can think of, to
> no avail.
>
> Is there a way to blow away the old password or even blow away the
> NSS Database and create a new one? We need a new certificate
> installed ASAP to be able to move forward with a big project, so
> this is an issue with a lot of visibility.
There is no way to change it if you don't know the old password
(afaik), you must start over from scratch. Hopefully you don't need
any of the old certs.
To remove the current NSS database do the following:
[1] Stop the server
[2] Remove all the *.db files from /etc/dirsrv/slapd-YOUR_INSTANCE
[3] Create NSS database and add CA and Server certs via certutil
[4] I would suggest using a pin.txt file, see the admin guide for
more info on this.
[4] Start the server
Note - Use the same server certificate nickname as the old server
cert - it has to match the existing config (or change the existing
config to match whatever certificate nickname you use):
dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: Server-Cert <-- This is the cert nickname
and it must match what you use when you import the server
certificate.
nsSSLActivation: on
nsSSLToken: internal (software)
Our wiki's TLS guide is really good here, but I want to point out a few
things too. I'm also including my NSS command guide which I always
refer to for these tasks.
http://www.port389.org/docs/389ds/howto/howto-ssl.html
https://fy.blackhats.net.au/blog/html/pages/nss_and_openssl_command_refer...
So if you use attribute encryption, the encryption key is a hidden
component of the key3.db/key4.db. If you move the DB as mark suggests
*you will not be able to recover encrypted attributes*.
You may find the password in pin.txt in the same folder. There is an
attribute in cn=encryption,cn=config (I think ...?) which lists the
path to the pin.txt, if not, I think it's the same folder as the .db
files.
As always, take lots of backups, and test and have a recovery plan
available.
Hope that helps!
--
Sincerely,
William