Switch OpenLDAP from NSS to OpenSSL
Summary
Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for crypto. OpenLDAP is going to be compiled with OpenSSL, instead.
Owner
- Name: Matus Honek
- Email: mhonek (at) redhat.com
- Release notes ticket: #120
Current status
Detailed Description
Insight
OpenLDAP in Fedora has been compiled with NSS for crypto for several years now. Support layer for NSS was added back in 2008 but the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons for keeping OpenLDAP compiled with NSS was to make it work with some other packages (esp. 389DS) seamlessly. Fixing and keeping downstream patches has become a burden, thus it was decided to switch to OpenSSL, instead.
Dependents
389DS
Upstream patch that mirrors certificates to PEM files so that OpenSSL-built OpenLDAP library may be used, is supported since version 389-ds-base-1.3.5
.
See the design document.
FreeIPA
- BuildRequires openldap-devel
- Requires openldap-clients
SSSD
- BuildRequires openldap-devel
other
- dhcpd: BuildRequires openldap-devel
- python-ldap: BuildRequires openldap-devel; uses OpenSSL for TLS, so maybe not a problem?
Schedule
This is the proposed timeline that aims for clean adaptation by other components and users. In later Fedora releases the actual timelines may change.
Fedora 28
- Land the OpenSSL-built OpenLDAP.
- Include the #Interception code.
- Have
X_MOZNSS_COMPATIBILITY
implicitly set on by default. - Include a deprecation warning.
Fedora 29
- Have
X_MOZNSS_COMPATIBILITY
implicitly set off by default.
Fedora 30
- Drop the #Interception code patching entirely.
- Drop the deprecation warning.
Implementation
The code handling possible NSS-specific configuration (#Interception code) should handle all possible use-cases (libldap, openldap-clients and openldap-servers packages). Briefly, the code should make usage of both, OpenSSL-specific and NSS-specific, configurations seamless with no more than setting the X_MOZNSS_COMPATIBILITY
option on.
Build
Will build with ./configure --with-tls=openssl
, dropping --with-tls=moznss
. Also, NSS libs will be needed to be included so that the #Interception code works.
Interception code
Enabling
A yes
/no
options LDAP_OPT_X_MOZNSS_COMPATIBILITY
(libldap), X_MOZNSS_COMPATIBILIY
(ldap.conf, slapd.conf), and olcMozNSSCompatibility
(slapd-config) may be used to explicitly set whether the #Interception code will be used.
Implementation
After parsing user options change these accordingly:
- keep
CACERT
as set - if
CACERTDIR
is NSSDB then- if NSSDB is pin-protected then unlock it using
KEY
- extract all CA certs to
ca.pem
- extract all CA certs from
(DEFAULT_)MOZNSS_DIR
environment variable to(default_)moznss_dir.pem
- extract user cert and key to
user.pem
- get the randomly pre-generated DH params from NSSDB and put it into
DHParamFile
- update options so that they work for OpenSSL
- tear down the NSS context
- if NSSDB is pin-protected then unlock it using
- go on with OpenSSL only
Although all configuration and runtime cases should be handled, in case the #Interception code is not able to continue as expected it should fail cleanly with an appropriate error.
Considerations
PEM files location
We should keep the NSSDB in place, while creating a directory with the same owner and permissions for storing the extracted PEM files. If the directory cannot be created, we should temporarily put these to a tempdir (in /tmp
).
CRLCheck and CRLFile options
NSS uses CRLFILE
option only, whereas OpenSSL uses CRLCHECK
bool. There is no feasible way to be backward-compatible.
NSS still used
Even though temporarily, NSS library is still used possibly causing some (although few) troubles.
Pitfalls
Downgrade
Will not be supported automatically. We should provide steps how to revert to NSSDB having OpenSSL-like configuration in place.
Mixed configuration options have undefined behaviour
If both, OpenSSL-like and NSS-like, configurations are used for various configuration parameters at the same time then the behaviour SHOULD not be destructive but it is undefined.
Benefit to Fedora
Support from upstream -- currently, most bugs are related to MozNSS and upstream refuses to bother with our TLS or PKI related issues as they do not support MozNSS anymore.
Scope
- Proposal owners: write the #Interception code.
- Other developers: ensure usage of OpenSSL-like TLS configuration based on the #Schedule.
- Release engineering: [1]
- List of deliverables: Not affected
- Policies and guidelines: none.
- Trademark approval: none.
Upgrade/compatibility impact
No issues should occur in the first phase (see #Schedule).
How To Test
- This change is not hardware-specific.
- This changes the
libldap
library, thus all packages of the OpenLDAP component are affected, as well as all the other packages that Require or BuildRequire some of OpenLDAP packages. - Testing
- Sanity testing should be done for both MozNSS-NSSDB-like and OpenSSL-like configuration and for each of the following specifics:
- Basic self-signed CA cert and user cert/key
- Self-signed CA cert chain
- Dependent packages' tests
- Sanity testing should be done for both MozNSS-NSSDB-like and OpenSSL-like configuration and for each of the following specifics:
All configurations should work as expected, no regression should occur.
User Experience
No changes should occur. However, from the third phase (see #Schedule) on users will not be able to use NSSDB.
Dependencies
This change does not depend on any other change.
Contingency Plan
- Contingency mechanism: revert the patches implementing the change. No external changes would be required.
- Contingency deadline: beta freeze.
- Blocks release? No.
- Blocks product? No.
Documentation
OpenLDAP-and-MozNSS-Compatibility-Layer
Release Notes