tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Moley Harey <moleyha...@gmail.com>
Subject Re: Usage of Tomcat SSL in client-side class
Date Wed, 17 Nov 2010 08:35:17 GMT
Thanks André, I have been checking Apache Http Commons API for connecting
through HTTPS in my client-side classes and it seems that protocol is
supported well.

My doubt regarding if I had to do anything special in the client side was
related to the certificate, I have a self generated certificate using JSSE
keystore tool and I had read that those kind of certificates must be
accepted explicitly by the client (the same that browsers do), therefore I
was wondering how can I do that in my client to accept that automatically...

2010/11/16 André Warnier <aw@ice-sa.com>

> Moley Harey wrote:
>
>> Hello folks,
>>
>> I have a set of web services installed in Tomcat 6.0.26 that I would like
>> to
>> access using HTTPs, I have following the instructions in Tomcat web side
>> to
>> set up JSSE support and now I can access the web services using SSH.
>>
>> My question is what do I have to do in my Java client-side classes to work
>> with HTTPs requests from Tomcat? Do I have to accept somehow the
>> certificate
>> provided by Tomcat in my Java classes? Well, I'm totally newbie in these
>> security issues :-/
>>
>>
> Only because you mention that you are a total newbie, and because I am
> myself not far above that level, some beginning pointers :
>
> It helps to give things their correct name (or acronym), so as to be able
> to find the correct documentation and understand their relationship.
> SSL is "Secure Socket Layer". (Google : SSL RFC)
> SSH is an acronym for "Secure Shell" (Google : SSH RFC)
> HTTP is an acronym for "HyperText Transport Protocol". (Google : HTTP RFC)
> HTTPS (with a big S) is an acronym for "HTTP over SSL". (Google : HTTPS
> RFC)
>
> So you are not accessing the web services over SSH, you are accessing your
> web services over HTTPS, which itself "lives" above an SSL connection, which
> itself lives above a TCP connection, which itself lives above an IP link
> (which itself lives over an Ethernet link (probably) etc..).
>
> And on top of it all, you have the application (both at the client side,
> and at the server side).
>
> Schematically :
>
> Client application                            Server application
> Client "container" (?) (e.g. a JVM)           Server container (e.g. JVM +
> Tomcat)
> Client O.S.                                   Server OS
> Client SSL layer (optional)                   Server SSL layer (optional)
> Client OS TCP/IP layer                        Server OS TCP/IP layer
> Client-side Ethernet layer                    Server-side Ethernet layer
> Client-side hardware layer <-------------->   Server-side hardware layer
>
> When the client side application sends something to the server-side
> application, whatever data is sent goes through all the layers on the client
> side, then over the physical connection, then through all the layers on the
> server side up to the server application.
> The encryption/decryption, if any, takes place at the SSL layer level,
> automatically.
>
> So basically, to answer our question, you do not /have/ to do something
> special at the application level.  The container and the OS take care of the
> interface, so that your application can just use the standard "read" and
> "write" and "open" and "close" and request.getParameters() calls, no matter
> if the connection uses an SSL layer or not.
>
> But you /can/ make use of some of the SSL-specific things, if you want.
> For example, the server-side application setup /could/ tell the container
> that it will only accept requests that come over a secure channel, and only
> if they come from a client identified as "X" or "Y".
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message