You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by sebb AT ASF <se...@apache.org> on 2011/11/07 20:20:16 UTC
Re: httpclient version upgrade causing SSL exceptions
On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> I have been seeing SSL exceptions being thrown relating to certificates not
> matching in builds from trunk recently. I have traced this back to a
> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> reverting back to 4.1.1 for the time being?
>
> Looking that the changes that went into 4.1.2, this change looks like it
> might be related to the problem. I have CCed Sebastian, maybe he can
> confirm.
This should really have been fed back to all the HttpComponents
developers via e-mail or JIRA issue; I'm copying the mailing on this
reply.
>
> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and StrictHostnameVerifier
> should handle
> wildcards in SSL certificates better.
> Contributed by Sebastian Bazley <sebb at apache.org>
> INFO: The following exception occurred when fetching
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405 ms
> elapsed.
> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
> fetch
> INFO:
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> <googleapis.com> OR <*.googleapis.com>
> at
It's not obvious why the hostname includes an IP address as well as a name.
I don't yet know if the validation is supposed to cope with that or not.
Also rather odd is that the hostname and IP address do not agree.
It's quite possible that the validation is wrong, and it should allow
for the /IP suffix, but it's also possible that the wrong hostname is
being passed to the validation method.
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> at
> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> at
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> at
> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> at
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> at
> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> at
> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> at
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> at
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> outputError
> INFO: The following error occurred when requesting a concatenated proxy: /*
> ---- Error INTERNAL_SERVER_ERROR
> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> <googleapis.com> OR <*.googleapis.com> ---- */.
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
+1
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Henry Saputra <he...@gmail.com>
To: dev@shindig.apache.org,
Date: 11/10/2011 03:18 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
+1 for another beta release next week.
- Henry
On Thu, Nov 10, 2011 at 10:53 AM, Paul Lindner <li...@inuus.com> wrote:
> It's not too hard to spin off more betas at this point now that all the
> boilerplate and build issues were ironed out for beta3.
>
> Let's decide when the next cut should be. How about early next week?
That
> will give us time to get more code committed.
>
>
> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra
<he...@gmail.com>wrote:
>
>> Yeah I think its not in the beta3 snapshots and since the release is
>> out we need to either deliver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>> > I¹m seeing the same error. I assume this didn¹t make it into the
beta3
>> > snapshot? We try not to use trunk artifacts in our build process.
Am I
>> > gonna have to wait until another beta?
>> >
>> > Thanks,
>> > doug
>> >
>> >
>> > On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>> >
>> >> Looks good so far Paul. I will do some more testing tomorrow.
>> >>
>> >> -Ryan
>> >>
>> >> Email: rjbaxter@us.ibm.com
>> >> Phone: 978-899-3041
>> >> developerWorks Profile
>> >>
>> >>
>> >>
>> >> From: Paul Lindner <li...@inuus.com>
>> >> To: dev@shindig.apache.org,
>> >> Cc: HttpComponents Project <de...@hc.apache.org>
>> >> Date: 11/07/2011 07:27 PM
>> >> Subject: Re: httpclient version upgrade causing SSL
exceptions
>> >>
>> >>
>> >>
>> >> I unreverted the changes and committed since this was already in the
>> >> codebase before.
>> >>
>> >> Let me know if it helps.
>> >>
>> >>
>> >
>> >
>>
>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Any ideas if we'll get another beta before Thanksgiving?
Thanks,
doug
On 11/10/11 3:19 PM, "Henry Saputra" <he...@gmail.com> wrote:
> +1 for another beta release next week.
>
> - Henry
>
> On Thu, Nov 10, 2011 at 10:53 AM, Paul Lindner <li...@inuus.com> wrote:
>> It's not too hard to spin off more betas at this point now that all the
>> boilerplate and build issues were ironed out for beta3.
>>
>> Let's decide when the next cut should be. ?How about early next week? ?That
>> will give us time to get more code committed.
>>
>>
>> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra
>> <he...@gmail.com>wrote:
>>
>>> Yeah I think its not in the beta3 snapshots and since the release is
>>> out we need to either deliver beta3-1 or wait for beta4
>>>
>>> - Henry
>>>
>>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>>>> I¹m seeing the same error. ?I assume this didn¹t make it into the beta3
>>>> snapshot? ?We try not to use trunk artifacts in our build process. ?Am I
>>>> gonna have to wait until another beta?
>>>>
>>>> Thanks,
>>>> doug
>>>>
>>>>
>>>> On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>>>>
>>>>> Looks good so far Paul. ?I will do some more testing tomorrow.
>>>>>
>>>>> -Ryan
>>>>>
>>>>> Email: rjbaxter@us.ibm.com
>>>>> Phone: 978-899-3041
>>>>> developerWorks Profile
>>>>>
>>>>>
>>>>>
>>>>> From: ? Paul Lindner <li...@inuus.com>
>>>>> To: ? ? dev@shindig.apache.org,
>>>>> Cc: ? ? HttpComponents Project <de...@hc.apache.org>
>>>>> Date: ? 11/07/2011 07:27 PM
>>>>> Subject: ? ? ? ?Re: httpclient version upgrade causing SSL exceptions
>>>>>
>>>>>
>>>>>
>>>>> I unreverted the changes and committed since this was already in the
>>>>> codebase before.
>>>>>
>>>>> Let me know if it helps.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Henry Saputra <he...@gmail.com>.
+1 for another beta release next week.
- Henry
On Thu, Nov 10, 2011 at 10:53 AM, Paul Lindner <li...@inuus.com> wrote:
> It's not too hard to spin off more betas at this point now that all the
> boilerplate and build issues were ironed out for beta3.
>
> Let's decide when the next cut should be. How about early next week? That
> will give us time to get more code committed.
>
>
> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra <he...@gmail.com>wrote:
>
>> Yeah I think its not in the beta3 snapshots and since the release is
>> out we need to either deliver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>> > I¹m seeing the same error. I assume this didn¹t make it into the beta3
>> > snapshot? We try not to use trunk artifacts in our build process. Am I
>> > gonna have to wait until another beta?
>> >
>> > Thanks,
>> > doug
>> >
>> >
>> > On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>> >
>> >> Looks good so far Paul. I will do some more testing tomorrow.
>> >>
>> >> -Ryan
>> >>
>> >> Email: rjbaxter@us.ibm.com
>> >> Phone: 978-899-3041
>> >> developerWorks Profile
>> >>
>> >>
>> >>
>> >> From: Paul Lindner <li...@inuus.com>
>> >> To: dev@shindig.apache.org,
>> >> Cc: HttpComponents Project <de...@hc.apache.org>
>> >> Date: 11/07/2011 07:27 PM
>> >> Subject: Re: httpclient version upgrade causing SSL exceptions
>> >>
>> >>
>> >>
>> >> I unreverted the changes and committed since this was already in the
>> >> codebase before.
>> >>
>> >> Let me know if it helps.
>> >>
>> >>
>> >
>> >
>>
>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
Ya, another beta at a stable point would be great. Thanks.
doug
On 11/10/11 1:53 PM, "Paul Lindner" <li...@inuus.com> wrote:
> It's not too hard to spin off more betas at this point now that all the
> boilerplate and build issues were ironed out for beta3.
>
> Let's decide when the next cut should be. How about early next week? That
> will give us time to get more code committed.
>
>
> On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra <he...@gmail.com>wrote:
>
>> Yeah I think its not in the beta3 snapshots and since the release is
>> out we need to either deliver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
>>> I¹m seeing the same error. I assume this didn¹t make it into the beta3
>>> snapshot? We try not to use trunk artifacts in our build process. Am I
>>> gonna have to wait until another beta?
>>>
>>> Thanks,
>>> doug
>>>
>>>
>>> On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>>>
>>>> Looks good so far Paul. I will do some more testing tomorrow.
>>>>
>>>> -Ryan
>>>>
>>>> Email: rjbaxter@us.ibm.com
>>>> Phone: 978-899-3041
>>>> developerWorks Profile
>>>>
>>>>
>>>>
>>>> From: Paul Lindner <li...@inuus.com>
>>>> To: dev@shindig.apache.org,
>>>> Cc: HttpComponents Project <de...@hc.apache.org>
>>>> Date: 11/07/2011 07:27 PM
>>>> Subject: Re: httpclient version upgrade causing SSL exceptions
>>>>
>>>>
>>>>
>>>> I unreverted the changes and committed since this was already in the
>>>> codebase before.
>>>>
>>>> Let me know if it helps.
>>>>
>>>>
>>>
>>>
>>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
It's not too hard to spin off more betas at this point now that all the
boilerplate and build issues were ironed out for beta3.
Let's decide when the next cut should be. How about early next week? That
will give us time to get more code committed.
On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra <he...@gmail.com>wrote:
> Yeah I think its not in the beta3 snapshots and since the release is
> out we need to either deliver beta3-1 or wait for beta4
>
> - Henry
>
> On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
> > I¹m seeing the same error. I assume this didn¹t make it into the beta3
> > snapshot? We try not to use trunk artifacts in our build process. Am I
> > gonna have to wait until another beta?
> >
> > Thanks,
> > doug
> >
> >
> > On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> >
> >> Looks good so far Paul. I will do some more testing tomorrow.
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >>
> >>
> >> From: Paul Lindner <li...@inuus.com>
> >> To: dev@shindig.apache.org,
> >> Cc: HttpComponents Project <de...@hc.apache.org>
> >> Date: 11/07/2011 07:27 PM
> >> Subject: Re: httpclient version upgrade causing SSL exceptions
> >>
> >>
> >>
> >> I unreverted the changes and committed since this was already in the
> >> codebase before.
> >>
> >> Let me know if it helps.
> >>
> >>
> >
> >
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Henry Saputra <he...@gmail.com>.
Yeah I think its not in the beta3 snapshots and since the release is
out we need to either deliver beta3-1 or wait for beta4
- Henry
On Thu, Nov 10, 2011 at 9:37 AM, daviesd <da...@oclc.org> wrote:
> I¹m seeing the same error. I assume this didn¹t make it into the beta3
> snapshot? We try not to use trunk artifacts in our build process. Am I
> gonna have to wait until another beta?
>
> Thanks,
> doug
>
>
> On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>
>> Looks good so far Paul. I will do some more testing tomorrow.
>>
>> -Ryan
>>
>> Email: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>>
>>
>> From: Paul Lindner <li...@inuus.com>
>> To: dev@shindig.apache.org,
>> Cc: HttpComponents Project <de...@hc.apache.org>
>> Date: 11/07/2011 07:27 PM
>> Subject: Re: httpclient version upgrade causing SSL exceptions
>>
>>
>>
>> I unreverted the changes and committed since this was already in the
>> codebase before.
>>
>> Let me know if it helps.
>>
>>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by daviesd <da...@oclc.org>.
I¹m seeing the same error. I assume this didn¹t make it into the beta3
snapshot? We try not to use trunk artifacts in our build process. Am I
gonna have to wait until another beta?
Thanks,
doug
On 11/7/11 8:14 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> Looks good so far Paul. I will do some more testing tomorrow.
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org,
> Cc: HttpComponents Project <de...@hc.apache.org>
> Date: 11/07/2011 07:27 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
>
>
>
> I unreverted the changes and committed since this was already in the
> codebase before.
>
> Let me know if it helps.
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Looks good so far Paul. I will do some more testing tomorrow.
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Paul Lindner <li...@inuus.com>
To: dev@shindig.apache.org,
Cc: HttpComponents Project <de...@hc.apache.org>
Date: 11/07/2011 07:27 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
I unreverted the changes and committed since this was already in the
codebase before.
Let me know if it helps.
On Mon, Nov 7, 2011 at 4:22 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Paul, seems like the right thing to do if we want to use 4.1.2. Do you
> have a link to previous thread on this?
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org,
> Cc: HttpComponents Project <de...@hc.apache.org>, Ryan J
> Baxter/Westford/IBM@Lotus
> Date: 11/07/2011 04:17 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
>
>
>
> I had a patch to use the non-deprecated methods in shindig. It caused
> problems for containers that had not already upgraded so I reverted it.
I
> can bring it back pretty easily.
>
>
> On Mon, Nov 7, 2011 at 11:56 AM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
>
> > On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> > > On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > > > Thanks Sebastian.
> > > >
> > > > I am not to familiar with this part of the code in Shindig but it
> > looks like
> > > > we are just passing the host name, ie https://ajax.googleapis.com,
> to
> > the
> > > > fetcher.
> > >
> > > Yes, I suspect the /IP part is being generated internally by HC
4.1.2.
> > >
> > > > Is there anything we as the the Shindig community can do to help
> > > > out?
> > >
> > > If it's easy to test with 4.2-alpha1, it would help to know if that
is
> > > also affected.
> > >
> > > > -Ryan
> > > >
> >
> > Folks
> >
> > This issue has been beaten to death on a number of occasions. The bug
> > affects deprecated functionality only and it has already been fixed in
> > the 4.2 branch.
> >
> > To fix the problem regardless of the release version just make sure to
> > not use deprecated methods of the Scheme class.
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> > > > Email: rjbaxter@us.ibm.com
> > > > Phone: 978-899-3041
> > > > developerWorks Profile
> > > >
> > > >
> > > >
> > > > From: sebb AT ASF <se...@apache.org>
> > > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > > <de...@hc.apache.org>
> > > > Date: 11/07/2011 02:19 PM
> > > > Subject: Re: httpclient version upgrade causing SSL
> exceptions
> > > > Sent by: sebbaz@gmail.com
> > > > ________________________________
> > > >
> > > >
> > > > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com>
wrote:
> > > >> I have been seeing SSL exceptions being thrown relating to
> > certificates
> > > >> not
> > > >> matching in builds from trunk recently. I have traced this back
to
> a
> > > >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed
to
> > > >> reverting back to 4.1.1 for the time being?
> > > >>
> > > >> Looking that the changes that went into 4.1.2, this change looks
> like
> > it
> > > >> might be related to the problem. I have CCed Sebastian, maybe he
> can
> > > >> confirm.
> > > >
> > > > This should really have been fed back to all the HttpComponents
> > > > developers via e-mail or JIRA issue; I'm copying the mailing on
this
> > > > reply.
> > > >
> > > >>
> > > >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> > > >> StrictHostnameVerifier
> > > >> should handle
> > > >> wildcards in SSL certificates better.
> > > >> Contributed by Sebastian Bazley <sebb at apache.org>
> > > >
> > > >> INFO: The following exception occurred when fetching
> > > >>
> > https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> > > >> elapsed.
> > > >> Nov 7, 2011 1:38:28 PM
> > org.apache.shindig.gadgets.http.BasicHttpFetcher
> > > >> fetch
> > > >> INFO:
> > > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > > >> <googleapis.com> OR <*.googleapis.com>
> > > >> at
> > > >
> > > > It's not obvious why the hostname includes an IP address as well
as
> a
> > name.
> > > > I don't yet know if the validation is supposed to cope with that
or
> > not.
> > > >
> > > > Also rather odd is that the hostname and IP address do not agree.
> > > >
> > > > It's quite possible that the validation is wrong, and it should
> allow
> > > > for the /IP suffix, but it's also possible that the wrong hostname
> is
> > > > being passed to the validation method.
> > > >
> > > >>
> > > >>
> >
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> > > >> at
> > > >>
> > > >>
> >
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> > > >> at
> > > >>
> > > >>
> >
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> > > >> at
> > > >>
> > > >>
> >
>
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> > > >> at
> > > >>
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > > >> at
java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > > >> at
> > > >>
> > > >>
> >
>
>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > > >> at
> > > >>
> > > >>
> >
>
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > > >> at java.lang.Thread.run(Thread.java:662)
> > > >> Nov 7, 2011 1:38:28 PM
> > > >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> > > >> outputError
> > > >> INFO: The following error occurred when requesting a concatenated
> > proxy:
> > > >> /*
> > > >> ---- Error INTERNAL_SERVER_ERROR
> > > >> concat(
> > https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> > > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > > >> <googleapis.com> OR <*.googleapis.com> ---- */.
> > > >>
> > > >> -Ryan
> > > >>
> > > >> Email: rjbaxter@us.ibm.com
> > > >> Phone: 978-899-3041
> > > >> developerWorks Profile
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> >
> >
> >
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
I unreverted the changes and committed since this was already in the
codebase before.
Let me know if it helps.
On Mon, Nov 7, 2011 at 4:22 PM, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Paul, seems like the right thing to do if we want to use 4.1.2. Do you
> have a link to previous thread on this?
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: Paul Lindner <li...@inuus.com>
> To: dev@shindig.apache.org,
> Cc: HttpComponents Project <de...@hc.apache.org>, Ryan J
> Baxter/Westford/IBM@Lotus
> Date: 11/07/2011 04:17 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
>
>
>
> I had a patch to use the non-deprecated methods in shindig. It caused
> problems for containers that had not already upgraded so I reverted it. I
> can bring it back pretty easily.
>
>
> On Mon, Nov 7, 2011 at 11:56 AM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
>
> > On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> > > On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > > > Thanks Sebastian.
> > > >
> > > > I am not to familiar with this part of the code in Shindig but it
> > looks like
> > > > we are just passing the host name, ie https://ajax.googleapis.com,
> to
> > the
> > > > fetcher.
> > >
> > > Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> > >
> > > > Is there anything we as the the Shindig community can do to help
> > > > out?
> > >
> > > If it's easy to test with 4.2-alpha1, it would help to know if that is
> > > also affected.
> > >
> > > > -Ryan
> > > >
> >
> > Folks
> >
> > This issue has been beaten to death on a number of occasions. The bug
> > affects deprecated functionality only and it has already been fixed in
> > the 4.2 branch.
> >
> > To fix the problem regardless of the release version just make sure to
> > not use deprecated methods of the Scheme class.
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> > > > Email: rjbaxter@us.ibm.com
> > > > Phone: 978-899-3041
> > > > developerWorks Profile
> > > >
> > > >
> > > >
> > > > From: sebb AT ASF <se...@apache.org>
> > > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > > <de...@hc.apache.org>
> > > > Date: 11/07/2011 02:19 PM
> > > > Subject: Re: httpclient version upgrade causing SSL
> exceptions
> > > > Sent by: sebbaz@gmail.com
> > > > ________________________________
> > > >
> > > >
> > > > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > > >> I have been seeing SSL exceptions being thrown relating to
> > certificates
> > > >> not
> > > >> matching in builds from trunk recently. I have traced this back to
> a
> > > >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> > > >> reverting back to 4.1.1 for the time being?
> > > >>
> > > >> Looking that the changes that went into 4.1.2, this change looks
> like
> > it
> > > >> might be related to the problem. I have CCed Sebastian, maybe he
> can
> > > >> confirm.
> > > >
> > > > This should really have been fed back to all the HttpComponents
> > > > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > > > reply.
> > > >
> > > >>
> > > >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> > > >> StrictHostnameVerifier
> > > >> should handle
> > > >> wildcards in SSL certificates better.
> > > >> Contributed by Sebastian Bazley <sebb at apache.org>
> > > >
> > > >> INFO: The following exception occurred when fetching
> > > >>
> > https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> > > >> elapsed.
> > > >> Nov 7, 2011 1:38:28 PM
> > org.apache.shindig.gadgets.http.BasicHttpFetcher
> > > >> fetch
> > > >> INFO:
> > > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > > >> <googleapis.com> OR <*.googleapis.com>
> > > >> at
> > > >
> > > > It's not obvious why the hostname includes an IP address as well as
> a
> > name.
> > > > I don't yet know if the validation is supposed to cope with that or
> > not.
> > > >
> > > > Also rather odd is that the hostname and IP address do not agree.
> > > >
> > > > It's quite possible that the validation is wrong, and it should
> allow
> > > > for the /IP suffix, but it's also possible that the wrong hostname
> is
> > > > being passed to the validation method.
> > > >
> > > >>
> > > >>
> >
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> > > >> at
> > > >>
> > > >>
> >
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> > > >> at
> > > >>
> > > >>
> >
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> > > >> at
> > > >>
> > > >>
> >
>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> > > >> at
> > > >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > > >> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > > >> at
> > > >>
> > > >>
> >
>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > > >> at
> > > >>
> > > >>
> >
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > > >> at java.lang.Thread.run(Thread.java:662)
> > > >> Nov 7, 2011 1:38:28 PM
> > > >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> > > >> outputError
> > > >> INFO: The following error occurred when requesting a concatenated
> > proxy:
> > > >> /*
> > > >> ---- Error INTERNAL_SERVER_ERROR
> > > >> concat(
> > https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> > > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > > >> <googleapis.com> OR <*.googleapis.com> ---- */.
> > > >>
> > > >> -Ryan
> > > >>
> > > >> Email: rjbaxter@us.ibm.com
> > > >> Phone: 978-899-3041
> > > >> developerWorks Profile
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> >
> >
> >
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Paul, seems like the right thing to do if we want to use 4.1.2. Do you
have a link to previous thread on this?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: Paul Lindner <li...@inuus.com>
To: dev@shindig.apache.org,
Cc: HttpComponents Project <de...@hc.apache.org>, Ryan J
Baxter/Westford/IBM@Lotus
Date: 11/07/2011 04:17 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
I had a patch to use the non-deprecated methods in shindig. It caused
problems for containers that had not already upgraded so I reverted it. I
can bring it back pretty easily.
On Mon, Nov 7, 2011 at 11:56 AM, Oleg Kalnichevski <ol...@apache.org>
wrote:
> On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> > On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > > Thanks Sebastian.
> > >
> > > I am not to familiar with this part of the code in Shindig but it
> looks like
> > > we are just passing the host name, ie https://ajax.googleapis.com,
to
> the
> > > fetcher.
> >
> > Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> >
> > > Is there anything we as the the Shindig community can do to help
> > > out?
> >
> > If it's easy to test with 4.2-alpha1, it would help to know if that is
> > also affected.
> >
> > > -Ryan
> > >
>
> Folks
>
> This issue has been beaten to death on a number of occasions. The bug
> affects deprecated functionality only and it has already been fixed in
> the 4.2 branch.
>
> To fix the problem regardless of the release version just make sure to
> not use deprecated methods of the Scheme class.
>
> Hope this helps
>
> Oleg
>
>
> > > Email: rjbaxter@us.ibm.com
> > > Phone: 978-899-3041
> > > developerWorks Profile
> > >
> > >
> > >
> > > From: sebb AT ASF <se...@apache.org>
> > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > <de...@hc.apache.org>
> > > Date: 11/07/2011 02:19 PM
> > > Subject: Re: httpclient version upgrade causing SSL
exceptions
> > > Sent by: sebbaz@gmail.com
> > > ________________________________
> > >
> > >
> > > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > >> I have been seeing SSL exceptions being thrown relating to
> certificates
> > >> not
> > >> matching in builds from trunk recently. I have traced this back to
a
> > >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> > >> reverting back to 4.1.1 for the time being?
> > >>
> > >> Looking that the changes that went into 4.1.2, this change looks
like
> it
> > >> might be related to the problem. I have CCed Sebastian, maybe he
can
> > >> confirm.
> > >
> > > This should really have been fed back to all the HttpComponents
> > > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > > reply.
> > >
> > >>
> > >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> > >> StrictHostnameVerifier
> > >> should handle
> > >> wildcards in SSL certificates better.
> > >> Contributed by Sebastian Bazley <sebb at apache.org>
> > >
> > >> INFO: The following exception occurred when fetching
> > >>
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> > >> elapsed.
> > >> Nov 7, 2011 1:38:28 PM
> org.apache.shindig.gadgets.http.BasicHttpFetcher
> > >> fetch
> > >> INFO:
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com>
> > >> at
> > >
> > > It's not obvious why the hostname includes an IP address as well as
a
> name.
> > > I don't yet know if the validation is supposed to cope with that or
> not.
> > >
> > > Also rather odd is that the hostname and IP address do not agree.
> > >
> > > It's quite possible that the validation is wrong, and it should
allow
> > > for the /IP suffix, but it's also possible that the wrong hostname
is
> > > being passed to the validation method.
> > >
> > >>
> > >>
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> > >> at
> > >>
> > >>
>
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> > >> at
> > >>
> > >>
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> > >> at
> > >>
> > >>
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> > >> at
> > >>
> > >>
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> > >> at
> > >>
> > >>
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> > >> at
> > >>
> > >>
>
org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> > >> at
> > >>
> > >>
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> > >> at
> > >>
> > >>
>
org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> > >> at
> > >>
> > >>
>
org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> > >> at
> > >>
> > >>
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> > >> at
> > >>
> > >>
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> > >> at
> > >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > >> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > >> at
> > >>
> > >>
>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > >> at
> > >>
> > >>
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > >> at java.lang.Thread.run(Thread.java:662)
> > >> Nov 7, 2011 1:38:28 PM
> > >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> > >> outputError
> > >> INFO: The following error occurred when requesting a concatenated
> proxy:
> > >> /*
> > >> ---- Error INTERNAL_SERVER_ERROR
> > >> concat(
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com> ---- */.
> > >>
> > >> -Ryan
> > >>
> > >> Email: rjbaxter@us.ibm.com
> > >> Phone: 978-899-3041
> > >> developerWorks Profile
> > >>
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
I had a patch to use the non-deprecated methods in shindig. It caused
problems for containers that had not already upgraded so I reverted it. I
can bring it back pretty easily.
On Mon, Nov 7, 2011 at 11:56 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> > On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > > Thanks Sebastian.
> > >
> > > I am not to familiar with this part of the code in Shindig but it
> looks like
> > > we are just passing the host name, ie https://ajax.googleapis.com, to
> the
> > > fetcher.
> >
> > Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> >
> > > Is there anything we as the the Shindig community can do to help
> > > out?
> >
> > If it's easy to test with 4.2-alpha1, it would help to know if that is
> > also affected.
> >
> > > -Ryan
> > >
>
> Folks
>
> This issue has been beaten to death on a number of occasions. The bug
> affects deprecated functionality only and it has already been fixed in
> the 4.2 branch.
>
> To fix the problem regardless of the release version just make sure to
> not use deprecated methods of the Scheme class.
>
> Hope this helps
>
> Oleg
>
>
> > > Email: rjbaxter@us.ibm.com
> > > Phone: 978-899-3041
> > > developerWorks Profile
> > >
> > >
> > >
> > > From: sebb AT ASF <se...@apache.org>
> > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > <de...@hc.apache.org>
> > > Date: 11/07/2011 02:19 PM
> > > Subject: Re: httpclient version upgrade causing SSL exceptions
> > > Sent by: sebbaz@gmail.com
> > > ________________________________
> > >
> > >
> > > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > >> I have been seeing SSL exceptions being thrown relating to
> certificates
> > >> not
> > >> matching in builds from trunk recently. I have traced this back to a
> > >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> > >> reverting back to 4.1.1 for the time being?
> > >>
> > >> Looking that the changes that went into 4.1.2, this change looks like
> it
> > >> might be related to the problem. I have CCed Sebastian, maybe he can
> > >> confirm.
> > >
> > > This should really have been fed back to all the HttpComponents
> > > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > > reply.
> > >
> > >>
> > >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> > >> StrictHostnameVerifier
> > >> should handle
> > >> wildcards in SSL certificates better.
> > >> Contributed by Sebastian Bazley <sebb at apache.org>
> > >
> > >> INFO: The following exception occurred when fetching
> > >>
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> > >> elapsed.
> > >> Nov 7, 2011 1:38:28 PM
> org.apache.shindig.gadgets.http.BasicHttpFetcher
> > >> fetch
> > >> INFO:
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com>
> > >> at
> > >
> > > It's not obvious why the hostname includes an IP address as well as a
> name.
> > > I don't yet know if the validation is supposed to cope with that or
> not.
> > >
> > > Also rather odd is that the hostname and IP address do not agree.
> > >
> > > It's quite possible that the validation is wrong, and it should allow
> > > for the /IP suffix, but it's also possible that the wrong hostname is
> > > being passed to the validation method.
> > >
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> > >> at
> > >>
> > >>
> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> > >> at
> > >>
> > >>
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> > >> at
> > >>
> > >>
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> > >> at
> > >>
> > >>
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> > >> at
> > >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > >> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > >> at
> > >>
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > >> at
> > >>
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > >> at java.lang.Thread.run(Thread.java:662)
> > >> Nov 7, 2011 1:38:28 PM
> > >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> > >> outputError
> > >> INFO: The following error occurred when requesting a concatenated
> proxy:
> > >> /*
> > >> ---- Error INTERNAL_SERVER_ERROR
> > >> concat(
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com> ---- */.
> > >>
> > >> -Ryan
> > >>
> > >> Email: rjbaxter@us.ibm.com
> > >> Phone: 978-899-3041
> > >> developerWorks Profile
> > >>
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Paul Lindner <li...@inuus.com>.
I had a patch to use the non-deprecated methods in shindig. It caused
problems for containers that had not already upgraded so I reverted it. I
can bring it back pretty easily.
On Mon, Nov 7, 2011 at 11:56 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> > On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > > Thanks Sebastian.
> > >
> > > I am not to familiar with this part of the code in Shindig but it
> looks like
> > > we are just passing the host name, ie https://ajax.googleapis.com, to
> the
> > > fetcher.
> >
> > Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> >
> > > Is there anything we as the the Shindig community can do to help
> > > out?
> >
> > If it's easy to test with 4.2-alpha1, it would help to know if that is
> > also affected.
> >
> > > -Ryan
> > >
>
> Folks
>
> This issue has been beaten to death on a number of occasions. The bug
> affects deprecated functionality only and it has already been fixed in
> the 4.2 branch.
>
> To fix the problem regardless of the release version just make sure to
> not use deprecated methods of the Scheme class.
>
> Hope this helps
>
> Oleg
>
>
> > > Email: rjbaxter@us.ibm.com
> > > Phone: 978-899-3041
> > > developerWorks Profile
> > >
> > >
> > >
> > > From: sebb AT ASF <se...@apache.org>
> > > To: Ryan J Baxter/Westford/IBM@Lotus,
> > > Cc: dev@shindig.apache.org, HttpComponents Project
> > > <de...@hc.apache.org>
> > > Date: 11/07/2011 02:19 PM
> > > Subject: Re: httpclient version upgrade causing SSL exceptions
> > > Sent by: sebbaz@gmail.com
> > > ________________________________
> > >
> > >
> > > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > >> I have been seeing SSL exceptions being thrown relating to
> certificates
> > >> not
> > >> matching in builds from trunk recently. I have traced this back to a
> > >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> > >> reverting back to 4.1.1 for the time being?
> > >>
> > >> Looking that the changes that went into 4.1.2, this change looks like
> it
> > >> might be related to the problem. I have CCed Sebastian, maybe he can
> > >> confirm.
> > >
> > > This should really have been fed back to all the HttpComponents
> > > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > > reply.
> > >
> > >>
> > >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> > >> StrictHostnameVerifier
> > >> should handle
> > >> wildcards in SSL certificates better.
> > >> Contributed by Sebastian Bazley <sebb at apache.org>
> > >
> > >> INFO: The following exception occurred when fetching
> > >>
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> > >> elapsed.
> > >> Nov 7, 2011 1:38:28 PM
> org.apache.shindig.gadgets.http.BasicHttpFetcher
> > >> fetch
> > >> INFO:
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com>
> > >> at
> > >
> > > It's not obvious why the hostname includes an IP address as well as a
> name.
> > > I don't yet know if the validation is supposed to cope with that or
> not.
> > >
> > > Also rather odd is that the hostname and IP address do not agree.
> > >
> > > It's quite possible that the validation is wrong, and it should allow
> > > for the /IP suffix, but it's also possible that the wrong hostname is
> > > being passed to the validation method.
> > >
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> > >> at
> > >>
> > >>
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> > >> at
> > >>
> > >>
> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> > >> at
> > >>
> > >>
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> > >> at
> > >>
> > >>
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> > >> at
> > >>
> > >>
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> > >> at
> > >>
> > >>
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> > >> at
> > >>
> > >>
> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> > >> at
> > >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> > >> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> > >> at
> > >>
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> > >> at
> > >>
> > >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> > >> at java.lang.Thread.run(Thread.java:662)
> > >> Nov 7, 2011 1:38:28 PM
> > >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> > >> outputError
> > >> INFO: The following error occurred when requesting a concatenated
> proxy:
> > >> /*
> > >> ---- Error INTERNAL_SERVER_ERROR
> > >> concat(
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> > >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> > >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> > >> <googleapis.com> OR <*.googleapis.com> ---- */.
> > >>
> > >> -Ryan
> > >>
> > >> Email: rjbaxter@us.ibm.com
> > >> Phone: 978-899-3041
> > >> developerWorks Profile
> > >>
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: httpclient version upgrade causing SSL exceptions
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > Thanks Sebastian.
> >
> > I am not to familiar with this part of the code in Shindig but it looks like
> > we are just passing the host name, ie https://ajax.googleapis.com, to the
> > fetcher.
>
> Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
>
> > Is there anything we as the the Shindig community can do to help
> > out?
>
> If it's easy to test with 4.2-alpha1, it would help to know if that is
> also affected.
>
> > -Ryan
> >
Folks
This issue has been beaten to death on a number of occasions. The bug
affects deprecated functionality only and it has already been fixed in
the 4.2 branch.
To fix the problem regardless of the release version just make sure to
not use deprecated methods of the Scheme class.
Hope this helps
Oleg
> > Email: rjbaxter@us.ibm.com
> > Phone: 978-899-3041
> > developerWorks Profile
> >
> >
> >
> > From: sebb AT ASF <se...@apache.org>
> > To: Ryan J Baxter/Westford/IBM@Lotus,
> > Cc: dev@shindig.apache.org, HttpComponents Project
> > <de...@hc.apache.org>
> > Date: 11/07/2011 02:19 PM
> > Subject: Re: httpclient version upgrade causing SSL exceptions
> > Sent by: sebbaz@gmail.com
> > ________________________________
> >
> >
> > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> >> I have been seeing SSL exceptions being thrown relating to certificates
> >> not
> >> matching in builds from trunk recently. I have traced this back to a
> >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> >> reverting back to 4.1.1 for the time being?
> >>
> >> Looking that the changes that went into 4.1.2, this change looks like it
> >> might be related to the problem. I have CCed Sebastian, maybe he can
> >> confirm.
> >
> > This should really have been fed back to all the HttpComponents
> > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > reply.
> >
> >>
> >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> >> StrictHostnameVerifier
> >> should handle
> >> wildcards in SSL certificates better.
> >> Contributed by Sebastian Bazley <sebb at apache.org>
> >
> >> INFO: The following exception occurred when fetching
> >> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> >> elapsed.
> >> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
> >> fetch
> >> INFO:
> >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> >> <googleapis.com> OR <*.googleapis.com>
> >> at
> >
> > It's not obvious why the hostname includes an IP address as well as a name.
> > I don't yet know if the validation is supposed to cope with that or not.
> >
> > Also rather odd is that the hostname and IP address do not agree.
> >
> > It's quite possible that the validation is wrong, and it should allow
> > for the /IP suffix, but it's also possible that the wrong hostname is
> > being passed to the validation method.
> >
> >>
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> >> at
> >>
> >> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> >> at
> >>
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> >> at
> >>
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> >> at
> >>
> >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> >> at
> >>
> >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> >> at
> >>
> >> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> >> at
> >>
> >> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> >> at
> >>
> >> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> >> at
> >>
> >> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> >> at
> >>
> >> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> >> at
> >>
> >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> >> at
> >>
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> >> at
> >>
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> >> at
> >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> >> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> >> at
> >>
> >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> >> at
> >>
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> >> at java.lang.Thread.run(Thread.java:662)
> >> Nov 7, 2011 1:38:28 PM
> >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> >> outputError
> >> INFO: The following error occurred when requesting a concatenated proxy:
> >> /*
> >> ---- Error INTERNAL_SERVER_ERROR
> >> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> >> <googleapis.com> OR <*.googleapis.com> ---- */.
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2011-11-07 at 19:33 +0000, sebb AT ASF wrote:
> On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> > Thanks Sebastian.
> >
> > I am not to familiar with this part of the code in Shindig but it looks like
> > we are just passing the host name, ie https://ajax.googleapis.com, to the
> > fetcher.
>
> Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
>
> > Is there anything we as the the Shindig community can do to help
> > out?
>
> If it's easy to test with 4.2-alpha1, it would help to know if that is
> also affected.
>
> > -Ryan
> >
Folks
This issue has been beaten to death on a number of occasions. The bug
affects deprecated functionality only and it has already been fixed in
the 4.2 branch.
To fix the problem regardless of the release version just make sure to
not use deprecated methods of the Scheme class.
Hope this helps
Oleg
> > Email: rjbaxter@us.ibm.com
> > Phone: 978-899-3041
> > developerWorks Profile
> >
> >
> >
> > From: sebb AT ASF <se...@apache.org>
> > To: Ryan J Baxter/Westford/IBM@Lotus,
> > Cc: dev@shindig.apache.org, HttpComponents Project
> > <de...@hc.apache.org>
> > Date: 11/07/2011 02:19 PM
> > Subject: Re: httpclient version upgrade causing SSL exceptions
> > Sent by: sebbaz@gmail.com
> > ________________________________
> >
> >
> > On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> >> I have been seeing SSL exceptions being thrown relating to certificates
> >> not
> >> matching in builds from trunk recently. I have traced this back to a
> >> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> >> reverting back to 4.1.1 for the time being?
> >>
> >> Looking that the changes that went into 4.1.2, this change looks like it
> >> might be related to the problem. I have CCed Sebastian, maybe he can
> >> confirm.
> >
> > This should really have been fed back to all the HttpComponents
> > developers via e-mail or JIRA issue; I'm copying the mailing on this
> > reply.
> >
> >>
> >> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
> >> StrictHostnameVerifier
> >> should handle
> >> wildcards in SSL certificates better.
> >> Contributed by Sebastian Bazley <sebb at apache.org>
> >
> >> INFO: The following exception occurred when fetching
> >> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
> >> elapsed.
> >> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
> >> fetch
> >> INFO:
> >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> >> <googleapis.com> OR <*.googleapis.com>
> >> at
> >
> > It's not obvious why the hostname includes an IP address as well as a name.
> > I don't yet know if the validation is supposed to cope with that or not.
> >
> > Also rather odd is that the hostname and IP address do not agree.
> >
> > It's quite possible that the validation is wrong, and it should allow
> > for the /IP suffix, but it's also possible that the wrong hostname is
> > being passed to the validation method.
> >
> >>
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> >> at
> >>
> >> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> >> at
> >>
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> >> at
> >>
> >> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> >> at
> >>
> >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> >> at
> >>
> >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> >> at
> >>
> >> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> >> at
> >>
> >> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> >> at
> >>
> >> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> >> at
> >>
> >> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> >> at
> >>
> >> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> >> at
> >>
> >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> >> at
> >>
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> >> at
> >>
> >> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> >> at
> >>
> >> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> >> at
> >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> >> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> >> at
> >>
> >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> >> at
> >>
> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> >> at java.lang.Thread.run(Thread.java:662)
> >> Nov 7, 2011 1:38:28 PM
> >> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> >> outputError
> >> INFO: The following error occurred when requesting a concatenated proxy:
> >> /*
> >> ---- Error INTERNAL_SERVER_ERROR
> >> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> >> javax.net.ssl.SSLException: hostname in certificate didn't match:
> >> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> >> <googleapis.com> OR <*.googleapis.com> ---- */.
> >>
> >> -Ryan
> >>
> >> Email: rjbaxter@us.ibm.com
> >> Phone: 978-899-3041
> >> developerWorks Profile
> >>
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: httpclient version upgrade causing SSL exceptions
Posted by sebb AT ASF <se...@apache.org>.
On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Thanks Sebastian.
>
> I am not to familiar with this part of the code in Shindig but it looks like
> we are just passing the host name, ie https://ajax.googleapis.com, to the
> fetcher.
Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> Is there anything we as the the Shindig community can do to help
> out?
If it's easy to test with 4.2-alpha1, it would help to know if that is
also affected.
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: sebb AT ASF <se...@apache.org>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: dev@shindig.apache.org, HttpComponents Project
> <de...@hc.apache.org>
> Date: 11/07/2011 02:19 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
> Sent by: sebbaz@gmail.com
> ________________________________
>
>
> On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
>> I have been seeing SSL exceptions being thrown relating to certificates
>> not
>> matching in builds from trunk recently. I have traced this back to a
>> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
>> reverting back to 4.1.1 for the time being?
>>
>> Looking that the changes that went into 4.1.2, this change looks like it
>> might be related to the problem. I have CCed Sebastian, maybe he can
>> confirm.
>
> This should really have been fed back to all the HttpComponents
> developers via e-mail or JIRA issue; I'm copying the mailing on this
> reply.
>
>>
>> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
>> StrictHostnameVerifier
>> should handle
>> wildcards in SSL certificates better.
>> Contributed by Sebastian Bazley <sebb at apache.org>
>
>> INFO: The following exception occurred when fetching
>> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
>> elapsed.
>> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
>> fetch
>> INFO:
>> javax.net.ssl.SSLException: hostname in certificate didn't match:
>> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
>> <googleapis.com> OR <*.googleapis.com>
>> at
>
> It's not obvious why the hostname includes an IP address as well as a name.
> I don't yet know if the validation is supposed to cope with that or not.
>
> Also rather odd is that the hostname and IP address do not agree.
>
> It's quite possible that the validation is wrong, and it should allow
> for the /IP suffix, but it's also possible that the wrong hostname is
> being passed to the validation method.
>
>>
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
>> at
>>
>> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
>> at
>>
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
>> at
>>
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
>> at
>>
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
>> at
>>
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
>> at
>>
>> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
>> at
>>
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
>> at
>>
>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
>> at
>>
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
>> at
>>
>> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
>> at
>>
>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
>> at
>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>> at
>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
>> at
>>
>> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
>> at
>>
>> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
>> at
>>
>> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
>> at
>>
>> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:662)
>> Nov 7, 2011 1:38:28 PM
>> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
>> outputError
>> INFO: The following error occurred when requesting a concatenated proxy:
>> /*
>> ---- Error INTERNAL_SERVER_ERROR
>> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
>> javax.net.ssl.SSLException: hostname in certificate didn't match:
>> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
>> <googleapis.com> OR <*.googleapis.com> ---- */.
>>
>> -Ryan
>>
>> Email: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: httpclient version upgrade causing SSL exceptions
Posted by sebb AT ASF <se...@apache.org>.
On 7 November 2011 19:28, Ryan J Baxter <rj...@us.ibm.com> wrote:
> Thanks Sebastian.
>
> I am not to familiar with this part of the code in Shindig but it looks like
> we are just passing the host name, ie https://ajax.googleapis.com, to the
> fetcher.
Yes, I suspect the /IP part is being generated internally by HC 4.1.2.
> Is there anything we as the the Shindig community can do to help
> out?
If it's easy to test with 4.2-alpha1, it would help to know if that is
also affected.
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: sebb AT ASF <se...@apache.org>
> To: Ryan J Baxter/Westford/IBM@Lotus,
> Cc: dev@shindig.apache.org, HttpComponents Project
> <de...@hc.apache.org>
> Date: 11/07/2011 02:19 PM
> Subject: Re: httpclient version upgrade causing SSL exceptions
> Sent by: sebbaz@gmail.com
> ________________________________
>
>
> On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
>> I have been seeing SSL exceptions being thrown relating to certificates
>> not
>> matching in builds from trunk recently. I have traced this back to a
>> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
>> reverting back to 4.1.1 for the time being?
>>
>> Looking that the changes that went into 4.1.2, this change looks like it
>> might be related to the problem. I have CCed Sebastian, maybe he can
>> confirm.
>
> This should really have been fed back to all the HttpComponents
> developers via e-mail or JIRA issue; I'm copying the mailing on this
> reply.
>
>>
>> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
>> StrictHostnameVerifier
>> should handle
>> wildcards in SSL certificates better.
>> Contributed by Sebastian Bazley <sebb at apache.org>
>
>> INFO: The following exception occurred when fetching
>> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405ms
>> elapsed.
>> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
>> fetch
>> INFO:
>> javax.net.ssl.SSLException: hostname in certificate didn't match:
>> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
>> <googleapis.com> OR <*.googleapis.com>
>> at
>
> It's not obvious why the hostname includes an IP address as well as a name.
> I don't yet know if the validation is supposed to cope with that or not.
>
> Also rather odd is that the hostname and IP address do not agree.
>
> It's quite possible that the validation is wrong, and it should allow
> for the /IP suffix, but it's also possible that the wrong hostname is
> being passed to the validation method.
>
>>
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
>> at
>>
>> org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
>> at
>>
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
>> at
>>
>> org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
>> at
>>
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
>> at
>>
>> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
>> at
>>
>> org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
>> at
>>
>> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
>> at
>>
>> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
>> at
>>
>> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
>> at
>>
>> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
>> at
>>
>> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
>> at
>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>> at
>>
>> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
>> at
>>
>> org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
>> at
>>
>> org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
>> at
>>
>> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
>> at
>>
>> org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
>> at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:662)
>> Nov 7, 2011 1:38:28 PM
>> org.apache.shindig.gadgets.servlet.ConcatProxyServlet
>> outputError
>> INFO: The following error occurred when requesting a concatenated proxy:
>> /*
>> ---- Error INTERNAL_SERVER_ERROR
>> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
>> javax.net.ssl.SSLException: hostname in certificate didn't match:
>> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
>> <googleapis.com> OR <*.googleapis.com> ---- */.
>>
>> -Ryan
>>
>> Email: rjbaxter@us.ibm.com
>> Phone: 978-899-3041
>> developerWorks Profile
>>
>
>
>
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Thanks Sebastian.
I am not to familiar with this part of the code in Shindig but it looks
like we are just passing the host name, ie https://ajax.googleapis.com, to
the fetcher. Is there anything we as the the Shindig community can do to
help out?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: sebb AT ASF <se...@apache.org>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: dev@shindig.apache.org, HttpComponents Project <de...@hc.apache.org>
Date: 11/07/2011 02:19 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
Sent by: sebbaz@gmail.com
On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> I have been seeing SSL exceptions being thrown relating to certificates
not
> matching in builds from trunk recently. I have traced this back to a
> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> reverting back to 4.1.1 for the time being?
>
> Looking that the changes that went into 4.1.2, this change looks like it
> might be related to the problem. I have CCed Sebastian, maybe he can
> confirm.
This should really have been fed back to all the HttpComponents
developers via e-mail or JIRA issue; I'm copying the mailing on this
reply.
>
> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
StrictHostnameVerifier
> should handle
> wildcards in SSL certificates better.
> Contributed by Sebastian Bazley <sebb at apache.org>
> INFO: The following exception occurred when fetching
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405 ms
> elapsed.
> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
> fetch
> INFO:
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> <googleapis.com> OR <*.googleapis.com>
> at
It's not obvious why the hostname includes an IP address as well as a
name.
I don't yet know if the validation is supposed to cope with that or not.
Also rather odd is that the hostname and IP address do not agree.
It's quite possible that the validation is wrong, and it should allow
for the /IP suffix, but it's also possible that the wrong hostname is
being passed to the validation method.
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> at
>
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> at
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> at
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> at
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> at
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> at
>
org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> at
>
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> at
>
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> at
>
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> at
>
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> at
>
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> at
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> at
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> at
>
org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> at
>
org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> at
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> at
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Nov 7, 2011 1:38:28 PM
org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> outputError
> INFO: The following error occurred when requesting a concatenated proxy:
/*
> ---- Error INTERNAL_SERVER_ERROR
> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> <googleapis.com> OR <*.googleapis.com> ---- */.
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
Re: httpclient version upgrade causing SSL exceptions
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Thanks Sebastian.
I am not to familiar with this part of the code in Shindig but it looks
like we are just passing the host name, ie https://ajax.googleapis.com, to
the fetcher. Is there anything we as the the Shindig community can do to
help out?
-Ryan
Email: rjbaxter@us.ibm.com
Phone: 978-899-3041
developerWorks Profile
From: sebb AT ASF <se...@apache.org>
To: Ryan J Baxter/Westford/IBM@Lotus,
Cc: dev@shindig.apache.org, HttpComponents Project <de...@hc.apache.org>
Date: 11/07/2011 02:19 PM
Subject: Re: httpclient version upgrade causing SSL exceptions
Sent by: sebbaz@gmail.com
On 7 November 2011 18:45, Ryan J Baxter <rj...@us.ibm.com> wrote:
> I have been seeing SSL exceptions being thrown relating to certificates
not
> matching in builds from trunk recently. I have traced this back to a
> httpclient upgrade from 4.1.1 to 4.1.2. Would anyone be opposed to
> reverting back to 4.1.1 for the time being?
>
> Looking that the changes that went into 4.1.2, this change looks like it
> might be related to the problem. I have CCed Sebastian, maybe he can
> confirm.
This should really have been fed back to all the HttpComponents
developers via e-mail or JIRA issue; I'm copying the mailing on this
reply.
>
> * [HTTPCLIENT-1097] BrowserCompatHostnameVerifier and
StrictHostnameVerifier
> should handle
> wildcards in SSL certificates better.
> Contributed by Sebastian Bazley <sebb at apache.org>
> INFO: The following exception occurred when fetching
> https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js:405 ms
> elapsed.
> Nov 7, 2011 1:38:28 PM org.apache.shindig.gadgets.http.BasicHttpFetcher
> fetch
> INFO:
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> <googleapis.com> OR <*.googleapis.com>
> at
It's not obvious why the hostname includes an IP address as well as a
name.
I don't yet know if the validation is supposed to cope with that or not.
Also rather odd is that the hostname and IP address do not agree.
It's quite possible that the validation is wrong, and it should allow
for the /IP suffix, but it's also possible that the wrong hostname is
being passed to the validation method.
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)
> at
>
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
> at
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149)
> at
>
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130)
> at
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:397)
> at
>
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:495)
> at
>
org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:62)
> at
>
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
> at
>
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
> at
>
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
> at
>
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
> at
>
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
> at
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
> at
>
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
> at
>
org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:361)
> at
>
org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:108)
> at
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:105)
> at
>
org.apache.shindig.gadgets.http.MultipleResourceHttpFetcher$HttpFetchCallable.call(MultipleResourceHttpFetcher.java:92)
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Nov 7, 2011 1:38:28 PM
org.apache.shindig.gadgets.servlet.ConcatProxyServlet
> outputError
> INFO: The following error occurred when requesting a concatenated proxy:
/*
> ---- Error INTERNAL_SERVER_ERROR
> concat(https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js)
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <ajax.googleapis.com/74.125.115.95> != <*.googleapis.com> OR
> <googleapis.com> OR <*.googleapis.com> ---- */.
>
> -Ryan
>
> Email: rjbaxter@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>