Adding your FreeIPA server’s CA certificate to the system-wide trust store on Fedora and RHEL

I noticed today that when I accessed my FreeIPA server’s web interface with Firefox it was considered to have a valid TLS certificate, but when I accessed it with Epiphany (GNOME’s “Web” browser) it was not.

After some poking around I developed a suspicion that they were using different CA trust lists. This is where I will handwave madly to avoid an extremely long digression:

HANDWAVE HANDWAVE nss HANDWAVE HANDWAVE PKCS#11 HANDWAVE HANDWAVE p11-kit HANDWAVE HANDWAVE GIO TLS

Very simple executive summary: neither Firefox nor Epiphany nor, probably, any other browser will trust your FreeIPA server’s certificate right after you do ipa-client-install, most likely.

If you have a FreeIPA setup, you probably want all your clients to trust the server’s CA certificate as hard as possible. ipa-client-install has only recently been modified to add the CA certificate to the Fedora system-wide certificate store. This change is not in Fedora 19 or Fedora 20, to my knowledge. It’s also not in RHEL 7. There’s a bug report to have it backported to RHEL 7.1.

Prior to that change, it added the server’s CA certificate to the NSS store in /etc/pki/nssdb. Now there’s something irking me here, which is that so far as I can tell Firefox ought to trust things in this certificate store, but it doesn’t actually seem to do so. Epiphany certainly doesn’t. I’ll update this post if I clear up the Firefox case.

It’s relatively easy to verify that your IPA server CA cert is in the NSS store:

[root@adam adamw]# certutil -L -d /etc/pki/nssdb
Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

IPA Machine Certificate - adam.happyassassin.net             u,u,u
IPA CA                                                       CT,C,C
[root@adam adamw]# certutil -L -n "IPA CA" -d /etc/pki/nssdb
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Certificate Authority,O=HAPPYASSASSIN.NET"
        Validity:
            Not Before: Mon Sep 23 22:17:56 2013
            Not After : Fri Sep 23 22:17:56 2033
        Subject: "CN=Certificate Authority,O=HAPPYASSASSIN.NET"

To check if it’s in the system-wide store, you can open the file /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt with Seahorse (“Passwords and Keys”).

Adding it to the system-wide store is very easy. ipa-client-install keeps a copy of it at /etc/ipa/ca.crt. So just do something like:

# cp /etc/ipa/ca.crt /etc/pki/ca-trust/source/anchors/ipa-happyassassin.crt
# update-ca-trust

If you have Fedora 20, you can simplify this to:

# trust anchor /etc/ipa/ca.crt

You can pick any filename you like, so long as it’s not likely anything else will use it later (and overwrite the file). As long as it’s in the right directory, update-ca-trust will pick it up.

After you add your CA cert to the store, Firefox and Epiphany will no longer complain that the certificate is untrusted when you browse to the web interface. Most other Fedora apps should also benefit from this fix.

2 Responses

  1. Dean Hunter
    Dean Hunter September 7, 2014 at 1:19 pm | | Reply

    Following you instructions I can see that CA certificate is on the NSS store. But when I try to add it to the system-wide store I get an error:

    [root@developer ~]# uname -r
    3.15.10-201.fc20.x86_64

    [root@developer ~]# ls -l /etc/ipa/ca.crt
    -rw-r–r–. 1 root root 2562 Jun 7 17:17 /etc/ipa/ca.crt

    [root@developer ~]# trust anchor /etc/ipa/ca.crt
    p11-kit: couldn’t create object: The field is read-only

    [root@developer ~]# yum list installed p11-*
    Loaded plugins: langpacks
    Installed Packages
    p11-kit.x86_64 0.20.4-1.fc20 @local-updates
    p11-kit-trust.x86_64 0.20.4-1.fc20 @local-updates

    Also, when using:

    [root@developer ~]# seahorse /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt

    many instances of this message are displayed:

    (seahorse:4721): Gcr-WARNING **: a derived class provided an invalid or unparseable X.509 DER certificate data.

Leave a Reply

Your email address will not be published. Required fields are marked *