Extract PEM certificates and keys from a shared NSS DB

$ certutil -L -d .

Certificate Nickname Trust Attributes



$ certutil -L -d . -a -n ‘FreeIPA CA’ > freeipa.crt

The PEM certificate should now be stored in free-ipa.crt.

To extract the PEM key from key3.db use certutil, pk12util and openssl.

$ certutil -K -d . -a
$ pk12util -o keys.p12 -n ‘FreeIPA Key’ -d .
$ openssl pkcs12 -in keys.p12 -out freeipa.key -nodes

Google Accounts engine problem and Gnome 3

I have login.keychain corrupted in my Gnome 3 enabled workplace due to the recent Google Accounts engine problem. For some reason it has become completely unusable, Gnome Keychain was unable to unlock it, Google Chrome stopped loading sites, goa-daemon died (as usual) and Evolution has stopped getting mail.

Goog Friday morning frustration.

OOM-killer fun

Recently I had installed RHEL 7 FreeIPA test lab on my workplace. I have made virtual host with default 1GB RAM, installed the system, enrolled it into the IPA domain OK, then tried ipa-replica-install. Turns out that 1GB is not enough and OOM-killer tries to solve the problem by killing processes that ipa-replica-install had spawned. Surprisingly turns out that for some reason the script is not detecting errors caused and you have strangely configured replica as the result.


If you have host in the AD with the SSSD then your root user can be any user from the domain. So


would actually give permissions to all users from the “groupname” to become any AD user they want, and if they’re SSH’ng the localhost then, they would have Kerberos ticket as well. It is not actually that evident, but Active Directory is an identity provider, so if you are superuser on the host — you can be AD user on the host.

Debugging IDM

One of the most frequent cases I have is that “sometimes” and “somewhere” user is not getting authenticated. Trying to SSH to the host works for some users not always, “id username” returns errors sometimes — it’s all the same problem in the environment with LDAP replication. It does not actually matter what kind of the LDAP server or domain controller is being used, always check:

    1. Enable debug log on the client. If the client is SSSD, add “debug_level = 9” to the /etc/sssd/sssd.conf and then restart it. Invalidate its cache if possible.
    2. Repeat the test so you would see the error.
    3. Collect the log file from the client. You would see what server it has queried to get the information.
    4. Check server’s log. Most likely there is no requested information on this LDAP instance due to replication issues.

This would help to identify and fix the problem.