On Thu, 2007-08-02 at 18:58 +1000, William Rose wrote:
> Hi Jeff,
> 
> As far as I understand it, at least a server certificate is required for 
> SSL.  The server certificate doesn't have to be issued by a known 
> authority (e.g. you can use a certificate you create, signed by itself), 
> but it has to be there.
> 
> This is required as the certificate gives the client the server's public 
> key, and  normally then the client gets to work out whether they trust 
> the certificate based on who signed it and whether they are trusted.  
> Once they work out they trust the cert (and therefore the public key), 
> they can use it to communicate securely with the server using public-key 
> cryptography.  This secure channel is used only to establish a shared 
> symmetric cipher key, and then the connection uses the faster symmetric 
> encryption to run the rest of the connection.
> 
> So to my knowledge, you can't cut out the certificate from the 
> protocol.  It's an essential step.  You can make it easier to work with 
> by not requiring a valid certificate, or, more commonly, setting up a 
> certificate authority of your own (not that hard with keytool) and 
> adding that certificate to your Java Runtime's cacerts file.  This means 
> the minimum amount of code changes.  If you don't want to fiddle with 
> files in the JRE/JDK, the alternative is writing custom trust validation 
> classes that will accept your own certificates.
> 
> cheers,
> 
> Will
> 

In the extreme case one can simply choose to trust any public
certificate regardless of their origin, authenticity and validity. This
can be accomplished by implementing a custom TrustManager that dumbly 
trusts anything

EasyX509TrustManager could be used as a starting point:

http://svn.apache.org/viewvc/jakarta/httpcomponents/oac.hc3x/trunk/src/contrib/org/apache/commons/httpclient/contrib/ssl/EasyX509TrustManager.java?view=markup

Oleg

> Jeff Garrett wrote:
> > Hi.
> > I have looked over most of the mail archives and found a couple of posts
> > that are kind of what I want to do, but were not quite in-line with my
> > project or did not do what I needed.  So, I need some help with something.
> >
> > I want to send an HTTPS Post message using SSL so that it is encrypted.  I
> > am currently using HttpClient 3.0.1 and that has worked like a charm for
> > sending HTTP Post messages without encryption.  But, now I need to do be
> > able to send encrypted messages too.  So, now I send to https://host:1001,
> > whereas before I was sending to http://host:1000, for example.
> >
> > The catch is, and this should make it easier, that I do NOT need to, nor
> > want to, use certificates for authentication.  I don't care who the receiver
> > of the message is - all I want is to send an encrypted message to a host and
> > port number I have stored.  I know this is not the most secure setup, but in
> > this scenario this is the only requirement - clients subscribe and are
> > stored, and I send an encrypted message to each client and move onto the
> > next task.  Its an asynchronus event that rarely happens.
> >
> > As I said, this should be easier than having to deal with certificates.
> > However, almost every online reference I found has certificates included and
> > I was unable to find a way to modify the examples and get them to work w/o
> > certificates.  I am not finding the right info, or not using the proper
> > info.  The SSL guide was helpful, but all of the implemented
> > classes resulted in some form of exception.
> >
> > This can be done right?  Can someone please provide some information for how
> > to go about doing this?
> >
> > I apologize if this is available somewhere - I have yet to see it.
> > Jeff G.
> >
> >   
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to