Hallvard B Furuseth wrote:
Howard Chu writes:
Hallvard B Furuseth wrote:
Would it be hard to make different listener addresses present different server certificates, signed by different CA certificates?
Not that hard. The worst part would be defining the new config syntax for it and adding the appropriate config actions.
Maybe something like:
dn: cn={n}override,cn=config olcOverrideBy:<"*" or socket-related<who> fields from olcAccess>
<same attributes as in cn=config entry>
slapd would search each override for the first which matches the connection. Attributes not found there would be taken from the cn=config entry. The attributes would need to accept some value which means "don't use the cn=config default for this attribute".
Over time it could be generalized to cover other config parameters like limits, and maybe other<by> clauses too.
Hm, that sounds like a lot of work, and a bit too indirect. If the only necessary selection criteria is the listener, then that should be used explicitly. One thing that we've often talked about is why the listener isn't part of the config data, instead of only supplied on the command-line...
I'm also skeptical about the motivation for this discussion. If you have separate certs from separate CAs, then you really have distinct security domains so I don't understand why you need them to share databases. You might as well just run separate slapds.
I don't understand the tls-config code itself though. It configures a fake LDAP*, slap_tls_ld, so I presume the TLS config isn't global. That's good news - except I don't see where the slap_tls_ld settings are applied to a connection.
Well, slap_tls_ld is a global var of course. To handle this appropriately, we'd move the slap_tls_ld/slap_tls_ctx stuff into the Listener structure.