Would it be hard to make different listener addresses present different server certificates, signed by different CA certificates?
(I'm sure I've asked someone on that before, but don't remember if it was this list.)
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.
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.
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.
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.
--On Tuesday, April 29, 2008 2:57 PM -0700 Howard Chu hyc@symas.com wrote:
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.
Multiple addresses from different domains on a given interface come to mind, where the database is particularly large, so you don't want to have multiple slapd's taking up the resources. That way each address could be secured via SSL, but access the same DB with a single slapd. Say, for example, x.google.org and y.google.com.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, April 29, 2008 2:57 PM -0700 Howard Chuhyc@symas.com wrote:
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.
Multiple addresses from different domains on a given interface come to mind, where the database is particularly large, so you don't want to have multiple slapd's taking up the resources. That way each address could be secured via SSL, but access the same DB with a single slapd. Say, for example, x.google.org and y.google.com.
You can only have one listener per interface, so none of those considerations are relevant.
Again, if you're really serving multiple distinct security domains, then I don't see what data would be shared between them. It would be poor security practice to have them sharing anything.
This is the real question - why are you using server certs from different CAs? It seems Hallvard will have to answer that, since he posed the original question.
If it were just about mapping multiple DNS names to the same server, you wouldn't need to involve multiple CAs. You would just use a single cert, with multiple subjectAltNames. The use of different CAs means you have totally different administrative realms, different political authorities, and different policies. It is extremely unlikely that two different administrative bodies with different policies would jointly administer the same database.
-
Hallvard B Furuseth -
Howard Chu -
Quanah Gibson-Mount