You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Jake C <bu...@hotmail.com> on 2006/12/01 04:08:34 UTC
Certificateless SSL
I am a complete SSL noob, so please pardon me if my questions are silly...
:-) I've seen similar questions in the archive, but nothing that really
spelled it out.
We need an encrypted connection to a 3-rd party application, but we don't
need validation. The data being transmitted is validation enough for us.
However, the application we are sending to (running on Windows under IIS) is
requiring a certificate.
I know it is possible to use SSL without requiring a certificate, as the
test application at the bottom of the HttpClient SSL Guide works for
Verisign, but not for our application.
I see two possible ways of getting around this, and I'd just like some
validation that these would work the way I want (not requiring our users to
mess with certificates).
1) Use an Authenticating Proxy Server. We should be able to set up one of
these that accepts SSL connections without requiring a certificate, and
configure the connection between it and our 3-rd party application using a
certificate just for the proxy server, and not for each individual client.
2) Modify the IIS configuration of our 3-rd party application so that it
doesn't require client certificates, as the data being sent contains the
real authentication information. I"m not sure this is really an option, as I
don't know IIS at all. We DO have access to the server, though.
Do both of these methods work, and encrypt our data? If so, is the
encryption in the second case just as strong as if we used client
certificates, or is it weaker because there is only a server certificate? Is
there any other method I missed?
The application we are accessing initially provides a login page, and we
just provide a MethodPost with the needed data, so the SSL Connection itself
isn't initially authenticated. What I don't really understand is how a
generic web browser certificate is any better than no certificate at all.
Why is a personal certificate required via HttpClient and not via a web
browser?
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: https now works, but http doesnt?!?!
Posted by Jake C <bu...@hotmail.com>.
OK, everything works again!
For some reason, the web server on the http server wasn't forwarding
"/<application>/" to "/application/login.aspx" for HttpClient any more, but
was for IE. It worked fine on the https server. However, when I add
"login.aspx" to the URI, it works in both cases.
Thanks again for all the help!
>From: "Julius Davies" <ju...@gmail.com>
>Reply-To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>Subject: Re: https now works, but http doesnt?!?!
>Date: Sat, 2 Dec 2006 13:38:26 -0500
>
>Hi, Jake,
>
>Sounds frustrating!
>
>On 12/2/06, Jake C <bu...@hotmail.com> wrote:
>>I tried all of that.
>>
>>I call "client.setState(new HttpState());" before my transactions and
>>removed the synchronized blocks.
>>
>>I checked the forms I'm posting to on both servers, and they are identical
>>except for the __VIEWSTATE value.
>>
>
>You checked the HTML forms? Are they are both using "method=POST" ?
>And so in HttpClient you're creating the
>"application/x-www-form-urlencoded" RequestEntity and adding it to
>your PostMethod.
>
>
>>I print out the URI and the parameters I'm adding. If I paste the URI into
>>the web browser then add the parameters manually
>>(<URI>?<Name1>=<Value1>&<Name2>=<Value2>&...) it works just fine!
>>
>
>When you do that (paste a URI into a browser) then you're doing a GET
>request, not a POST request. You have to actually click on the
>"submit" button of a method=POST form do actually do a post.
>
>
>>I printed out the Headers:
>>header[0]:User-Agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
>>SV1;
>>.NET CLR 1.1.4322)
>>header[1]:Host=<host>:8080
>>header[2]:Content-Length=110
>>header[3]:Content-Type=application/x-www-form-urlencoded
>>
>
>Are these the headers your browser sent? Or that HttpClient sent?
>
>
>>The content length is exactly the right length for all my parameters and
>>values, with a = between the name and value, and an & between each pair.
>>
>>The Method is a PostMethod, and my URI is correct. What the heck is going
>>on? Is there another level of debugging I can turn on to help track this
>>down?
>>
>>This is EXTREMELY frustrating! Why should it work for https and not for
>>http? What could possible be the difference between the two?
>>
>>Here is the rest of the information I'm printing out:
>>method=org.apache.commons.httpclient.methods.PostMethod
>>URI=http://<host>:8080/<app>/
>>path=/<app>/
>>query=null
>>reason=Method not allowed
>>status=405, Method not allowed
>>location=null
>>contentType=Content-Type: text/html
>>
>>All of this is identical for the https situation except for the URI, which
>>says https and has no port specified.
>
>
>Yeah, that doesn't make sense. Another angle to try and learn more
>information is to try "telnetting" to your HTTP server and just typing
>in the headers and content manually:
>
>telnet <host> 8080
>------------------------------------------
>POST /<app>/ HTTP/1.1
>host: <host>
>content-length=7
>content-type=application/x-www-form-urlencoded
>
>x=1&y=2
>
>------------------------------------------
>
>
>--
>yours,
>
>Julius Davies
>416-652-0183
>http://juliusdavies.ca/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
_________________________________________________________________
All-in-one security and maintenance for your PC. Get a free 90-day trial!
http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo0050000001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: https now works, but http doesnt?!?!
Posted by Julius Davies <ju...@gmail.com>.
Hi, Jake,
Sounds frustrating!
On 12/2/06, Jake C <bu...@hotmail.com> wrote:
> I tried all of that.
>
> I call "client.setState(new HttpState());" before my transactions and
> removed the synchronized blocks.
>
> I checked the forms I'm posting to on both servers, and they are identical
> except for the __VIEWSTATE value.
>
You checked the HTML forms? Are they are both using "method=POST" ?
And so in HttpClient you're creating the
"application/x-www-form-urlencoded" RequestEntity and adding it to
your PostMethod.
> I print out the URI and the parameters I'm adding. If I paste the URI into
> the web browser then add the parameters manually
> (<URI>?<Name1>=<Value1>&<Name2>=<Value2>&...) it works just fine!
>
When you do that (paste a URI into a browser) then you're doing a GET
request, not a POST request. You have to actually click on the
"submit" button of a method=POST form do actually do a post.
> I printed out the Headers:
> header[0]:User-Agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
> .NET CLR 1.1.4322)
> header[1]:Host=<host>:8080
> header[2]:Content-Length=110
> header[3]:Content-Type=application/x-www-form-urlencoded
>
Are these the headers your browser sent? Or that HttpClient sent?
> The content length is exactly the right length for all my parameters and
> values, with a = between the name and value, and an & between each pair.
>
> The Method is a PostMethod, and my URI is correct. What the heck is going
> on? Is there another level of debugging I can turn on to help track this
> down?
>
> This is EXTREMELY frustrating! Why should it work for https and not for
> http? What could possible be the difference between the two?
>
> Here is the rest of the information I'm printing out:
> method=org.apache.commons.httpclient.methods.PostMethod
> URI=http://<host>:8080/<app>/
> path=/<app>/
> query=null
> reason=Method not allowed
> status=405, Method not allowed
> location=null
> contentType=Content-Type: text/html
>
> All of this is identical for the https situation except for the URI, which
> says https and has no port specified.
Yeah, that doesn't make sense. Another angle to try and learn more
information is to try "telnetting" to your HTTP server and just typing
in the headers and content manually:
telnet <host> 8080
------------------------------------------
POST /<app>/ HTTP/1.1
host: <host>
content-length=7
content-type=application/x-www-form-urlencoded
x=1&y=2
------------------------------------------
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: https now works, but http doesnt?!?!
Posted by Roland Weber <ht...@dubioso.net>.
Hello Jake,
the Client HTTP Programming Primer addresses the problem of
submitting HTML forms in HttpClient:
http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners
Follow the instructions about "analyzing the form" twice,
once for the HTTP and once for the HTTPS version. Check for
differences. Also, check whether one of the cookies you might
get is declared as "secure". In that case, it would only be
sent to the server if you are using HTTPS.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: https now works, but http doesnt?!?!
Posted by Jake C <bu...@hotmail.com>.
I tried all of that.
I call "client.setState(new HttpState());" before my transactions and
removed the synchronized blocks.
I checked the forms I'm posting to on both servers, and they are identical
except for the __VIEWSTATE value.
I print out the URI and the parameters I'm adding. If I paste the URI into
the web browser then add the parameters manually
(<URI>?<Name1>=<Value1>&<Name2>=<Value2>&...) it works just fine!
I printed out the Headers:
header[0]:User-Agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
.NET CLR 1.1.4322)
header[1]:Host=<host>:8080
header[2]:Content-Length=110
header[3]:Content-Type=application/x-www-form-urlencoded
The content length is exactly the right length for all my parameters and
values, with a = between the name and value, and an & between each pair.
The Method is a PostMethod, and my URI is correct. What the heck is going
on? Is there another level of debugging I can turn on to help track this
down?
This is EXTREMELY frustrating! Why should it work for https and not for
http? What could possible be the difference between the two?
Here is the rest of the information I'm printing out:
method=org.apache.commons.httpclient.methods.PostMethod
URI=http://<host>:8080/<app>/
path=/<app>/
query=null
reason=Method not allowed
status=405, Method not allowed
location=null
contentType=Content-Type: text/html
All of this is identical for the https situation except for the URI, which
says https and has no port specified.
>From: Roland Weber <ht...@dubioso.net>
>Reply-To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>To: HttpClient User Discussion <ht...@jakarta.apache.org>
>Subject: Re: https now works, but http doesnt?!?!
>Date: Sat, 02 Dec 2006 09:06:20 +0100
>
>Hello Jake,
>
> > When I run under https, I get a log message that I used to get for http
> > as well:
> > [INFO] HttpMethodDirector - Redirect requested but followRedirects is
> > disabled
> > I was never sure WHY I got that message, as I always called
> > method.setFollowRedirects(false) and follow the redirects manually.
> > However, it didn't seem to hurt anything, so I ignored it.
>
>Yes, that is not a warning. It is just an INFO message to tell you
>that you called method.setFollowRedirects(false) and that you need
>to follow the redirects manually :-)
>
> > However, now when I use http, I get this message instead:
> > [INFO] HttpMethodBase - Discarding unexpected response: HTTP/1.1 100
> > Continue
>
>"100 Continue" responses are part of the expect-continue handshake
>you can enable for POST or PUT requests. The "unexpected" in the
>message means that HttpClient wasn't using the expect-continue
>handshake, or maybe that the server sent two of the "100 continue"
>responses. I'm not sure whether that is just strange or actually
>bad behavior on the side of the server, but it's nothing to worry
>about at this time.
>
> > I then get a 405, Method not allowed error and some really strange HTML
> > as a response, which I'm sure is just the standard IIS 405 error page,
> > but since it mentions protocol, I'll include it at the bottom of the
> > message.
>
>That means you are sending a POST to a URL that can only be used
>for GET. Or else there is a more complicated mismatch, like if you
>send a HEAD request and the server doesn't like it or some such.
>
> > I am POSITIVE I am using the correct url. It DOES have a port, but I've
> > been using this exact same code before I added the EasySSL* classes, and
> > it worked just fine. If I manually browse to the same page, I can log
>in.
>
>I think it is just a coincidence that this problem happens now
>after you've fixed the SSL problem. Have you checked whether
>somebody updated the server recently and thereby changed the
>URL you need to use?
>
> > Actually, there IS one thing I changed from before. I made my HttpClient
> > static and access it in synchronized(client) blocks now. My application
> > is user-bound, and one interaction is always completed before they can
> > start another anyway, but I added the synchronized blocks for safety.
> > That couldn't really cause problems, could it? I'm not locking up, just
> > getting an error from the server.
>
>The HttpClient object keeps a default HttpState, where cookies are
>collected. Try to reset the default state before each interaction
>to see whether that makes any difference.
>
>>From a general design perspective, synchronizing access to the
>HttpClient is overkill, especially because you have to synchronize
>full method executions. Install a multithreaded connection manager,
>create a new HttpState for each interaction instead of using the
>default state, and then access the static HttpClient object without
>synchronization. Make sure to shut down the connection manager
>properly when it is no longer needed.
>
>hope that helps,
> Roland
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: https now works, but http doesnt?!?!
Posted by Roland Weber <ht...@dubioso.net>.
Hello Jake,
> When I run under https, I get a log message that I used to get for http
> as well:
> [INFO] HttpMethodDirector - Redirect requested but followRedirects is
> disabled
> I was never sure WHY I got that message, as I always called
> method.setFollowRedirects(false) and follow the redirects manually.
> However, it didn't seem to hurt anything, so I ignored it.
Yes, that is not a warning. It is just an INFO message to tell you
that you called method.setFollowRedirects(false) and that you need
to follow the redirects manually :-)
> However, now when I use http, I get this message instead:
> [INFO] HttpMethodBase - Discarding unexpected response: HTTP/1.1 100
> Continue
"100 Continue" responses are part of the expect-continue handshake
you can enable for POST or PUT requests. The "unexpected" in the
message means that HttpClient wasn't using the expect-continue
handshake, or maybe that the server sent two of the "100 continue"
responses. I'm not sure whether that is just strange or actually
bad behavior on the side of the server, but it's nothing to worry
about at this time.
> I then get a 405, Method not allowed error and some really strange HTML
> as a response, which I'm sure is just the standard IIS 405 error page,
> but since it mentions protocol, I'll include it at the bottom of the
> message.
That means you are sending a POST to a URL that can only be used
for GET. Or else there is a more complicated mismatch, like if you
send a HEAD request and the server doesn't like it or some such.
> I am POSITIVE I am using the correct url. It DOES have a port, but I've
> been using this exact same code before I added the EasySSL* classes, and
> it worked just fine. If I manually browse to the same page, I can log in.
I think it is just a coincidence that this problem happens now
after you've fixed the SSL problem. Have you checked whether
somebody updated the server recently and thereby changed the
URL you need to use?
> Actually, there IS one thing I changed from before. I made my HttpClient
> static and access it in synchronized(client) blocks now. My application
> is user-bound, and one interaction is always completed before they can
> start another anyway, but I added the synchronized blocks for safety.
> That couldn't really cause problems, could it? I'm not locking up, just
> getting an error from the server.
The HttpClient object keeps a default HttpState, where cookies are
collected. Try to reset the default state before each interaction
to see whether that makes any difference.
>From a general design perspective, synchronizing access to the
HttpClient is overkill, especially because you have to synchronize
full method executions. Install a multithreaded connection manager,
create a new HttpState for each interaction instead of using the
default state, and then access the static HttpClient object without
synchronization. Make sure to shut down the connection manager
properly when it is no longer needed.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
https now works, but http doesnt?!?!
Posted by Jake C <bu...@hotmail.com>.
Thanks for all the earlier help! I now have https working.
Strangely enough, however, it now fails to work for http... :-(
I am most positive it doesn't have anything to do with using EasySSL*,
because if I comment it all out, I still have the problem with http, and
also can't connect to https any more.
When I run under https, I get a log message that I used to get for http as
well:
[INFO] HttpMethodDirector - Redirect requested but followRedirects is
disabled
I was never sure WHY I got that message, as I always called
method.setFollowRedirects(false) and follow the redirects manually. However,
it didn't seem to hurt anything, so I ignored it.
However, now when I use http, I get this message instead:
[INFO] HttpMethodBase - Discarding unexpected response: HTTP/1.1 100
Continue
I then get a 405, Method not allowed error and some really strange HTML as a
response, which I'm sure is just the standard IIS 405 error page, but since
it mentions protocol, I'll include it at the bottom of the message.
I am POSITIVE I am using the correct url. It DOES have a port, but I've been
using this exact same code before I added the EasySSL* classes, and it
worked just fine. If I manually browse to the same page, I can log in.
I print out the path beforehand, and it is the same for both protocols, and
the PostMethod is created identically as well. I originally added the
EasySSL* stuff no matter what protocol was being used, as follows:
Protocol easyhttps = new Protocol("https", new
EasySSLProtocolSocketFactory(), 443);
Protocol.registerProtocol("https", easyhttps);
I then removed those lines completely, in case having that set somehow
messed up http, but http still failed.
Actually, there IS one thing I changed from before. I made my HttpClient
static and access it in synchronized(client) blocks now. My application is
user-bound, and one interaction is always completed before they can start
another anyway, but I added the synchronized blocks for safety. That
couldn't really cause problems, could it? I'm not locking up, just getting
an error from the server.
Here is the HTML page I received.
<META NAME="ROBOTS" CONTENT="NOINDEX">
<title>The page cannot be displayed</title>
<META HTTP-EQUIV="Content-Type" Content="text-html; charset=Windows-1252">
</head>
<script>
function Homepage(){
<!--
// in real bits, urls get returned to our script like this:
// res://shdocvw.dll/http_404.htm#http://www.DocURL.com/bar.htm
//For testing use DocURL =
"res://shdocvw.dll/http_404.htm#https://www.microsoft.com/bar.htm"
DocURL=document.URL;
//this is where the http or https will be, as found by searching for ://
but skipping the res://
protocolIndex=DocURL.indexOf("://",4);
//this finds the ending slash for the domain server
serverIndex=DocURL.indexOf("/",protocolIndex + 3);
//for the href, we need a valid URL to the domain. We search for the #
symbol to find the begining
//of the true URL, and add 1 to skip it - this is the BeginURL value. We
use serverIndex as the end marker.
//urlresult=DocURL.substring(protocolIndex - 4,serverIndex);
BeginURL=DocURL.indexOf("#",1) + 1;
urlresult=DocURL.substring(BeginURL,serverIndex);
//for display, we need to skip after http://, and go to the next slash
displayresult=DocURL.substring(protocolIndex + 3 ,serverIndex);
InsertElementAnchor(urlresult, displayresult);
}
function HtmlEncode(text)
{
return text.replace(/&/g, '&').replace(/'/g, '"').replace(/</g,
'<').replace(/>/g, '>');
}
function TagAttrib(name, value)
{
return ' '+name+'="'+HtmlEncode(value)+'"';
}
function PrintTag(tagName, needCloseTag, attrib, inner){
document.write( '<' + tagName + attrib + '>' + HtmlEncode(inner) );
if (needCloseTag) document.write( '</' + tagName +'>' );
}
function URI(href)
{
IEVer = window.navigator.appVersion;
IEVer = IEVer.substr( IEVer.indexOf('MSIE') + 5, 3 );
return (IEVer.charAt(1)=='.' && IEVer >= '5.5') ?
encodeURI(href) :
escape(href).replace(/%3A/g, ':').replace(/%3B/g, ';');
}
function InsertElementAnchor(href, text)
{
PrintTag('A', true, TagAttrib('HREF', URI(href)), text);
}
//-->
</script>
<body bgcolor="FFFFFF">
<table width="410" cellpadding="3" cellspacing="5">
<tr>
<td align="left" valign="middle" width="360">
<h1 style="COLOR:000000; FONT: 13pt/15pt verdana"><!--Problem-->The page
cannot be displayed</h1>
</td>
</tr>
<tr>
<td width="400" colspan="2">
<font style="COLOR:000000; FONT: 8pt/11pt verdana">The page you are looking
for cannot be displayed because the page address is incorrect.</font> </td>
</tr>
<tr>
<td width="400" colspan="2">
<font style="COLOR:000000; FONT: 8pt/11pt verdana">
<hr color="#C0C0C0" noshade>
<p>Please try the following:</p>
<ul>
<li>If you typed the page address in the Address bar, check that it is
entered correctly.<br>
</li>
<li>Open the
<script>
<!--
if (!((window.navigator.userAgent.indexOf("MSIE") > 0) &&
(window.navigator.appVersion.charAt(0) == "2")))
{
Homepage();
}
//-->
</script>
home page and then look for links to the information you want.</li>
</ul>
<h2 style="COLOR:000000; FONT: 8pt/11pt verdana">HTTP 405 - Resource not
allowed<br>
Internet Information Services</h2>
<hr color="#C0C0C0" noshade>
<p>Technical Information (for support personnel)</p>
<ul>
<li>More information:<br>
<a
href="http://www.microsoft.com/ContentRedirect.asp?prd=iis&sbp=&pver=5.0&pid=&ID=405&cat=web&os=&over=&hrd=&Opt1=&Opt2=&Opt3="
target="_blank">Microsoft Support</a>
</li>
</ul>
</font></td>
</tr>
</table>
</body>
</html>
Thanks in advance for any help!
_________________________________________________________________
Get the latest Windows Live Messenger 8.1 Beta version. Join now.
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Jake C <bu...@hotmail.com>.
Yep, I just verified that our server is using a self-signed cert. The
"Issued by" contains the server name. :-)
So, I will use EasySSL in test mode, and not use it in production mode.
Just to verify, when I hit Production, which has a Verisign cert, I
shouldn't have this issue, correct?
It would be very helpful to have a dialog like the browsers do that presents
the certificate when there is a problem, and let you choose whether to allow
it permanently, temporarily, or disallow it. Presumably, this would just
require the location of a keystore to use/create, and the user/pass for it.
Of course, then you would need to store the user/pass somewhere, encrypted.
>From: "Julius Davies" <ju...@gmail.com>
>Reply-To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>Subject: Re: Certificateless SSL
>Date: Fri, 1 Dec 2006 16:06:35 -0500
>
>Hi, Jake,
>
>Roland is right. Your reference to "Client Certificate" sent me on a
>journey. :-)
>
>Thanks for running the not-yet-common-ssl "Ping" test! Sorry to make
>you edit out so much information from the cut & paste.
>
>Anyway, you're exactly right. Your issue is that HttpClient is not
>trusting that self-signed certificate. java.net.URL wouldn't trust
>it, either. You have several options:
>
>1. Import self-signed cert into Java's "cacerts" file.
>-------------------------------------------------------------------------
>You can use "openssl s_client" or "not-yet-commons-ssl.jar Ping" to
>download the self-signed certificate. Cut & paste the Base64 PEM text
>into a separate file (be sure to include the ----BEGIN----- and
>-----END-----). Try and import it into Java's "cacerts" file. It's
>usually found here:
>
>$JAVA_HOME/jre/lib/security/cacerts
>
>Here's the command to import a Base64 PEM certificate into that file:
>
>cd $JAVA_HOME/jre/lib/security
>$JAVA_HOME/bin/keytool -import -file [file.pem] -keystore cacerts
>
>The password is usually "changeit" (unless you changed it? ROTFL).
>
>Personally, I don't really recommend this approach. But it's good to
>know about. If you ever upgrade your JVM or switch to JRockit or IBM,
>you're going to have to do this all over again.
>
>
>2. Use EasySSLSockeyProtocolFactory
>-------------------------------------------------------------------------
>http://jakarta.apache.org/commons/httpclient/sslguide.html
>
>This is a great approach for a dev environment, but it's usually not
>appropriate for a production environment.
>
>
>3. Use AuthSSLSockeyProtocolFactory
>-------------------------------------------------------------------------
>Set the client JKS to null. Set the trust JKS to a brand new JKS you
>created only containing the server's self-signed certificate.
>
>
>4. You can also try the ALPHA "not-yet-commons-ssl.jar"
>-------------------------------------------------------------------------
>I think this is an interesting approach:
>
>http://juliusdavies.ca/commons-ssl/TrustExample.java.html
>
>It's kind of a hybrid approach of #1 and #2. Essentially equivalent
>to #3, but without the hassle of creating a JKS file. (Java Keystore
>File).
>
>-------------------------------------------------------------------------
>
>Security note: downloading the certificate directly from the SSL
>handshake using "openssl s_client" or "not-yet-commons-ssl.jar" is not
>safe. In a dev environment it's okay. But in a production
>environment it leaves you suspectible to the oft-cited
>man-in-the-middle. It's safer than EasySSLSockeyProtocolFactory
>because you only download the certificate one time, whereas
>EasySSLSockeyProtocolFactory is always vulnerable, with every socket
>created. But nonetheless you should try to acquire the self-signed
>certificate through a different medium, maybe email (with
>encryption?), fax, telephone, letter mail, usb-drive, etc. Or if the
>self-signed cert is hosted on an properly signed "https" site, that's
>also okay (e.g. https://trustedsite.com/path/to/self-signed.pem).
>
>yours,
>
>Julius
>
><SNIP>
>
>--
>yours,
>
>Julius Davies
>416-652-0183
>http://juliusdavies.ca/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
_________________________________________________________________
Fixing up the home? Live Search can help
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Julius Davies <ju...@gmail.com>.
Hi, Jake,
Roland is right. Your reference to "Client Certificate" sent me on a
journey. :-)
Thanks for running the not-yet-common-ssl "Ping" test! Sorry to make
you edit out so much information from the cut & paste.
Anyway, you're exactly right. Your issue is that HttpClient is not
trusting that self-signed certificate. java.net.URL wouldn't trust
it, either. You have several options:
1. Import self-signed cert into Java's "cacerts" file.
-------------------------------------------------------------------------
You can use "openssl s_client" or "not-yet-commons-ssl.jar Ping" to
download the self-signed certificate. Cut & paste the Base64 PEM text
into a separate file (be sure to include the ----BEGIN----- and
-----END-----). Try and import it into Java's "cacerts" file. It's
usually found here:
$JAVA_HOME/jre/lib/security/cacerts
Here's the command to import a Base64 PEM certificate into that file:
cd $JAVA_HOME/jre/lib/security
$JAVA_HOME/bin/keytool -import -file [file.pem] -keystore cacerts
The password is usually "changeit" (unless you changed it? ROTFL).
Personally, I don't really recommend this approach. But it's good to
know about. If you ever upgrade your JVM or switch to JRockit or IBM,
you're going to have to do this all over again.
2. Use EasySSLSockeyProtocolFactory
-------------------------------------------------------------------------
http://jakarta.apache.org/commons/httpclient/sslguide.html
This is a great approach for a dev environment, but it's usually not
appropriate for a production environment.
3. Use AuthSSLSockeyProtocolFactory
-------------------------------------------------------------------------
Set the client JKS to null. Set the trust JKS to a brand new JKS you
created only containing the server's self-signed certificate.
4. You can also try the ALPHA "not-yet-commons-ssl.jar"
-------------------------------------------------------------------------
I think this is an interesting approach:
http://juliusdavies.ca/commons-ssl/TrustExample.java.html
It's kind of a hybrid approach of #1 and #2. Essentially equivalent
to #3, but without the hassle of creating a JKS file. (Java Keystore
File).
-------------------------------------------------------------------------
Security note: downloading the certificate directly from the SSL
handshake using "openssl s_client" or "not-yet-commons-ssl.jar" is not
safe. In a dev environment it's okay. But in a production
environment it leaves you suspectible to the oft-cited
man-in-the-middle. It's safer than EasySSLSockeyProtocolFactory
because you only download the certificate one time, whereas
EasySSLSockeyProtocolFactory is always vulnerable, with every socket
created. But nonetheless you should try to acquire the self-signed
certificate through a different medium, maybe email (with
encryption?), fax, telephone, letter mail, usb-drive, etc. Or if the
self-signed cert is hosted on an properly signed "https" site, that's
also okay (e.g. https://trustedsite.com/path/to/self-signed.pem).
yours,
Julius
On 12/1/06, Richard Suematsu <ri...@syncadd.com> wrote:
> Hi Jake,
>
> When you hit the 3rd party app, does IE give you a Security Alert box
> that says "The security certificate was issues by a company you have
> chosen not to trust. View the certificate..."
>
> If so, what thats saying is that the certificate on the server was
> signed by a CA that IE doesn't know about. Click on the View
> Certificate button and look at the Issued by: field.
>
> Your HttpClient connection is dying because the server has an
> unrecognized CA and HttpClient can't just pop up a window asking the
> user to continue like IE.
>
> Check out: http://jakarta.apache.org/commons/httpclient/sslguide.html
>
> About half way down the page there is a EasySSLSockeyProtocolFactory
> that will allow HttpClient to ignore unrecognized CAs.
>
> Jake C wrote:
> > Thanks for the quick reply!
> >
> > Maybe I'm misunderstanding the exception I'm getting. IE is normally
> > used to access the 3rd party application, and it does NOT require us
> > to install or even select a certificate. It DOES prompt us to accept
> > THEIR certificate. We certainly don't have to generate a certificate
> > and install it in a keystore for every client.
> >
> > The exception I'm getting in HttpClient is:
> >
> > [INFO] HttpMethodDirector - I/O exception
> > (javax.net.ssl.SSLHandshakeException) caught when processing request:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > find valid certification path to requested target
> >
> >> From what I saw in the mailing list archives, and from a Google
> >> search, that
> > meant that I didn't have a certificate installed in JSSE.
> >
> > Here is what I get when running the ping utility:
> >
> > Writing:
> > ================================================================================
> >
> > HEAD / HTTP/1.1
> > Host: <IIS Server>
> >
> > Reading:
> > ================================================================================
> >
> > HTTP/1.1 200 OK
> > Content-Length: 1433
> > Content-Type: text/html
> > Content-Location: https://<IIS Server>/iisstart.htm
> > Last-Modified: Sat, 22 Feb 2003 02:48:30 GMT
> > Accept-Ranges: bytes
> > ETag: "<ETag>"
> > Server: Microsoft-IIS/6.0
> > X-Powered-By: ASP.NET
> > Date: Fri, 01 Dec 2006 17:02:43 GMT
> >
> > Server Certificate for: [<IIS Server>:443]
> > ================================================================================
> >
> > <IIS Server>
> > Valid: 2006/Nov/30 - 2007/Nov/30
> > s: CN=<IIS Server>, OU=<My Department>, O="<My Company>, Inc.", L=<My
> > State>, ST=<My City>, C=US
> > i: CN=<IIS Server>, DC=<My Company>, DC=com
> > -----BEGIN CERTIFICATE-----
> > <Lots of certificate info>
> > -----END CERTIFICATE-----
> >
> > Thanks again for your quick reply, and your help!
> >
> >> From: "Julius Davies" <ju...@gmail.com>
> >> Reply-To: "HttpClient User Discussion"
> >> <ht...@jakarta.apache.org>
> >> To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
> >> Subject: Re: Certificateless SSL
> >> Date: Thu, 30 Nov 2006 23:21:23 -0500
> >>
> >> Hi, Jake,
> >>
> >> I'll take a stab at this one!
> >>
> >> Certificates don't really have much to do with encryption.
> >> Certificates address the issue of trust. Think about it this way:
> >>
> >> How do I know I'm actually talking to "https://web.da-us.citibank.com/"?
> >>
> >> That's why they're called "certificates". They really are like a
> >> virtual piece of paper, nicely framed, with a nice stamp and some
> >> ribbons, hanging on your Doctor's office wall. "I guess he really
> >> must be a doctor, because few people have access to those fancy
> >> ribbons!"
> >>
> >> The "trust" works for a few reasons:
> >>
> >> - Only Citibank will be able to obtain a certificate for
> >> "citibank.com" from a root certificate authority (like thawte,
> >> verisign, many others pre-loaded into your browser).
> >>
> >> - (Or, alternatively, if Citibank can't get a certificate for
> >> "citibank.com", they'll choose a different domain name, and print that
> >> on all their marketing materials).
> >>
> >> - Once Citibank has obtained that first certificate no-one else will
> >> be able to acquire a new one for the domain, even after the first one
> >> expires.
> >>
> >> The fact that the ROOT CA's already trusted by your browser came
> >> pre-loaded is important. This means those CA's were installed
> >> "out-of-band" - through a different medium compared to that through
> >> which you are conducting your online business. In the case of IE6
> >> those root CA's presumably came on the CD-ROM that came with Windows
> >> XP, and NOT over the internet.
> >>
> >> (You can then use those out-of-band root ca's to bootstrap your
> >> acquisition of additional ca's. You now have at least a few (quite a
> >> few) https:// sites you already trust, and those can provide you with
> >> additional root ca's. This makes me think that all Firefox downloads
> >> should be over https, since that is one way we acquire new ROOT ca's -
> >> by downloading a new browser!.... anyway, confusing digression, you
> >> can give this paragraph a few months to sink in.)
> >>
> >> There's quite a lot of detail behind all of this. For example, how
> >> does the "citibank.com" certificate get associated with those ROOT
> >> CA's already loaded in the browser? If someone managed to temporarily
> >> steal the "citibank.com" domain, why can't they also just steal the
> >> certificate off of Citibank's website? How does the domain name fit
> >> into all this? For now let's just assume all this stuff is okay.
> >>
> >> Client certificates provide exactly the same service. But now it's a
> >> question of "how does the server really know that Julius Davies is
> >> driving that browser?" Usually a username/password is considered
> >> adequete, so client certificates are quite rare. But they do create a
> >> 2nd factor of authentication. Client certificates could be used to
> >> dramatically reduce phishing attacks. But it's impractical. The
> >> thing that's so great about client certs is that they make it harder
> >> for the public at large to access a given site. The "public" must get
> >> a username/password, and then they must also acquire a unique client
> >> cert, install it, and regularly update it because of its expiry cycle!
> >> As much as CitiBank wants to avoid phishing, they also want their
> >> customers to be able to access the website without clogging the phone
> >> lines.
> >>
> >> Just like anything, client certs (and server certs) never provide a
> >> 100% bulletproof solution. The private key behind the public
> >> certificate can be stolen, just like the keys to your house can be
> >> stolen. A safe that's impossible to open is not useful. A safe that
> >> can be opened can also be opened by the wrong person.
> >>
> >> But client certs do add one more layer of hassle to the bad guy's
> >> life. "Great, not only do I need to get his username and password, I
> >> need to get the private key that goes with his client certificate."
> >>
> >>
> >> Onto your question: if IIS is configured to require client certs from
> >> HTTPClient, then I suspect it's also requiring client certs from your
> >> browser. Your browser might just not be telling you that it's sending
> >> the client cert. Are you using Firefox? By default Firefox won't
> >> bother prompting you to select the client certificate to use. Firefox
> >> will just automatically provide it to the server. But you can get
> >> Firefox to always prompt by changing the settings.
> >>
> >> (Interesting side note: if Firefox is just automatically providing
> >> it, that means that the client cert is ultimately protected only by
> >> your screensaver password. People probably can't "export" the client
> >> cert to a file without a special admin password, but they can still
> >> just sit down at your computer and start using the browser. But I
> >> think that's the right way to go. In the long run (5 years from now?)
> >> that initial-logon/screensaver password is going to be the only
> >> password you ever use.)
> >>
> >> Perhaps you can try downloading "not-yet-commons-ssl.jar" from
> >> http://juliusdavies.ca/commons-ssl/. There is a useful "ping" utility
> >> there to try and help debug HTTPS issues. Can you try running this
> >> test?
> >>
> >> java -jar not-yet-commons-ssl.jar -t [IIS IP]:port
> >>
> >> If you recieve this response, then, yeah, your server wants a client
> >> certificate:
> >>
> >> javax.net.ssl.SSLHandshakeException: Received fatal alert:
> >> bad_certificate
> >>
> >>
> >> I have to signoff now. But I'll be able to respond with part 2
> >> tomorrow. Sorry I haven't answered all your questions yet.
> >>
> >> yours,
> >>
> >> Julius
> >>
> >>
> >>
> >>
> >> On 11/30/06, Jake C <bu...@hotmail.com> wrote:
> >>> I am a complete SSL noob, so please pardon me if my questions are
> >>> silly...
> >>> :-) I've seen similar questions in the archive, but nothing that really
> >>> spelled it out.
> >>>
> >>> We need an encrypted connection to a 3-rd party application, but we
> >>> don't
> >>> need validation. The data being transmitted is validation enough for
> >>> us.
> >>> However, the application we are sending to (running on Windows under
> >>> IIS) is
> >>> requiring a certificate.
> >>>
> >>> I know it is possible to use SSL without requiring a certificate, as
> >>> the
> >>> test application at the bottom of the HttpClient SSL Guide works for
> >>> Verisign, but not for our application.
> >>>
> >>> I see two possible ways of getting around this, and I'd just like some
> >>> validation that these would work the way I want (not requiring our
> >>> users to
> >>> mess with certificates).
> >>>
> >>> 1) Use an Authenticating Proxy Server. We should be able to set up
> >>> one of
> >>> these that accepts SSL connections without requiring a certificate, and
> >>> configure the connection between it and our 3-rd party application
> >>> using a
> >>> certificate just for the proxy server, and not for each individual
> >>> client.
> >>>
> >>> 2) Modify the IIS configuration of our 3-rd party application so
> >>> that it
> >>> doesn't require client certificates, as the data being sent contains
> >>> the
> >>> real authentication information. I"m not sure this is really an
> >>> option, as I
> >>> don't know IIS at all. We DO have access to the server, though.
> >>>
> >>> Do both of these methods work, and encrypt our data? If so, is the
> >>> encryption in the second case just as strong as if we used client
> >>> certificates, or is it weaker because there is only a server
> >>> certificate? Is
> >>> there any other method I missed?
> >>>
> >>> The application we are accessing initially provides a login page,
> >>> and we
> >>> just provide a MethodPost with the needed data, so the SSL
> >>> Connection itself
> >>> isn't initially authenticated. What I don't really understand is how a
> >>> generic web browser certificate is any better than no certificate at
> >>> all.
> >>> Why is a personal certificate required via HttpClient and not via a web
> >>> browser?
> >>>
> >>> _________________________________________________________________
> >>> Get FREE company branded e-mail accounts and business Web site from
> >>> Microsoft Office Live
> >>> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >>> httpclient-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> yours,
> >>
> >> Julius Davies
> >> 416-652-0183
> >> http://juliusdavies.ca/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >>
> >
> > _________________________________________________________________
> > All-in-one security and maintenance for your PC. Get a free 90-day
> > trial!
> > http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo0050000001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
> >
>
>
> --
> Aloha,
> Richard Suematsu
> SynCaDD Systems, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Richard Suematsu <ri...@syncadd.com>.
Hi Jake,
When you hit the 3rd party app, does IE give you a Security Alert box
that says "The security certificate was issues by a company you have
chosen not to trust. View the certificate..."
If so, what thats saying is that the certificate on the server was
signed by a CA that IE doesn't know about. Click on the View
Certificate button and look at the Issued by: field.
Your HttpClient connection is dying because the server has an
unrecognized CA and HttpClient can't just pop up a window asking the
user to continue like IE.
Check out: http://jakarta.apache.org/commons/httpclient/sslguide.html
About half way down the page there is a EasySSLSockeyProtocolFactory
that will allow HttpClient to ignore unrecognized CAs.
Jake C wrote:
> Thanks for the quick reply!
>
> Maybe I'm misunderstanding the exception I'm getting. IE is normally
> used to access the 3rd party application, and it does NOT require us
> to install or even select a certificate. It DOES prompt us to accept
> THEIR certificate. We certainly don't have to generate a certificate
> and install it in a keystore for every client.
>
> The exception I'm getting in HttpClient is:
>
> [INFO] HttpMethodDirector - I/O exception
> (javax.net.ssl.SSLHandshakeException) caught when processing request:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
>
>> From what I saw in the mailing list archives, and from a Google
>> search, that
> meant that I didn't have a certificate installed in JSSE.
>
> Here is what I get when running the ping utility:
>
> Writing:
> ================================================================================
>
> HEAD / HTTP/1.1
> Host: <IIS Server>
>
> Reading:
> ================================================================================
>
> HTTP/1.1 200 OK
> Content-Length: 1433
> Content-Type: text/html
> Content-Location: https://<IIS Server>/iisstart.htm
> Last-Modified: Sat, 22 Feb 2003 02:48:30 GMT
> Accept-Ranges: bytes
> ETag: "<ETag>"
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> Date: Fri, 01 Dec 2006 17:02:43 GMT
>
> Server Certificate for: [<IIS Server>:443]
> ================================================================================
>
> <IIS Server>
> Valid: 2006/Nov/30 - 2007/Nov/30
> s: CN=<IIS Server>, OU=<My Department>, O="<My Company>, Inc.", L=<My
> State>, ST=<My City>, C=US
> i: CN=<IIS Server>, DC=<My Company>, DC=com
> -----BEGIN CERTIFICATE-----
> <Lots of certificate info>
> -----END CERTIFICATE-----
>
> Thanks again for your quick reply, and your help!
>
>> From: "Julius Davies" <ju...@gmail.com>
>> Reply-To: "HttpClient User Discussion"
>> <ht...@jakarta.apache.org>
>> To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>> Subject: Re: Certificateless SSL
>> Date: Thu, 30 Nov 2006 23:21:23 -0500
>>
>> Hi, Jake,
>>
>> I'll take a stab at this one!
>>
>> Certificates don't really have much to do with encryption.
>> Certificates address the issue of trust. Think about it this way:
>>
>> How do I know I'm actually talking to "https://web.da-us.citibank.com/"?
>>
>> That's why they're called "certificates". They really are like a
>> virtual piece of paper, nicely framed, with a nice stamp and some
>> ribbons, hanging on your Doctor's office wall. "I guess he really
>> must be a doctor, because few people have access to those fancy
>> ribbons!"
>>
>> The "trust" works for a few reasons:
>>
>> - Only Citibank will be able to obtain a certificate for
>> "citibank.com" from a root certificate authority (like thawte,
>> verisign, many others pre-loaded into your browser).
>>
>> - (Or, alternatively, if Citibank can't get a certificate for
>> "citibank.com", they'll choose a different domain name, and print that
>> on all their marketing materials).
>>
>> - Once Citibank has obtained that first certificate no-one else will
>> be able to acquire a new one for the domain, even after the first one
>> expires.
>>
>> The fact that the ROOT CA's already trusted by your browser came
>> pre-loaded is important. This means those CA's were installed
>> "out-of-band" - through a different medium compared to that through
>> which you are conducting your online business. In the case of IE6
>> those root CA's presumably came on the CD-ROM that came with Windows
>> XP, and NOT over the internet.
>>
>> (You can then use those out-of-band root ca's to bootstrap your
>> acquisition of additional ca's. You now have at least a few (quite a
>> few) https:// sites you already trust, and those can provide you with
>> additional root ca's. This makes me think that all Firefox downloads
>> should be over https, since that is one way we acquire new ROOT ca's -
>> by downloading a new browser!.... anyway, confusing digression, you
>> can give this paragraph a few months to sink in.)
>>
>> There's quite a lot of detail behind all of this. For example, how
>> does the "citibank.com" certificate get associated with those ROOT
>> CA's already loaded in the browser? If someone managed to temporarily
>> steal the "citibank.com" domain, why can't they also just steal the
>> certificate off of Citibank's website? How does the domain name fit
>> into all this? For now let's just assume all this stuff is okay.
>>
>> Client certificates provide exactly the same service. But now it's a
>> question of "how does the server really know that Julius Davies is
>> driving that browser?" Usually a username/password is considered
>> adequete, so client certificates are quite rare. But they do create a
>> 2nd factor of authentication. Client certificates could be used to
>> dramatically reduce phishing attacks. But it's impractical. The
>> thing that's so great about client certs is that they make it harder
>> for the public at large to access a given site. The "public" must get
>> a username/password, and then they must also acquire a unique client
>> cert, install it, and regularly update it because of its expiry cycle!
>> As much as CitiBank wants to avoid phishing, they also want their
>> customers to be able to access the website without clogging the phone
>> lines.
>>
>> Just like anything, client certs (and server certs) never provide a
>> 100% bulletproof solution. The private key behind the public
>> certificate can be stolen, just like the keys to your house can be
>> stolen. A safe that's impossible to open is not useful. A safe that
>> can be opened can also be opened by the wrong person.
>>
>> But client certs do add one more layer of hassle to the bad guy's
>> life. "Great, not only do I need to get his username and password, I
>> need to get the private key that goes with his client certificate."
>>
>>
>> Onto your question: if IIS is configured to require client certs from
>> HTTPClient, then I suspect it's also requiring client certs from your
>> browser. Your browser might just not be telling you that it's sending
>> the client cert. Are you using Firefox? By default Firefox won't
>> bother prompting you to select the client certificate to use. Firefox
>> will just automatically provide it to the server. But you can get
>> Firefox to always prompt by changing the settings.
>>
>> (Interesting side note: if Firefox is just automatically providing
>> it, that means that the client cert is ultimately protected only by
>> your screensaver password. People probably can't "export" the client
>> cert to a file without a special admin password, but they can still
>> just sit down at your computer and start using the browser. But I
>> think that's the right way to go. In the long run (5 years from now?)
>> that initial-logon/screensaver password is going to be the only
>> password you ever use.)
>>
>> Perhaps you can try downloading "not-yet-commons-ssl.jar" from
>> http://juliusdavies.ca/commons-ssl/. There is a useful "ping" utility
>> there to try and help debug HTTPS issues. Can you try running this
>> test?
>>
>> java -jar not-yet-commons-ssl.jar -t [IIS IP]:port
>>
>> If you recieve this response, then, yeah, your server wants a client
>> certificate:
>>
>> javax.net.ssl.SSLHandshakeException: Received fatal alert:
>> bad_certificate
>>
>>
>> I have to signoff now. But I'll be able to respond with part 2
>> tomorrow. Sorry I haven't answered all your questions yet.
>>
>> yours,
>>
>> Julius
>>
>>
>>
>>
>> On 11/30/06, Jake C <bu...@hotmail.com> wrote:
>>> I am a complete SSL noob, so please pardon me if my questions are
>>> silly...
>>> :-) I've seen similar questions in the archive, but nothing that really
>>> spelled it out.
>>>
>>> We need an encrypted connection to a 3-rd party application, but we
>>> don't
>>> need validation. The data being transmitted is validation enough for
>>> us.
>>> However, the application we are sending to (running on Windows under
>>> IIS) is
>>> requiring a certificate.
>>>
>>> I know it is possible to use SSL without requiring a certificate, as
>>> the
>>> test application at the bottom of the HttpClient SSL Guide works for
>>> Verisign, but not for our application.
>>>
>>> I see two possible ways of getting around this, and I'd just like some
>>> validation that these would work the way I want (not requiring our
>>> users to
>>> mess with certificates).
>>>
>>> 1) Use an Authenticating Proxy Server. We should be able to set up
>>> one of
>>> these that accepts SSL connections without requiring a certificate, and
>>> configure the connection between it and our 3-rd party application
>>> using a
>>> certificate just for the proxy server, and not for each individual
>>> client.
>>>
>>> 2) Modify the IIS configuration of our 3-rd party application so
>>> that it
>>> doesn't require client certificates, as the data being sent contains
>>> the
>>> real authentication information. I"m not sure this is really an
>>> option, as I
>>> don't know IIS at all. We DO have access to the server, though.
>>>
>>> Do both of these methods work, and encrypt our data? If so, is the
>>> encryption in the second case just as strong as if we used client
>>> certificates, or is it weaker because there is only a server
>>> certificate? Is
>>> there any other method I missed?
>>>
>>> The application we are accessing initially provides a login page,
>>> and we
>>> just provide a MethodPost with the needed data, so the SSL
>>> Connection itself
>>> isn't initially authenticated. What I don't really understand is how a
>>> generic web browser certificate is any better than no certificate at
>>> all.
>>> Why is a personal certificate required via HttpClient and not via a web
>>> browser?
>>>
>>> _________________________________________________________________
>>> Get FREE company branded e-mail accounts and business Web site from
>>> Microsoft Office Live
>>> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> httpclient-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> --
>> yours,
>>
>> Julius Davies
>> 416-652-0183
>> http://juliusdavies.ca/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>>
>
> _________________________________________________________________
> All-in-one security and maintenance for your PC. Get a free 90-day
> trial!
> http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo0050000001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
>
--
Aloha,
Richard Suematsu
SynCaDD Systems, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Jake C <bu...@hotmail.com>.
I had seen that, but at the time I didn't realize that a self-signed cert
could have been my problem. However, I'm sure it is. We are currently
running against a test server, which I'm sure has a self-signed cert. Our
production server will be running under a Verisign cert.
I'll give it a try right now. Do you think that this mean that I most likely
won't have this issue at production? It would be nice to only have to use
the EasySSL* classes during testing.
>From: Roland Weber <ht...@dubioso.net>
>Reply-To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>To: HttpClient User Discussion <ht...@jakarta.apache.org>
>Subject: Re: Certificateless SSL
>Date: Fri, 01 Dec 2006 19:23:06 +0100
>
>Hello Jake,
>
> > Maybe I'm misunderstanding the exception I'm getting. IE is normally
> > used to access the 3rd party application, and it does NOT require us to
> > install or even select a certificate. It DOES prompt us to accept THEIR
> > certificate. We certainly don't have to generate a certificate and
> > install it in a keystore for every client.
>
>There are different kinds of certificates that can be presented and
>verified. So-called "server certificates" are used on the client to
>verify that the server is what it claims to be. "Client certificates"
>are used on the server to verify that the client is what it claims to
>be. And then there are certificates used to verify other certificates.
>Given all these different certificates, your subject "certificateless
>SSL" is really an oxymoron :-)
>If IE does not require you to install a certificate, then most likely
>your problem is not a missing client certificate.
>
> > The exception I'm getting in HttpClient is:
> >
> > [INFO] HttpMethodDirector - I/O exception
> > (javax.net.ssl.SSLHandshakeException) caught when processing request:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > find valid certification path to requested target
>
>A certificate path or chain is a series of certificate to verify other
>certificates. The server sends a certificate, the client checks it with
>another certificate. Then the client checks that other certificate with
>yet another certificate. And so on, until it reaches a "root" certificate
>which it knows can be trusted. IE ships with a set of root certificates,
>and each JDK also ships with a set of root certificates, but those sets
>can be different. I suspect that the certificate store used for your
>SSL connections is missing a root certificate that IE has.
>
> > From what I saw in the mailing list archives, and from a Google search,
> > that meant that I didn't have a certificate installed in JSSE.
>
>Yes. And it's a "root certificate" you are missing, as opposed to a
>"client certificate". That's where you got Julius on a wrong track.
>
>Have you read our SSL guide?
>http://jakarta.apache.org/commons/httpclient/sslguide.html
>
>Towards the end, you'll find a link to the EasySSLProtocolSocketFactory.
>That is a class which does _not_ build a certificate chain in order to
>verify the certificate. Rather, it simply trusts the server certificate,
>which seems to be what you want to do.
>
> > Here is what I get when running the ping utility:
> > [...]
>
>I'll leave this part to Julius :-)
>
>hope that helps,
> Roland
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Roland Weber <ht...@dubioso.net>.
Hello Jake,
> Maybe I'm misunderstanding the exception I'm getting. IE is normally
> used to access the 3rd party application, and it does NOT require us to
> install or even select a certificate. It DOES prompt us to accept THEIR
> certificate. We certainly don't have to generate a certificate and
> install it in a keystore for every client.
There are different kinds of certificates that can be presented and
verified. So-called "server certificates" are used on the client to
verify that the server is what it claims to be. "Client certificates"
are used on the server to verify that the client is what it claims to
be. And then there are certificates used to verify other certificates.
Given all these different certificates, your subject "certificateless
SSL" is really an oxymoron :-)
If IE does not require you to install a certificate, then most likely
your problem is not a missing client certificate.
> The exception I'm getting in HttpClient is:
>
> [INFO] HttpMethodDirector - I/O exception
> (javax.net.ssl.SSLHandshakeException) caught when processing request:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
A certificate path or chain is a series of certificate to verify other
certificates. The server sends a certificate, the client checks it with
another certificate. Then the client checks that other certificate with
yet another certificate. And so on, until it reaches a "root" certificate
which it knows can be trusted. IE ships with a set of root certificates,
and each JDK also ships with a set of root certificates, but those sets
can be different. I suspect that the certificate store used for your
SSL connections is missing a root certificate that IE has.
> From what I saw in the mailing list archives, and from a Google search,
> that meant that I didn't have a certificate installed in JSSE.
Yes. And it's a "root certificate" you are missing, as opposed to a
"client certificate". That's where you got Julius on a wrong track.
Have you read our SSL guide?
http://jakarta.apache.org/commons/httpclient/sslguide.html
Towards the end, you'll find a link to the EasySSLProtocolSocketFactory.
That is a class which does _not_ build a certificate chain in order to
verify the certificate. Rather, it simply trusts the server certificate,
which seems to be what you want to do.
> Here is what I get when running the ping utility:
> [...]
I'll leave this part to Julius :-)
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Jake C <bu...@hotmail.com>.
Thanks for the quick reply!
Maybe I'm misunderstanding the exception I'm getting. IE is normally used to
access the 3rd party application, and it does NOT require us to install or
even select a certificate. It DOES prompt us to accept THEIR certificate. We
certainly don't have to generate a certificate and install it in a keystore
for every client.
The exception I'm getting in HttpClient is:
[INFO] HttpMethodDirector - I/O exception
(javax.net.ssl.SSLHandshakeException) caught when processing request:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
>From what I saw in the mailing list archives, and from a Google search, that
meant that I didn't have a certificate installed in JSSE.
Here is what I get when running the ping utility:
Writing:
================================================================================
HEAD / HTTP/1.1
Host: <IIS Server>
Reading:
================================================================================
HTTP/1.1 200 OK
Content-Length: 1433
Content-Type: text/html
Content-Location: https://<IIS Server>/iisstart.htm
Last-Modified: Sat, 22 Feb 2003 02:48:30 GMT
Accept-Ranges: bytes
ETag: "<ETag>"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Fri, 01 Dec 2006 17:02:43 GMT
Server Certificate for: [<IIS Server>:443]
================================================================================
<IIS Server>
Valid: 2006/Nov/30 - 2007/Nov/30
s: CN=<IIS Server>, OU=<My Department>, O="<My Company>, Inc.", L=<My
State>, ST=<My City>, C=US
i: CN=<IIS Server>, DC=<My Company>, DC=com
-----BEGIN CERTIFICATE-----
<Lots of certificate info>
-----END CERTIFICATE-----
Thanks again for your quick reply, and your help!
>From: "Julius Davies" <ju...@gmail.com>
>Reply-To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>To: "HttpClient User Discussion" <ht...@jakarta.apache.org>
>Subject: Re: Certificateless SSL
>Date: Thu, 30 Nov 2006 23:21:23 -0500
>
>Hi, Jake,
>
>I'll take a stab at this one!
>
>Certificates don't really have much to do with encryption.
>Certificates address the issue of trust. Think about it this way:
>
>How do I know I'm actually talking to "https://web.da-us.citibank.com/"?
>
>That's why they're called "certificates". They really are like a
>virtual piece of paper, nicely framed, with a nice stamp and some
>ribbons, hanging on your Doctor's office wall. "I guess he really
>must be a doctor, because few people have access to those fancy
>ribbons!"
>
>The "trust" works for a few reasons:
>
>- Only Citibank will be able to obtain a certificate for
>"citibank.com" from a root certificate authority (like thawte,
>verisign, many others pre-loaded into your browser).
>
>- (Or, alternatively, if Citibank can't get a certificate for
>"citibank.com", they'll choose a different domain name, and print that
>on all their marketing materials).
>
>- Once Citibank has obtained that first certificate no-one else will
>be able to acquire a new one for the domain, even after the first one
>expires.
>
>The fact that the ROOT CA's already trusted by your browser came
>pre-loaded is important. This means those CA's were installed
>"out-of-band" - through a different medium compared to that through
>which you are conducting your online business. In the case of IE6
>those root CA's presumably came on the CD-ROM that came with Windows
>XP, and NOT over the internet.
>
>(You can then use those out-of-band root ca's to bootstrap your
>acquisition of additional ca's. You now have at least a few (quite a
>few) https:// sites you already trust, and those can provide you with
>additional root ca's. This makes me think that all Firefox downloads
>should be over https, since that is one way we acquire new ROOT ca's -
>by downloading a new browser!.... anyway, confusing digression, you
>can give this paragraph a few months to sink in.)
>
>There's quite a lot of detail behind all of this. For example, how
>does the "citibank.com" certificate get associated with those ROOT
>CA's already loaded in the browser? If someone managed to temporarily
>steal the "citibank.com" domain, why can't they also just steal the
>certificate off of Citibank's website? How does the domain name fit
>into all this? For now let's just assume all this stuff is okay.
>
>Client certificates provide exactly the same service. But now it's a
>question of "how does the server really know that Julius Davies is
>driving that browser?" Usually a username/password is considered
>adequete, so client certificates are quite rare. But they do create a
>2nd factor of authentication. Client certificates could be used to
>dramatically reduce phishing attacks. But it's impractical. The
>thing that's so great about client certs is that they make it harder
>for the public at large to access a given site. The "public" must get
>a username/password, and then they must also acquire a unique client
>cert, install it, and regularly update it because of its expiry cycle!
>As much as CitiBank wants to avoid phishing, they also want their
>customers to be able to access the website without clogging the phone
>lines.
>
>Just like anything, client certs (and server certs) never provide a
>100% bulletproof solution. The private key behind the public
>certificate can be stolen, just like the keys to your house can be
>stolen. A safe that's impossible to open is not useful. A safe that
>can be opened can also be opened by the wrong person.
>
>But client certs do add one more layer of hassle to the bad guy's
>life. "Great, not only do I need to get his username and password, I
>need to get the private key that goes with his client certificate."
>
>
>Onto your question: if IIS is configured to require client certs from
>HTTPClient, then I suspect it's also requiring client certs from your
>browser. Your browser might just not be telling you that it's sending
>the client cert. Are you using Firefox? By default Firefox won't
>bother prompting you to select the client certificate to use. Firefox
>will just automatically provide it to the server. But you can get
>Firefox to always prompt by changing the settings.
>
>(Interesting side note: if Firefox is just automatically providing
>it, that means that the client cert is ultimately protected only by
>your screensaver password. People probably can't "export" the client
>cert to a file without a special admin password, but they can still
>just sit down at your computer and start using the browser. But I
>think that's the right way to go. In the long run (5 years from now?)
>that initial-logon/screensaver password is going to be the only
>password you ever use.)
>
>Perhaps you can try downloading "not-yet-commons-ssl.jar" from
>http://juliusdavies.ca/commons-ssl/. There is a useful "ping" utility
>there to try and help debug HTTPS issues. Can you try running this
>test?
>
>java -jar not-yet-commons-ssl.jar -t [IIS IP]:port
>
>If you recieve this response, then, yeah, your server wants a client
>certificate:
>
>javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
>
>
>I have to signoff now. But I'll be able to respond with part 2
>tomorrow. Sorry I haven't answered all your questions yet.
>
>yours,
>
>Julius
>
>
>
>
>On 11/30/06, Jake C <bu...@hotmail.com> wrote:
>>I am a complete SSL noob, so please pardon me if my questions are silly...
>>:-) I've seen similar questions in the archive, but nothing that really
>>spelled it out.
>>
>>We need an encrypted connection to a 3-rd party application, but we don't
>>need validation. The data being transmitted is validation enough for us.
>>However, the application we are sending to (running on Windows under IIS)
>>is
>>requiring a certificate.
>>
>>I know it is possible to use SSL without requiring a certificate, as the
>>test application at the bottom of the HttpClient SSL Guide works for
>>Verisign, but not for our application.
>>
>>I see two possible ways of getting around this, and I'd just like some
>>validation that these would work the way I want (not requiring our users
>>to
>>mess with certificates).
>>
>>1) Use an Authenticating Proxy Server. We should be able to set up one of
>>these that accepts SSL connections without requiring a certificate, and
>>configure the connection between it and our 3-rd party application using a
>>certificate just for the proxy server, and not for each individual client.
>>
>>2) Modify the IIS configuration of our 3-rd party application so that it
>>doesn't require client certificates, as the data being sent contains the
>>real authentication information. I"m not sure this is really an option, as
>>I
>>don't know IIS at all. We DO have access to the server, though.
>>
>>Do both of these methods work, and encrypt our data? If so, is the
>>encryption in the second case just as strong as if we used client
>>certificates, or is it weaker because there is only a server certificate?
>>Is
>>there any other method I missed?
>>
>>The application we are accessing initially provides a login page, and we
>>just provide a MethodPost with the needed data, so the SSL Connection
>>itself
>>isn't initially authenticated. What I don't really understand is how a
>>generic web browser certificate is any better than no certificate at all.
>>Why is a personal certificate required via HttpClient and not via a web
>>browser?
>>
>>_________________________________________________________________
>>Get FREE company branded e-mail accounts and business Web site from
>>Microsoft Office Live
>>http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>>
>>
>
>
>--
>yours,
>
>Julius Davies
>416-652-0183
>http://juliusdavies.ca/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
_________________________________________________________________
All-in-one security and maintenance for your PC. Get a free 90-day trial!
http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo0050000001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Certificateless SSL
Posted by Julius Davies <ju...@gmail.com>.
Hi, Jake,
I'll take a stab at this one!
Certificates don't really have much to do with encryption.
Certificates address the issue of trust. Think about it this way:
How do I know I'm actually talking to "https://web.da-us.citibank.com/"?
That's why they're called "certificates". They really are like a
virtual piece of paper, nicely framed, with a nice stamp and some
ribbons, hanging on your Doctor's office wall. "I guess he really
must be a doctor, because few people have access to those fancy
ribbons!"
The "trust" works for a few reasons:
- Only Citibank will be able to obtain a certificate for
"citibank.com" from a root certificate authority (like thawte,
verisign, many others pre-loaded into your browser).
- (Or, alternatively, if Citibank can't get a certificate for
"citibank.com", they'll choose a different domain name, and print that
on all their marketing materials).
- Once Citibank has obtained that first certificate no-one else will
be able to acquire a new one for the domain, even after the first one
expires.
The fact that the ROOT CA's already trusted by your browser came
pre-loaded is important. This means those CA's were installed
"out-of-band" - through a different medium compared to that through
which you are conducting your online business. In the case of IE6
those root CA's presumably came on the CD-ROM that came with Windows
XP, and NOT over the internet.
(You can then use those out-of-band root ca's to bootstrap your
acquisition of additional ca's. You now have at least a few (quite a
few) https:// sites you already trust, and those can provide you with
additional root ca's. This makes me think that all Firefox downloads
should be over https, since that is one way we acquire new ROOT ca's -
by downloading a new browser!.... anyway, confusing digression, you
can give this paragraph a few months to sink in.)
There's quite a lot of detail behind all of this. For example, how
does the "citibank.com" certificate get associated with those ROOT
CA's already loaded in the browser? If someone managed to temporarily
steal the "citibank.com" domain, why can't they also just steal the
certificate off of Citibank's website? How does the domain name fit
into all this? For now let's just assume all this stuff is okay.
Client certificates provide exactly the same service. But now it's a
question of "how does the server really know that Julius Davies is
driving that browser?" Usually a username/password is considered
adequete, so client certificates are quite rare. But they do create a
2nd factor of authentication. Client certificates could be used to
dramatically reduce phishing attacks. But it's impractical. The
thing that's so great about client certs is that they make it harder
for the public at large to access a given site. The "public" must get
a username/password, and then they must also acquire a unique client
cert, install it, and regularly update it because of its expiry cycle!
As much as CitiBank wants to avoid phishing, they also want their
customers to be able to access the website without clogging the phone
lines.
Just like anything, client certs (and server certs) never provide a
100% bulletproof solution. The private key behind the public
certificate can be stolen, just like the keys to your house can be
stolen. A safe that's impossible to open is not useful. A safe that
can be opened can also be opened by the wrong person.
But client certs do add one more layer of hassle to the bad guy's
life. "Great, not only do I need to get his username and password, I
need to get the private key that goes with his client certificate."
Onto your question: if IIS is configured to require client certs from
HTTPClient, then I suspect it's also requiring client certs from your
browser. Your browser might just not be telling you that it's sending
the client cert. Are you using Firefox? By default Firefox won't
bother prompting you to select the client certificate to use. Firefox
will just automatically provide it to the server. But you can get
Firefox to always prompt by changing the settings.
(Interesting side note: if Firefox is just automatically providing
it, that means that the client cert is ultimately protected only by
your screensaver password. People probably can't "export" the client
cert to a file without a special admin password, but they can still
just sit down at your computer and start using the browser. But I
think that's the right way to go. In the long run (5 years from now?)
that initial-logon/screensaver password is going to be the only
password you ever use.)
Perhaps you can try downloading "not-yet-commons-ssl.jar" from
http://juliusdavies.ca/commons-ssl/. There is a useful "ping" utility
there to try and help debug HTTPS issues. Can you try running this
test?
java -jar not-yet-commons-ssl.jar -t [IIS IP]:port
If you recieve this response, then, yeah, your server wants a client
certificate:
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
I have to signoff now. But I'll be able to respond with part 2
tomorrow. Sorry I haven't answered all your questions yet.
yours,
Julius
On 11/30/06, Jake C <bu...@hotmail.com> wrote:
> I am a complete SSL noob, so please pardon me if my questions are silly...
> :-) I've seen similar questions in the archive, but nothing that really
> spelled it out.
>
> We need an encrypted connection to a 3-rd party application, but we don't
> need validation. The data being transmitted is validation enough for us.
> However, the application we are sending to (running on Windows under IIS) is
> requiring a certificate.
>
> I know it is possible to use SSL without requiring a certificate, as the
> test application at the bottom of the HttpClient SSL Guide works for
> Verisign, but not for our application.
>
> I see two possible ways of getting around this, and I'd just like some
> validation that these would work the way I want (not requiring our users to
> mess with certificates).
>
> 1) Use an Authenticating Proxy Server. We should be able to set up one of
> these that accepts SSL connections without requiring a certificate, and
> configure the connection between it and our 3-rd party application using a
> certificate just for the proxy server, and not for each individual client.
>
> 2) Modify the IIS configuration of our 3-rd party application so that it
> doesn't require client certificates, as the data being sent contains the
> real authentication information. I"m not sure this is really an option, as I
> don't know IIS at all. We DO have access to the server, though.
>
> Do both of these methods work, and encrypt our data? If so, is the
> encryption in the second case just as strong as if we used client
> certificates, or is it weaker because there is only a server certificate? Is
> there any other method I missed?
>
> The application we are accessing initially provides a login page, and we
> just provide a MethodPost with the needed data, so the SSL Connection itself
> isn't initially authenticated. What I don't really understand is how a
> generic web browser certificate is any better than no certificate at all.
> Why is a personal certificate required via HttpClient and not via a web
> browser?
>
> _________________________________________________________________
> Get FREE company branded e-mail accounts and business Web site from
> Microsoft Office Live
> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org