Re-deriving AES and 3DES attribute encryption keys for 389 Directory Server installation

1. Introduction

Even if you do not use attribute encryption keys in your 389 Directory Server (DS) installation, you might be bothered by all those messages that repeat themselves in /var/log/dirsrv/slapd-instance_name/error ("instance name" is your actual instance name), after every start/restart of the 389 DS daemon:

[04/Nov/2019:02:03:16.808096029 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher AES in backend userRoot, attempting to create one...
[04/Nov/2019:02:03:16.843731964 +0200] - ERR - attrcrypt_wrap_key - Failed to wrap key for cipher AES
[04/Nov/2019:02:03:16.808096029 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one...
[04/Nov/2019:02:03:16.843731964 +0200] - ERR - attrcrypt_wrap_key - Failed to wrap key for cipher 3DES

What causes their appearance and how to get rid of them (and to solve the problem they point to)?

There are two reasons for those message to be seen in /var/log/dirsrv/slapd-instance_name/error:

• the RSA-based X.509 certificate, used by the 389 DS server, was replaced with a new one and it has new encryption key (that situation might be fatal if your LDAP directory hosts encrypted attributes and the old RSA keys were lost);
• the 389 DS server uses Elliptic Curves based X.509 certificate.

First, some important remarks. While it is true that failing to access the attribute encryption keys is not a fatal event to most of the 389 DS installations, where upon the attribute encryption is not necessary and therefore - not truly implemented, the appearance of those error messages might indicate a disruption of some other services (especially those that frequently query the LDAP server). That means, you really have to investigate the source of those errors, if your goal is a reliable 389 DS installation.

2. The RSA-based X.509 certificate, used by the 389 DS server, was replaced with a new one and it has new encryption key

Go down to "Deriving new attribute encryption keys" to see how to fix the problem.

3. The 389 DS server uses Elliptic Curves (ECC) based X.509 certificate

389 Directory Server stores the keys, certificates, and passwords in Mozilla NSS DB storage. It is usually located inside the folder /etc/dirsrv/slapd-instance_name, where "instance_name" is the actual instance name of your 389 Directory Server setup (depends on how did you name the instance). The NSS DB store is split into three files: cert8.db, keys3.db, and secmod.db.

If the 389 Directory Server is configured to use SSL (and STARTTLS), a X.509v3 certificate is installed in the NSS DB store. The problem is that by default (so far), the administrative server sets any X.509 certificate in use, as if it is RSA-based. Therefore, in /etc/dirsrv/slapd-instance_name/dse.ldif (that is the starting configuration of the instance), you will find the entry:

dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: server-cert
nsSSLToken: internal (software)
nsSSLActivation: on

even if the X.509 certificate with nickname "server-cert" installed there (the nickname the certificate is know under in the NSS DB store) is ECDSA-based. And this "masking" of the ECDSA-based certificate as RSA, causes those errors from above to appear, when the SSL certificated is ECDSA-based. Note that the current method for deriving 3DES and AES attribute encryption keys is based on RSA encryption keys only. To solve this problem (especially if you want to deliberately generate 3DES and AES keys), you need to implement some workaround. That workaround works in the following way. Define an entry for the ECDSA certificate in the starting configuration (replace "server-cert" with your actual ECDSA X.509 certificate nickname, listed in the NSS DB certificate store):

$ ldapadd -D "cn=Directory Manager" -x -W
dn: cn=ECDSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: ECDSA
nsSSLPersonalitySSL: server-cert
nsSSLToken: internal (software)
nsSSLActivation: on

Then import into NSS DB certificate store new RSA certificate, that will be used only to support the attribute encryption key generation (we assume its nickname is "keygen-cert"), remove the old dn "cn=RSA,cn=encryption,cn=config" (if exists):

$ ldapdelete -D "cn=Directory Manager" -x -W "cn=RSA,cn=encryption,cn=config"

and add it again, pointing this time the attribute "nsSSLPersonalitySSL" to the RSA certificate nickname ("keygen-cert" in the example bellow):

$ ldapadd -D "cn=Directory Manager" -x -W
dn: cn=RSA,cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: keygen-cert
nsSSLToken: internal (software)
nsSSLActivation: off

PAY ATTENTION: To avoid the use of RSA certificate as a host certificate, and to force the use of ECDSA one for that purpose, you have to set nsSSLActivation to off. That is mandatory!

At this point, you might restart your 389 Directory Server instance:

$ sudo systemctl restart dirsrv@instance_name

Then proceed to "Deriving new attribute encryption keys".

4. Deriving new attribute encryption keys

If you don't know how many back-ends does your 389 DS currently supports, you might check that:

$ ldapsearch -D "cn=Directory Manager" -b "cn=config" -x -W "nsslapd-backend=*" nsslapd-backend | grep ^nsslapd-backend | awk '{print $2}'

(you will have to know the "cn=Directory Manager" password to complete the search). In most cases (default setup schema) the result will look like this:

userRoot

If the administrative server is also installed and configured, the NetscapeRoot back-end will be shown too:

NetscapeRoot
userRoot

The next step is to delete the dn-objects containing the AES and 3DES attribute encryption keys. For each back-end, you need to execute (replace BACKEND with the actual name of the back-end):

$ ldapdelete -D "cn=Directory Manager" -x -W "cn=AES,cn=encrypted attribute keys,cn=BACKEND,cn=ldbm database,cn=plugins,cn=config"
$ ldapdelete -D "cn=Directory Manager" -x -W "cn=3DES,cn=encrypted attribute keys,cn=BACKEND,cn=ldbm database,cn=plugins,cn=config"

If you receive "No such object" as a result, that might be a proof that only X.509 ECC-based certificates have been used with the current installation of 389 DS, ever since it was created.

You can restart now the 389 DS daemon (replace "instance_name" with your actual 389 Directory Server instance name):

$ sudo systemctl restart dirsrv@instance_name

and if the keys were successfully derived during the restart of 389 DS daemon, you will see the following messages at the end of /var/log/dirsrv/slapd-instance_name/error (two lines for each back-end):

[04/Nov/2019:04:57:08.393260367 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher AES in backend userRoot, attempting to create one...
[04/Nov/2019:04:57:08.446317176 +0200] - INFO - attrcrypt_cipher_init - Key for cipher AES successfully generated and stored
[04/Nov/2019:04:57:08.470085086 +0200] - ERR - attrcrypt_cipher_init - No symmetric key found for cipher 3DES in backend userRoot, attempting to create one...
[04/Nov/2019:04:57:08.504787008 +0200] - INFO - attrcrypt_cipher_init - Key for cipher 3DES successfully generated and stored

No such messages will appear again during the next restarts, unless you remove the employed RSA-based X.509 certificates from the NSS DB.

Read More

How to protect the Google Chrome NSS Certificate DB store in Linux with password

Google Chrome for Linux, keeps the installed X.509 certificates and keys in NSS Certificate DB store, which is not protected by default. That means, everyone with access to the browser and/or the user's home directory, can copy the signing keys. The goal of this memo is to explain how to protect the Google Chrome's certificate store with password.

Note, that the folder, where Google Chrome keeps the NSS Certificate DB files per user is:

${HOME}/.pki/nssdb

During its first start (initiated by the user), the browser generates the NSS Certificate DB store files there in:

cert9.db
key4.db
pkcs11.txt

It is very important to keep in mind that Google Chrome uses SQLite3-based format of NSS Certificate DB, when using the NSS tools to manage the database.

To list the content of the database, use the tool certutil (mind the file system locator "sql:" that is after "-d" in the command line bellow):

$ certutil -L -d sql:${HOME}/.pki/nssdb

If there are X.509 certificates installed in NSS Certificate DB, you will see their friendly names and trust attributes (otherwise, only the column descriptions will be displayed).

To set the password for protecting the keys and the integrity of NSS Certificate DB, stop Google Chrome first (check if it is running), and then execute the following command line:

$ certutil -W -d sql:${HOME}/.pki/nssdb

That will start a dialogue in the terminal. At the beginning, you will need to type the current password (simply press "Enter" to try the default password, which is an empty string):

Enter Password or Pin for "NSS Certificate DB":

If that is the correct password, the next step will begin with the following statement displayed:

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

followed by a prompt, where the new password for protecting NSS Certificate DB to be entered twice:

Enter new password:
Re-enter password:

If the new password is correctly typed, a confirmation message will be displayed:

Password changed successfully.

From this moment onward, the installation of new certificates (with or without their private keys) in NSS Certificate DB, as well as the access to the installed private keys, will be granted based on password.

To verify the password controlled access to the NSS Certificate DB is working, run Google Chrome, type in the address bar:

chrome://settings/certificates

and press "Enter". If NSS Certificate DB is password protected, the following window will appear on the screen:

(note the window description saying "Please sign in to NSS Certificate DB"). In case you cannot provide the correct password, only read-only access to the NSS Certificate DB will be granted, with no access to the private keys installed there (that means no certificate authenticated logins, no digital signatures).

What if I forget the password for NSS Certificate DB?

You cannot do much, because the private keys, previously installed in the database, are now encrypted with a password you have forgotten. Moreover, the password is irretrievable, since no additional decryption key or another mechanism, that might help to retrieve the password from the locked database files exists, as a part of the NSS Certificate DB design. Hence, if you forget the NSS Certificate DB password, consider the keys installed in there lost.

In case you keep backup copies of the certificates and keys (as PFX/PKCS#12 files), you might create a new database and install them there. To create new NSS Certificate DB, you need to stop Google Chrome (mandatory). Then move the old NSS Certificate DB files to a temporary location (who knows, one day the forgotten password might be found):

$ mkdir ${HOME}/.pki/nssdb-lost
$ mv ${HOME}/.pki/nssdb/* ${HOME}/.pki/nssdb-lost/

and create new database files in ${HOME}/.pki/nssdb:

$ certutil -N -d sql:${HOME}/.pki/nssdb

After the message:

Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

enter the new password twice:

Enter new password:
Re-enter password:

and if the confirmation message:

Password changed successfully.

is displayed, you new (but empty) NSS Certificate DB, is created and protected with password.

Now you can run the Google Chrome and install the certificates and private keys, using the NSS Certificate DB management tools, embedded in the browser.

Read More

Using nmcli to create 802.1x EAP-TTLS connections

The GUI of NetworkManager is pretty user friendly, when it comes to create easily 802.1x connection configurations (WPA2 Enterprise). In a command line environment (non-GUI setups) that kind of connections should be created and handled by using the TUI tool nmcli. When invoked, that tool communicates with the locally running NetworkManager daemon.

It is rather strange that on many Internet user forums an easy thing to do, like creating and exploring 802.1x connection by using nmcli, is declared mission impossible, and wpa_supplicant is pointed out as the only available tool for connecting to WPA2 Enterprise hotspot infrastructure. The goal of this post is to show that nmcli is capable of doing that natively.

To create 802.1x connection in command line mode the nmcli tool need to be invoked correctly. It is not practical to enter the nmcli interactive shell for describing the connection parameters one by one. The easiest way is to create the connection description at once by executing a single command line. Note that some of the options passed as arguments to nmcli are in fact critical, even if they are not considered as such by the syntax checker. For instance, the process of tunnelling the plain-text password requires a positive verification of the RADIUS X.509 certificate to resist the mighty "man-in-the-middle" kind of attacks. Therefore, a copy of the CA X.509 certificate need to be stored locally, as text file (preferably in PEM format).

The example bellow shows how to define all the parameters of a 802.1x connection, required for using "eduroam" hotspot (more about Eduroam):

$ sudo nmcli connection add type wifi con-name "eduroam" ifname wlan0 ssid "eduroam" -- wifi-sec.key-mgmt wpa-eap 802-1x.eap ttls 802-1x.phase2-auth pap 802-1x.identity "user@some.edu" 802-1x.anonymous-identity "anon@some.edu" 802-1x.ca-cert "/home/user/CA-wifi.crt" 802-1x.password 3423sd3easd32e2

Note the use of full path to the CA X.509 certificate file given above (/home/user/CA-wifi.crt). Declaring a relative path instead need to be avoided.

In case of a successful execution of the command line, the connection "eduroam" will appear as available in the list of suported connections:

$ nmcli c s

Once listed there, the connection can be activated by executing:

$ sudo nmcli c up eduroam

and in case of successful activation, the usual kind of message will appear on the display:

Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/9)

It is very good idea to clear the shell history in order to prevent the password from disclosure, since it is part of the command line defining the connection.

The example given above has been tested on the latest CentOS 7, Red Hat Enterprise Linux 7, Scientific Linux 7, and Ubuntu 18.04.1 LTS.

Read More

Using LDAPS (LDAP+TLS) from within the Sendmail configuration file

 

Content:

1. Introduction.

2. Installing and configuring OpenLDAP certificate database

3. SELinux configuration.

4. LDAP+TLS in sendmail.mc/sendmail.cf.

 

1. Introduction.

If one need to implement LDAP+TLS to securely connect sendmail daemon to the LDAP directory server, they need to enable and use the existing OpenLDAP integration of Sendmail. Most of the modern Linux distributions provide as a part of their package collections Sendmail compiled with OpenLDAP integration. But when it comes to configure Sendmail to connect to LDAP server by securing the TCP session with TLS it is very hard to find online an useful example. Almost all examples available explain how to configure Sendmail to use LDAP server through a plain TCP session. The goal of this document is to explain how to do that configuration. The explanations bellow are 100% compatible to Sendmail setup based on CentOS 7 or Red Hat Enterprise Linux 7, but they might be implemented to any other modern Linux distribution as well.

 

2. Installing and configuring OpenLDAP certificate database.

In CentOS 7 and Red Hat Enterprise Linux 7 the OpenLDAP clients configuration used by default the configuration and certificated based located in the directory /etc/openldap. That folder is supplied to the system by the package named openldap. In most cases, but also depend on the type of the installation, the package openldap should be presented in the system by default. Nevertheless one must check and verify that the package exists and it is up to date (not keeping your system up to date is risky). If the package openldap is not presented, install it by using yum:

# yum install openldap

If the installation is successful the package will create the folders /etc/openldap and /etc/openldap/certs. That last folder contains NSS database:

/etc/openldap/certs/cert8.db
/etc/openldap/certs/key3.db
/etc/openldap/certs/password
/etc/openldap/certs/secmod.db

There the file named "password" contains the password for unlocking the NSS database when accessing the stored private keys and passwords. The NSS base is created empty by default which means that one must add there at least the CA certificate that helps to verify the validity of the LDAP server X.509 certificate (the LDAP server Sendmail will be connected to). For example, if the CA X.509 certificate "COMODO RSA Certification Authority", stored in PEM format in the file /tmp/COMODO_RSA_Certification_Authority.crt, should be added to the NSS database and trusted, that can be done in the following way:

# cd /etc/openldap/certs # certutil -A -d . -n "COMODO RSA Certification Authority" -a -i /tmp/COMODO_RSA_Certification_Authority.crt -t "CT,c,"

Please, note that the use of NSS libraries with OpenLDAP is specific to CentOS and Red Hat Enterprise Linux 7. Another Linux distributions might use OpenSSL libraries instead of NSS ones.

 

3. SELinux configuration.

By default the Sendmail OpenLDAP client process cannot access the NSS certificate database of OpenLDAP. In order to make the access possible, one need to set the SELinux boolean authlogin_nsswitch_use_ldap to true:

# setsebool -P authlogin_nsswitch_use_ldap 1

 

4. LDAP+TLS in sendmail.mc/sendmail.cf.

The LDAP+TLS can be configured by using a specific URI format "-H ldaps://hosname:port", where the port number is optional. Bellow is a detailed example in m4 format which need to become part of the m4 Sendmail configuration file sendmail.m4:

define(`confLDAP_DEFAULT_SPEC', `-H ldaps://directory.example.com -b "o=example.com" -d "cn=sendmail,ou=Special Users,o=example.com" -M simple -P /etc/mail/password-sendmail.ldap')dnl

If one need to specify the LDAP client settings directly in sendmail.cf the following configuration line should be added there:

O LDAPDefaultSpec=-H ldaps://directory.example.com -b "o=example.com" -d "cn=sendmail,ou=Special Users,o=example.com" -M simple -P /etc/mail/password-sendmail.ldap

Read More