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.
Any help is appreciated!!
-Cassandra
Cassandra Reed 978-762-4222 EDP Systems Analyst III North Shore Community College 1 Ferncroft Road, Danvers MA 01923
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)
Hope that helps,
Mark
Any help is appreciated!!
-Cassandra
Cassandra Reed 978-762-4222 EDP Systems Analyst III North Shore Community College 1 Ferncroft Road, Danvers MA 01923
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....
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_referenc...
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!
389-users@lists.fedoraproject.org
-
Cassandra Reed -
Mark Reynolds -
William Brown