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-leave@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/
No comments:
Post a Comment