Bug 840403 - (PRODMGT-454) the plugin for JBoss EAP 6 / AS 7 needs to support SSL/TLS encryption and authentication [INPUT NEEDED]

Thomas Segismont tsegismo at redhat.com
Tue Jan 28 17:43:11 UTC 2014


Hi Larry,

Le 24/01/2014 21:13, Larry O'Leary a écrit :
> Great work Thomas! See my response inline.

Thanks

>
> On Wed, 2014-01-22 at 18:47 +0100, Thomas Segismont wrote:
>> >Hi,
>> >
>> >I've just pushed the initial implementation for Bug 840403 in a topic
>> >branch:
>> >https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=bug/840403&id=3e7174e16ac754122b459f21de7d56a8c0c67f97
>> >...
>> >* Only valid certificates or self-signed certificates (certificate chain
>> >size is 1) are supported now
> Why this limitation? Is this because the CA or public key is not yet
> trusted by the agent's JVM?
>

No, this commit was just the initial implementation, I pushed more 
changes since and squashed the commits. The full implementation is here:

https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=bug/840403&id=81be8c6fe46251916f24886e1ffa3c8465fab241

>> >
>> >AS7 plugin must be able to work with self-signed certificates and
>> >unknown certificate authorities (internal or not common). It also needs
>> >to be able to find a key store for client cert authentication.
>> >
>> >I think Standalone and Domain server plugin configurations should let
>> >users define a key and a trust store for maximum customization.
> Yes. I agree. The connection settings should provide the ability to
> specify the location of the key and trust store files and what level of
> enforcement is required (host name validation, CRL, encryption only w/
> no authentication/validation, etc).

All these switches except CRL are implemented. CRL is not supported in 
AS7/EAP6 as far as I know.

>
> Additionally, without any resource specific connection settings the JVMs
> global/default settings should be used. Thus allowing all certificates
> to be managed/provided via the JVM's settings and to be overridden by
> resource specific connection settings.
>

Yes, that's how it is implemented.

>> >I believe that, by default, self-signed certificates and unknown
>> >certificate authorities should not be trusted.
> Assuming that the certificate trust has not been installed, I would
> agree. However, if the public key for a self-signed certificate has been
> installed in the certificate trust, it should be considered trusted.

Yes, that's how it is implemented.

Regards,
Thomas


More information about the rhq-devel mailing list