Product SiteDocumentation Site

18.10. Troubleshooting

18.10.1. Starting FreeIPA with Expired Certificates

If FreeIPA administrative server certificates expire, then most FreeIPA services will be inaccessible, including administrative services. The underlying Apache and 389 Directory Server services can be configured to allow SSL access to those services, even if the certificates are expired.

NOTE

Allowing limited access with expired certificates permits Apache, Kerberos, DNS, and 389 Directory Server services to continue working. With those services active, users are able to log into the domain.
Client services such as sudo that require SSL for access will still fail because of the expired server certificates.
  1. Change the mod_nss configuration for the Apache server to not enforce valid certificates, in the NSSEnforceValidCerts parameter. If this parameter is not already in the file, then add it.
    Set the value to off.
    [root@ipaserver ~]# vim /etc/httpd/conf.d/nss.conf
    
    NSSEnforceValidCerts off
  2. Restart Apache.
    [root@ipaserver ~]# service httpd restart
  3. Change the nsslapd-validate-cert attribute in the 389 Directory Server configuration to warn instead of true to disable validity checks.
    [root@ipaserver ~]# ldapmodify -D "cn=directory manager" -w secret -p 389 -h ipaserver.example.com
    	
    dn: cn=config
    changetype: modify
    replace: nsslapd-validate-cert
    nsslapd-validate-cert: warn
  4. Restart 389 Directory Server.
    [root@ipaserver ~]# service dirsrv restart

18.10.2. There are SASL, GSS-API, and Kerberos errors in the 389 Directory Server logs when the replica starts.

When the replica starts, there can be a series of SASL bind errors recorded in the 389 Directory Server logs stating that the GSS-API connection failed because it could not find a credentials cache:
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
The replica is looking for a credentials cache in /tmp/krb5cc_496 (where 496 is the 389 Directory Server user ID) and cannot find it.
There may also be messages that the server could not obtain Kerberos credentials for the host principal:
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
These errors are both related to how and when the 389 Directory Server instance loads its Kerberos credentials cache.
While 389 Directory Server itself supports multiple different authentication mechanisms, FreeIPA only uses GSS-API for Kerberos connections. The 389 Directory Server instance for FreeIPA keeps its Kerberos credentials cache in memory. When the 389 Directory Server process ends — like when the FreeIPA replica is stopped — the credentials cache is destroyed.
Also, the 389 Directory Server is used as the backend storage for the principal information for the KDC.
When the replica then restarts, the 389 Directory Server instance starts first, since it supplies information for the KDC, and then the KDC server starts. This start order is what causes the GSS-API and Kerberos connection errors.
The 389 Directory Server attempts to open a GSS-API connection, but since there is no credentials cache yet and the KDC is not started, the GSS connection fails. Likewise, any attempt to obtain the host credentials also fails.
These errors are transient. The 389 Directory Server re-attempts the GSS-API connection after the KDC starts and it has a credentials cache. The 389 Directory Server logs then record a bind resumed message.
These startup GSS-API connection failures can be ignored as long as that connection is successfully established.