SELinux Context Mismatch: The Hidden Culprit in LDAP Certificate Renewal
We recently had to renew a private SSL certificate used for internal LDAP access on one of our production web servers (e.g., prod-web-01). This certificate is not public-facing and is used only by the Support and DevOps teams internally, when connecting to the LDAP directory via Apache Directory Studio (i.e. LDAP client).
The certificate secures the LDAPS connection (port 636) between the LDAP client (GUI) and the LDAP service running on prod-web-01. This host provides internal LDAP services only, and the certificate is not shared with any external systems or applications. The certificate was issued by our private Root CA, hosted on a separate virtual machine and used solely for internal infrastructure.
On paper, this should have been a routine renewal.
The Plan (What Should Have Worked)
The process was straightforward:
- Generate a new CSR on the LDAP server
- Sign it using our private Root CA
- Copy the signed certificate back to
prod-web-01 - Replace the existing certificate files
Our OpenLDAP TLS configuration already referenced fixed paths and filenames:
TLSCertificateFileTLSCertificateKeyFileTLSCACertificateFile
Since none of these changed, no configuration updates were required. A service restart should have been enough.
The Failure
After copying the new certificates into place and restarting slapd, the service failed immediately with:
1TLS init def ctx failed: -1
Not the result we were expecting.
The Investigation
The usual checks came first:
- File permissions were correct (644/640)
- Ownership was set properly (
root:ldap) - The certificate chain validated cleanly
From a traditional Linux permissions perspective, everything looked fine. There was no obvious reason for LDAPS on port 636 to fail.
Then I ran:
1ls -alZ
That's when the problem became clear.
The Culprit: SELinux Contexts
Note: This article focuses on the practical troubleshooting of SELinux context issues. For a comprehensive understanding of SELinux and how it works, see Red Hat's guide: What is SELinux?
What is SELinux? Security-Enhanced Linux (SELinux) is a security module that enforces mandatory access control policies by labeling files and processes with security contexts, adding an additional layer of security beyond traditional file permissions.
The newly generated certificate files had the SELinux context:
1user_home_t
instead of the expected:
1cert_t
Because the certificates were generated and transferred from a different system, they retained a home directory–style security label when placed on the LDAP server.
SELinux enforces access based on security contexts, not just permissions. OpenLDAP requires certificate files to be labeled correctly; without the proper context, access is denied and TLS initialisation fails — even though everything else appears correct.
The Fix
Restoring the correct SELinux contexts resolved the issue immediately:
1restorecon -v /etc/openldap/certs/ldap-tls-gui-web01.crt
2restorecon -v /etc/openldap/certs/private-rootca-ldap.cert.pem
Once the contexts were corrected, the LDAP service started successfully and LDAPS on port 636 was available again.
Lesson Learned
On SELinux-enabled systems, TLS and certificate issues aren't always about permissions or ownership.
Always check the security context.
The ls -alZ command shows the full picture, and in this case, it led directly to the root cause. The fix persists across reboots, and internal LDAP access via the GUI is now fully restored.