Glen,

It's not arbitrary because there is a fundamental difference between
SSL and WS-Security: the SSL handshake allows the client to get the
server's certificate before sending the request. This is not the case
for WS-Security.

Andreas

On Fri, Jun 5, 2009 at 15:36, Glen Mazza <[email protected]> wrote:
>
> Thanks for your response and clarification, I wasn't clear of the
> consequences of adding the certificate authority alone.
>
> I guess with a Java keystore, if I trust a certificate authority I would
> automatically be able to initiate an SSL conversation with any server that
> has a certificate issued by that authority. (Although, as you're saying,
> without the WS-Security encryption, for which I would still need to
> explicitly trust the individual public key of the server to do the
> encrypting.) I think that's how web browsers work--I trust VeriSign so I can
> make a SSL connection to https://www.mylocalbank.com which uses a VeriSign
> cert.  Still, I'm not sure why I wouldn't need to explicitly trust the
> individual server's key for transport-layer (https) encryption but still
> need to do so for message-layer (WS-Security) encryption--seems arbitrary,
> probably something worth testing to confirm.
>
> Regardless, I don't think I need to have the client trust the server's
> parent chain of certificates--I'll just stick with the client trusting the
> individual server key only.
>
> Thanks,
> Glen
>
>
> DSosnoski wrote:
>>
>> To clarify my response - just adding the certificate authority works for
>> making SSL connections, and should also work for WS-Security signing if
>> configured properly, but in order to use WS-Security encryption inbound
>> to the server you'd still need to add the individual certificate for
>> that server.
>>
>>   - Dennis
>>
>>
>> Dennis Sosnoski wrote:
>>> Hi Glen,
>>>
>>> It really depends on what you want to do. If the server is just using
>>> a self-signed key there's no actual chain involved, so this issue only
>>> arises when the server is using a certificate issued by a private
>>> certificate authority (since if they're using one of the "official"
>>> public authorities the signing certificate will already be trusted).
>>> Do you want to be able to work with all services using certificates
>>> issued by this authority? If so, then you're best off just importing
>>> the authority's signing certificate. Otherwise there's no benefit, and
>>> you're best off just importing the specific certificate for that service.
>>>
>>> This issue more often comes up when a service needs to work with
>>> client certificates which are issued by a private certificate
>>> authority. A private certificate authority is a great approach for
>>> when you have a lot of separate client systems needing to access
>>> services, since it gives you the added security of client certificates
>>> without the cost of paying for each certificate.
>>>
>>>  - Dennis
>>>
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Trusting-entire-certificate-chain--tp23873642p23888323.html
> Sent from the Axis - User mailing list archive at Nabble.com.
>
>

Reply via email to