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_reference.html 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 _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org/message/6TVM2XGDQMHASII5YYPKQHKR5YRP2LDD/
