On 3 Jul 2020, at 04:21, Ghiurea, Isabella
Running the following ldapsearch returns a lots of entries for nsSSLEnabledCiphers, but
I do not see this values in dse.ldif , where are this values configured or read, please
nsldapsearch -LLLxD 'cn=directory manager' -W -b cn=encryption,cn=config -s base
nsSSL3Ciphers nsSSLSupportedCiphers nsSSLEnabledCiphers
Part of this could also be explained that not *every* config option is set in dse.ldif.
The way to think of it is that every possible config value is stored, and compiled into
the server as defaults. dse.ldif is your *overrides* to these values.
When you search cn=config you are seeing the compiled config values AND your overlayed
content of dse.ldif.
So that's why you see nsSSLEnabledCiphers in cn=config, but NOT in dse.ldif.
The reason - this means that as a project, we can update and ship changes to configuration
values (compiled into the server) that improve your server over time. And we really do
this, with things like changing from SHA1 to PBKDF2 for password hashes, or changing the
TLS ciphers. We do always strive to improve the baseline. It also lets us "back
out" changes if something goes wrong too (we have some feature enabling flags in
If we wrote every value into dse.ldif first, this is really daunting to new
administrators. Second most people will never need to adjust 90% of these values. And
third, shipping the values in dse.ldif means that old settings will persist on upgrades.
Given the life of a DS server is say ... 3 to 10 years? A lot changes in TLS or our own
database performance improvements. Just because you installed 3 years ago doesn't mean
you should be held back by that setting.
So as Mark said - TLS settings also interact with Fedora/RH crypto policy, so it's
best to adjust the system wide crypto settings. We default to respecting and following
that policy, and it's really what you should be changing in this case.
Hope that helps explain what's going on here.
Senior Software Engineer, 389 Directory Server