You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2006/05/12 16:13:00 UTC
Using the KeystoreManager for CORBA SSL support
I'm looking at implementing KeystoreManager support in the openejb CORBA
TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
best to do this. The KeystoreManager GBean merely manages access to the
keystores and the creating of SSLSocket factories for creating
connections (and currently, it only supports SSLServerSockets, but it's
a fairly trivial matter to add SSLSocketFactory support too). In order
to use the KeystoreManager to create a socket, the caller must provide a
number of additional pieces of information, such as the truststore and
keystore names, and the key alias. For example, here's the
configuration for the HTTPSConnector used to configure Jetty:
<gbean name="JettySSLConnector"
class="org.apache.geronimo.jetty.connector.HTTPSConnector">
<attribute name="host">${PlanServerHostname}</attribute>
<attribute name="port">${PlanHTTPSPort}</attribute>
<attribute name="keyStore">geronimo-default</attribute>
<attribute name="keyAlias">geronimo</attribute>
<attribute name="trustStore">geronimo-default</attribute>
<attribute name="clientAuthRequired">false</attribute>
<attribute name="algorithm">Default</attribute>
<attribute name="secureProtocol">TLS</attribute>
<attribute name="maxThreads">150</attribute>
<attribute name="minThreads">25</attribute>
<reference name="JettyContainer">
<name>JettyWebContainer</name>
</reference>
<reference name="KeystoreManager">
<name>KeystoreManager</name>
</reference>
</gbean>
In this case, the keyStore, keyAlias, trustStore, algorithm,
secureProtocol, and KeystoreManager values are all needed to create the
SSLServerSocketFactory instance that will be used to create the SSL
connection.
Now, to enable this support for CORBA, the two beans that create the ORB
instances (CORBABean and CSSBean) will need the same set of attributes
(and those attributes will need to be propagated to a couple of other
objects, which would start to get pretty messy). Alternatively, it
might make sense to have an SSLFactoryGBean, which is configured with
all of the attributes above, and which has methods for creating an
SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
configured socket factory. This seems to me like a simpler
implementation, allowing the two CORBA beans to just be initialized with
the SSLFactoryGBean instance. It might make sense to rework the
HTTPSConnector too to use the same pattern.
So, which model should be used here:
1) Current model employed with HTTPSConnector where all KeystoreManager
users expose/manage all of the attributes necessary to create SSL
connections using the KeystoreManager, or
2) Have an SSLFactory GBean where the SSL characteristics are
configured separately from the SSL consumer?
Rick
Re: Using the KeystoreManager for CORBA SSL support
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Well, I don't like it much for Jetty, since it seems to just split off
pertinent settings into another bean. If you're sure that CORBA will
have many objects with exactly the same settings, that's fine with me.
I'd have thought you would just set up one TSS and one CSS (which
would need different SSL factories even in your proposal) and point
all your CORBA users to one of those, but I haven't used CORBA in J2EE
in practice, so I'll defer to others on whether they're likely to have
a lot of overlap or not.
Thanks,
Aaron
On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
> Aaron Mulder wrote:
> > OK... I guess I'm just having trouble seeing what this would look
> > like. Can you show what the SSL configuration would look like for the
> > new GBean and the same Jetty SSL server if you use the scheme you're
> > proposing? (Or a CORBA component, if you're suggesting something that
> > would be applicable to CORBA only.)
> Ok, here's the currently Jetty config entry:
>
> <gbean name="JettySSLConnector"
> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
> <attribute name="host">${PlanServerHostname}</attribute>
> <attribute name="port">${PlanHTTPSPort}</attribute>
> <attribute name="keyStore">geronimo-default</attribute>
> <attribute name="keyAlias">geronimo</attribute>
> <attribute name="trustStore">geronimo-default</attribute>
> <attribute name="clientAuthRequired">false</attribute>
> <attribute name="algorithm">Default</attribute>
> <attribute name="secureProtocol">TLS</attribute>
> <attribute name="maxThreads">150</attribute>
> <attribute name="minThreads">25</attribute>
> <reference name="JettyContainer">
> <name>JettyWebContainer</name>
> </reference>
> <reference name="KeystoreManager">
> <name>KeystoreManager</name>
> </reference>
> </gbean>
>
> My proposed new structure:
>
> <gbean name="JettySSLFactory"
> class="org.apache.geronimo.security.SSLFactoryGBean">
> <attribute name="keyStore">geronimo-default</attribute>
> <attribute name="keyAlias">geronimo</attribute>
> <attribute name="trustStore">geronimo-default</attribute>
> <attribute name="algorithm">Default</attribute>
> <attribute name="protocol">TLS</attribute>
> <reference name="KeystoreManager">
> <name>KeystoreManager</name>
> </reference>
> </gbean>
>
> <gbean name="JettySSLConnector"
> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
> <attribute name="host">${PlanServerHostname}</attribute>
> <attribute name="port">${PlanHTTPSPort}</attribute>
> <attribute name="clientAuthRequired">false</attribute>
> <reference name="JettyContainer">
> <name>JettyWebContainer</name>
> </reference>
> <reference name="JettySSLFactory">
> <name>JettySSLFactory</name>
> </reference>
> </gbean>
>
>
> This is probably less of an issue for the Jetty config, but it is very
> likely that the various CORBA beans will share a common configuration,
> so it makes sense to specify that part of the configuration in just one
> place and reference it in multiple places.
>
> The SSLFactoryGBean will also implement an interface for retrieving the
> socket factories, again to centralize the common logic involved.
>
> Rick
>
>
> >
> > Thanks,
> > Aaron
> >
> > On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
> >> I wasn't proposing having a single GBean instance to hold all of the
> >> information, but a common GBean class that is used to configure things
> >> and centralize the information/use of the information. For example, the
> >> CSSBean and CORBABean classes use a common config adaptor that
> >> encapsulates a number of the ORB implementation specifics from the
> >> instantiating code. This config adapator will need the SSL connector to
> >> set up the ORB socket factory. This task becomes a lot simpler if there
> >> is a single class that carries the information and can be used to
> >> retrieve the appropriate socket factories. These classes can even
> >> encapsulate the default fallback logic for when there is no explicit
> >> store configured.
> >>
> >>
> >> > For example, the client needs
> >> > no keystore if it's not using client auth, and needs a separate
> >> > keystore if it is. The protocol and algorithm can probably be
> >> > configured at the JVM level -- I'm not sure about the rest. It's
> >> > plausible that you might want two different SSL connectors with
> >> > different key/trust/client auth settings, one for internal clients and
> >> > one for external clients.
> >> >
> >> > Thanks,
> >> > Aaron
> >> >
> >> > On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
> >> >> I'm looking at implementing KeystoreManager support in the openejb
> >> CORBA
> >> >> TLS layer (see Jira GERONIMO-2002), and I'm having trouble
> >> deciding how
> >> >> best to do this. The KeystoreManager GBean merely manages access
> >> to the
> >> >> keystores and the creating of SSLSocket factories for creating
> >> >> connections (and currently, it only supports SSLServerSockets, but
> >> it's
> >> >> a fairly trivial matter to add SSLSocketFactory support too). In
> >> order
> >> >> to use the KeystoreManager to create a socket, the caller must
> >> provide a
> >> >> number of additional pieces of information, such as the truststore
> >> and
> >> >> keystore names, and the key alias. For example, here's the
> >> >> configuration for the HTTPSConnector used to configure Jetty:
> >> >>
> >> >> <gbean name="JettySSLConnector"
> >> >> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
> >> >> <attribute name="host">${PlanServerHostname}</attribute>
> >> >> <attribute name="port">${PlanHTTPSPort}</attribute>
> >> >> <attribute name="keyStore">geronimo-default</attribute>
> >> >> <attribute name="keyAlias">geronimo</attribute>
> >> >> <attribute name="trustStore">geronimo-default</attribute>
> >> >> <attribute name="clientAuthRequired">false</attribute>
> >> >> <attribute name="algorithm">Default</attribute>
> >> >> <attribute name="secureProtocol">TLS</attribute>
> >> >> <attribute name="maxThreads">150</attribute>
> >> >> <attribute name="minThreads">25</attribute>
> >> >> <reference name="JettyContainer">
> >> >> <name>JettyWebContainer</name>
> >> >> </reference>
> >> >> <reference name="KeystoreManager">
> >> >> <name>KeystoreManager</name>
> >> >> </reference>
> >> >> </gbean>
> >> >>
> >> >> In this case, the keyStore, keyAlias, trustStore, algorithm,
> >> >> secureProtocol, and KeystoreManager values are all needed to
> >> create the
> >> >> SSLServerSocketFactory instance that will be used to create the SSL
> >> >> connection.
> >> >>
> >> >> Now, to enable this support for CORBA, the two beans that create
> >> the ORB
> >> >> instances (CORBABean and CSSBean) will need the same set of
> >> attributes
> >> >> (and those attributes will need to be propagated to a couple of other
> >> >> objects, which would start to get pretty messy). Alternatively, it
> >> >> might make sense to have an SSLFactoryGBean, which is configured with
> >> >> all of the attributes above, and which has methods for creating an
> >> >> SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
> >> >> configured socket factory. This seems to me like a simpler
> >> >> implementation, allowing the two CORBA beans to just be
> >> initialized with
> >> >> the SSLFactoryGBean instance. It might make sense to rework the
> >> >> HTTPSConnector too to use the same pattern.
> >> >>
> >> >> So, which model should be used here:
> >> >>
> >> >> 1) Current model employed with HTTPSConnector where all
> >> KeystoreManager
> >> >> users expose/manage all of the attributes necessary to create SSL
> >> >> connections using the KeystoreManager, or
> >> >>
> >> >> 2) Have an SSLFactory GBean where the SSL characteristics are
> >> >> configured separately from the SSL consumer?
> >> >>
> >> >> Rick
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
Re: Using the KeystoreManager for CORBA SSL support
Posted by Rick McGuire <ri...@gmail.com>.
Aaron Mulder wrote:
> OK... I guess I'm just having trouble seeing what this would look
> like. Can you show what the SSL configuration would look like for the
> new GBean and the same Jetty SSL server if you use the scheme you're
> proposing? (Or a CORBA component, if you're suggesting something that
> would be applicable to CORBA only.)
Ok, here's the currently Jetty config entry:
<gbean name="JettySSLConnector"
class="org.apache.geronimo.jetty.connector.HTTPSConnector">
<attribute name="host">${PlanServerHostname}</attribute>
<attribute name="port">${PlanHTTPSPort}</attribute>
<attribute name="keyStore">geronimo-default</attribute>
<attribute name="keyAlias">geronimo</attribute>
<attribute name="trustStore">geronimo-default</attribute>
<attribute name="clientAuthRequired">false</attribute>
<attribute name="algorithm">Default</attribute>
<attribute name="secureProtocol">TLS</attribute>
<attribute name="maxThreads">150</attribute>
<attribute name="minThreads">25</attribute>
<reference name="JettyContainer">
<name>JettyWebContainer</name>
</reference>
<reference name="KeystoreManager">
<name>KeystoreManager</name>
</reference>
</gbean>
My proposed new structure:
<gbean name="JettySSLFactory"
class="org.apache.geronimo.security.SSLFactoryGBean">
<attribute name="keyStore">geronimo-default</attribute>
<attribute name="keyAlias">geronimo</attribute>
<attribute name="trustStore">geronimo-default</attribute>
<attribute name="algorithm">Default</attribute>
<attribute name="protocol">TLS</attribute>
<reference name="KeystoreManager">
<name>KeystoreManager</name>
</reference>
</gbean>
<gbean name="JettySSLConnector"
class="org.apache.geronimo.jetty.connector.HTTPSConnector">
<attribute name="host">${PlanServerHostname}</attribute>
<attribute name="port">${PlanHTTPSPort}</attribute>
<attribute name="clientAuthRequired">false</attribute>
<reference name="JettyContainer">
<name>JettyWebContainer</name>
</reference>
<reference name="JettySSLFactory">
<name>JettySSLFactory</name>
</reference>
</gbean>
This is probably less of an issue for the Jetty config, but it is very
likely that the various CORBA beans will share a common configuration,
so it makes sense to specify that part of the configuration in just one
place and reference it in multiple places.
The SSLFactoryGBean will also implement an interface for retrieving the
socket factories, again to centralize the common logic involved.
Rick
>
> Thanks,
> Aaron
>
> On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
>> I wasn't proposing having a single GBean instance to hold all of the
>> information, but a common GBean class that is used to configure things
>> and centralize the information/use of the information. For example, the
>> CSSBean and CORBABean classes use a common config adaptor that
>> encapsulates a number of the ORB implementation specifics from the
>> instantiating code. This config adapator will need the SSL connector to
>> set up the ORB socket factory. This task becomes a lot simpler if there
>> is a single class that carries the information and can be used to
>> retrieve the appropriate socket factories. These classes can even
>> encapsulate the default fallback logic for when there is no explicit
>> store configured.
>>
>>
>> > For example, the client needs
>> > no keystore if it's not using client auth, and needs a separate
>> > keystore if it is. The protocol and algorithm can probably be
>> > configured at the JVM level -- I'm not sure about the rest. It's
>> > plausible that you might want two different SSL connectors with
>> > different key/trust/client auth settings, one for internal clients and
>> > one for external clients.
>> >
>> > Thanks,
>> > Aaron
>> >
>> > On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
>> >> I'm looking at implementing KeystoreManager support in the openejb
>> CORBA
>> >> TLS layer (see Jira GERONIMO-2002), and I'm having trouble
>> deciding how
>> >> best to do this. The KeystoreManager GBean merely manages access
>> to the
>> >> keystores and the creating of SSLSocket factories for creating
>> >> connections (and currently, it only supports SSLServerSockets, but
>> it's
>> >> a fairly trivial matter to add SSLSocketFactory support too). In
>> order
>> >> to use the KeystoreManager to create a socket, the caller must
>> provide a
>> >> number of additional pieces of information, such as the truststore
>> and
>> >> keystore names, and the key alias. For example, here's the
>> >> configuration for the HTTPSConnector used to configure Jetty:
>> >>
>> >> <gbean name="JettySSLConnector"
>> >> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
>> >> <attribute name="host">${PlanServerHostname}</attribute>
>> >> <attribute name="port">${PlanHTTPSPort}</attribute>
>> >> <attribute name="keyStore">geronimo-default</attribute>
>> >> <attribute name="keyAlias">geronimo</attribute>
>> >> <attribute name="trustStore">geronimo-default</attribute>
>> >> <attribute name="clientAuthRequired">false</attribute>
>> >> <attribute name="algorithm">Default</attribute>
>> >> <attribute name="secureProtocol">TLS</attribute>
>> >> <attribute name="maxThreads">150</attribute>
>> >> <attribute name="minThreads">25</attribute>
>> >> <reference name="JettyContainer">
>> >> <name>JettyWebContainer</name>
>> >> </reference>
>> >> <reference name="KeystoreManager">
>> >> <name>KeystoreManager</name>
>> >> </reference>
>> >> </gbean>
>> >>
>> >> In this case, the keyStore, keyAlias, trustStore, algorithm,
>> >> secureProtocol, and KeystoreManager values are all needed to
>> create the
>> >> SSLServerSocketFactory instance that will be used to create the SSL
>> >> connection.
>> >>
>> >> Now, to enable this support for CORBA, the two beans that create
>> the ORB
>> >> instances (CORBABean and CSSBean) will need the same set of
>> attributes
>> >> (and those attributes will need to be propagated to a couple of other
>> >> objects, which would start to get pretty messy). Alternatively, it
>> >> might make sense to have an SSLFactoryGBean, which is configured with
>> >> all of the attributes above, and which has methods for creating an
>> >> SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
>> >> configured socket factory. This seems to me like a simpler
>> >> implementation, allowing the two CORBA beans to just be
>> initialized with
>> >> the SSLFactoryGBean instance. It might make sense to rework the
>> >> HTTPSConnector too to use the same pattern.
>> >>
>> >> So, which model should be used here:
>> >>
>> >> 1) Current model employed with HTTPSConnector where all
>> KeystoreManager
>> >> users expose/manage all of the attributes necessary to create SSL
>> >> connections using the KeystoreManager, or
>> >>
>> >> 2) Have an SSLFactory GBean where the SSL characteristics are
>> >> configured separately from the SSL consumer?
>> >>
>> >> Rick
>> >>
>> >>
>> >
>>
>>
>
Re: Using the KeystoreManager for CORBA SSL support
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
OK... I guess I'm just having trouble seeing what this would look
like. Can you show what the SSL configuration would look like for the
new GBean and the same Jetty SSL server if you use the scheme you're
proposing? (Or a CORBA component, if you're suggesting something that
would be applicable to CORBA only.)
Thanks,
Aaron
On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
> I wasn't proposing having a single GBean instance to hold all of the
> information, but a common GBean class that is used to configure things
> and centralize the information/use of the information. For example, the
> CSSBean and CORBABean classes use a common config adaptor that
> encapsulates a number of the ORB implementation specifics from the
> instantiating code. This config adapator will need the SSL connector to
> set up the ORB socket factory. This task becomes a lot simpler if there
> is a single class that carries the information and can be used to
> retrieve the appropriate socket factories. These classes can even
> encapsulate the default fallback logic for when there is no explicit
> store configured.
>
>
> > For example, the client needs
> > no keystore if it's not using client auth, and needs a separate
> > keystore if it is. The protocol and algorithm can probably be
> > configured at the JVM level -- I'm not sure about the rest. It's
> > plausible that you might want two different SSL connectors with
> > different key/trust/client auth settings, one for internal clients and
> > one for external clients.
> >
> > Thanks,
> > Aaron
> >
> > On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
> >> I'm looking at implementing KeystoreManager support in the openejb CORBA
> >> TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
> >> best to do this. The KeystoreManager GBean merely manages access to the
> >> keystores and the creating of SSLSocket factories for creating
> >> connections (and currently, it only supports SSLServerSockets, but it's
> >> a fairly trivial matter to add SSLSocketFactory support too). In order
> >> to use the KeystoreManager to create a socket, the caller must provide a
> >> number of additional pieces of information, such as the truststore and
> >> keystore names, and the key alias. For example, here's the
> >> configuration for the HTTPSConnector used to configure Jetty:
> >>
> >> <gbean name="JettySSLConnector"
> >> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
> >> <attribute name="host">${PlanServerHostname}</attribute>
> >> <attribute name="port">${PlanHTTPSPort}</attribute>
> >> <attribute name="keyStore">geronimo-default</attribute>
> >> <attribute name="keyAlias">geronimo</attribute>
> >> <attribute name="trustStore">geronimo-default</attribute>
> >> <attribute name="clientAuthRequired">false</attribute>
> >> <attribute name="algorithm">Default</attribute>
> >> <attribute name="secureProtocol">TLS</attribute>
> >> <attribute name="maxThreads">150</attribute>
> >> <attribute name="minThreads">25</attribute>
> >> <reference name="JettyContainer">
> >> <name>JettyWebContainer</name>
> >> </reference>
> >> <reference name="KeystoreManager">
> >> <name>KeystoreManager</name>
> >> </reference>
> >> </gbean>
> >>
> >> In this case, the keyStore, keyAlias, trustStore, algorithm,
> >> secureProtocol, and KeystoreManager values are all needed to create the
> >> SSLServerSocketFactory instance that will be used to create the SSL
> >> connection.
> >>
> >> Now, to enable this support for CORBA, the two beans that create the ORB
> >> instances (CORBABean and CSSBean) will need the same set of attributes
> >> (and those attributes will need to be propagated to a couple of other
> >> objects, which would start to get pretty messy). Alternatively, it
> >> might make sense to have an SSLFactoryGBean, which is configured with
> >> all of the attributes above, and which has methods for creating an
> >> SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
> >> configured socket factory. This seems to me like a simpler
> >> implementation, allowing the two CORBA beans to just be initialized with
> >> the SSLFactoryGBean instance. It might make sense to rework the
> >> HTTPSConnector too to use the same pattern.
> >>
> >> So, which model should be used here:
> >>
> >> 1) Current model employed with HTTPSConnector where all KeystoreManager
> >> users expose/manage all of the attributes necessary to create SSL
> >> connections using the KeystoreManager, or
> >>
> >> 2) Have an SSLFactory GBean where the SSL characteristics are
> >> configured separately from the SSL consumer?
> >>
> >> Rick
> >>
> >>
> >
>
>
Re: Using the KeystoreManager for CORBA SSL support
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
You can't have a single GBean hold all that information and make it
the same for every SSL client/server. For example, the client needs
no keystore if it's not using client auth, and needs a separate
keystore if it is. The protocol and algorithm can probably be
configured at the JVM level -- I'm not sure about the rest. It's
plausible that you might want two different SSL connectors with
different key/trust/client auth settings, one for internal clients and
one for external clients.
Thanks,
Aaron
On 5/12/06, Rick McGuire <ri...@gmail.com> wrote:
> I'm looking at implementing KeystoreManager support in the openejb CORBA
> TLS layer (see Jira GERONIMO-2002), and I'm having trouble deciding how
> best to do this. The KeystoreManager GBean merely manages access to the
> keystores and the creating of SSLSocket factories for creating
> connections (and currently, it only supports SSLServerSockets, but it's
> a fairly trivial matter to add SSLSocketFactory support too). In order
> to use the KeystoreManager to create a socket, the caller must provide a
> number of additional pieces of information, such as the truststore and
> keystore names, and the key alias. For example, here's the
> configuration for the HTTPSConnector used to configure Jetty:
>
> <gbean name="JettySSLConnector"
> class="org.apache.geronimo.jetty.connector.HTTPSConnector">
> <attribute name="host">${PlanServerHostname}</attribute>
> <attribute name="port">${PlanHTTPSPort}</attribute>
> <attribute name="keyStore">geronimo-default</attribute>
> <attribute name="keyAlias">geronimo</attribute>
> <attribute name="trustStore">geronimo-default</attribute>
> <attribute name="clientAuthRequired">false</attribute>
> <attribute name="algorithm">Default</attribute>
> <attribute name="secureProtocol">TLS</attribute>
> <attribute name="maxThreads">150</attribute>
> <attribute name="minThreads">25</attribute>
> <reference name="JettyContainer">
> <name>JettyWebContainer</name>
> </reference>
> <reference name="KeystoreManager">
> <name>KeystoreManager</name>
> </reference>
> </gbean>
>
> In this case, the keyStore, keyAlias, trustStore, algorithm,
> secureProtocol, and KeystoreManager values are all needed to create the
> SSLServerSocketFactory instance that will be used to create the SSL
> connection.
>
> Now, to enable this support for CORBA, the two beans that create the ORB
> instances (CORBABean and CSSBean) will need the same set of attributes
> (and those attributes will need to be propagated to a couple of other
> objects, which would start to get pretty messy). Alternatively, it
> might make sense to have an SSLFactoryGBean, which is configured with
> all of the attributes above, and which has methods for creating an
> SSLSocket and a SSLServerSocket, and/or retrieving an appropriately
> configured socket factory. This seems to me like a simpler
> implementation, allowing the two CORBA beans to just be initialized with
> the SSLFactoryGBean instance. It might make sense to rework the
> HTTPSConnector too to use the same pattern.
>
> So, which model should be used here:
>
> 1) Current model employed with HTTPSConnector where all KeystoreManager
> users expose/manage all of the attributes necessary to create SSL
> connections using the KeystoreManager, or
>
> 2) Have an SSLFactory GBean where the SSL characteristics are
> configured separately from the SSL consumer?
>
> Rick
>
>