In HTTP, when you use SSL through a proxy, you typically use a "proxy tunnel". The HTTP client connects to the proxy, plain text, and tells the proxy to establish a tunnel to the destination server. Once this tunnel is established, anything it sends/receives will be forwarded directly to the destination server -- so it then starts the SSL handshake and encryption, directly with the final server.

For this reason, it's not necessary to have separate SSL communication with the proxy itself (vs. the destination server) and so there's no need for certificate "replacement".

I'm not familiar with httpclient, and I don't know if JT400 has support for using proxy tunnels...? So it's possible that this info doesn't apply to you.

On 1/20/2015 12:00 PM, David Gibbs wrote:

I'm trying to get some information to see if I need to make a code
change ... it relates to SSL certificate replacement on a proxy server.

I have a thick client application that runs on customers desktops ... it
communicates both to the i, using JT400, and the web (using the apache
httpclient library) with SSL.

We released the software a short time ago and already have a customer
that encountered a problem with the SSL connection. Turns out their
proxy (bluecoat) was replacing the SSL certificate that our web site
presented with their own, self signed, certificate.

For the web browser that's not a problem ... the company established a
policy that said the self signed certificate was trusted, so the chain
was valid.

For our application, however, the self signed certificate wasn't trusted
and it generated an error.

So my question is this: How prevalent is the SSL certificate replacement
by proxys? Is this something we're going to encounter a lot ... or is
this a fringe case?



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.