Hi Tony,
Good to hear that the sample application worked, but all I was really trying to
give you with that reference was how to turn on the tracing in the java.net
API's -- so basically just using the "-Djavax.net.debug=all" flag when firing
up the JVM running tomcat.
I just ran through it myself as a quick test and was able to get the kind of
debug output on the console I was thinking would be helpful for you -- here is
what I did:
-- I'm using a "standalone" (not the .exe installer version) Tomcat 6 on
Windows for my testing.
-- I edited the end of startup.bat -- changing it from this:
call "%EXECUTABLE%" start %CMD_LINE_ARGS%
:end
to this:
set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.debug=all
call "%EXECUTABLE%" start %CMD_LINE_ARGS%
:end
-- Deployed a clean version of shindig built from trunk using the modified
startup script.
-- When Tomcat fires up I immediately see a digest of all the stuff in my local
trust store (which might be helpful for you).
-- Browse to http://localhost:8080/samplecontainer/examples/commoncontainer/
-- Paste in the location of your gadget spec and add it to the container.
-- When your gadget loads and makeRequest fires, you should see tons of SSL
debug output in Tomcat's console. This should give you enough info to figure
out exactly why things are failing.
It sounds like you've changed a bunch of stuff within your Tomcat install so if
things don't work as expected with the steps above I'd recommend just
downloading a fresh copy of the Tomcat zip version and starting from that.
As far as getting the certificate into the trust store of the JVM that Tomcat
is running on -- I think there are two options. By default I believe that
Tomcat just relies on the JVM's standard trust store. That is what I'm most
familiar with. I think you can also somehow configure Tomcat to get the JVM
not to use its default trust store and to use a Tomcat specific one -- I've not
tried that method but I know people who have and it seemed to work fine as well.
Hope that helps.
Let us know how you make out!
--Jesse
>-----Original Message-----
>From: Tony Chan (tchan2) [mailto:tch...@cisco.com]
>Sent: Thursday, October 13, 2011 2:53 PM
>To: dev@shindig.apache.org
>Subject: RE: Failing to connect to https server through gadget
>
>Thanks for that Jesse. I've read and followed the first link you sent.
>I successfully connected to the secure server using the sample
>application SSLSocketClientWithAuth from that page and got a response
>after importing the server's certificate into my cacerts keystore.
>However, my gadget still gets the same errors as before.
>
>I have verified that tomcat is using the correct path for JRE_HOME (it's
>the same one in which the cacerts is located "C:\Program
>Files\Java\jdk1.7.0\").
>
>Here's other things I tried:
>- editing the server.xml in my tomcat\conf folder
> I uncommented out the "Define a SSL HTTP/1.1 Connector on port
>8443" section and set the keystoreFile=<path to cacerts> and the
>keystorePass=<password>
>- editing the shindig.properties
> I read in another mailing list post
>(http://mail-archives.apache.org/mod_mbox/shindig-
>issues/201001.mbox/%3C
>b71cdca91001032330r78863462ud3b9ed1d49db9...@mail.gmail.com%3E) that
>to
>override the default shindig.properties, I simply need to put an edited
>shindig.properties file into the $CATALINA_HOME/lib/ folder, which I
>have done. I ran 2 openssl commands:
> openssl req -newkey rsa:1024 -days 365 -nodes -x509 -keyout
>testkey.pem -out testkey.pem -subj '/CN=mytestkey'
> openssl pkcs8 -in testkey.pem -out oauthkey.pem -topk8 -nocrypt
>-outform PEM
>I then copied the testkey.pem to the
>$CATALINA_HOME/webapps/ROOT/WEB-INF/ folder and edited the
>shindig.signing.key-name=mytestkey and
>shindig.signing.key-file=/WEB-INF/testkey.pem. I did not see any effects
>after restarting the server.
>
>Any ideas?
>
>
>-----Original Message-----
>From: Ciancetta, Jesse E. [mailto:jc...@mitre.org]
>Sent: Thursday, October 13, 2011 5:50 AM
>To: dev@shindig.apache.org
>Subject: RE: Failing to connect to https server through gadget
>
>I've run into this situation a bunch of times myself and the best way
>I've found to get to the root of the issue is to turn on low level
>debugging directly in the networking API's.
>
>Shindig is using HttpClient under the covers for all of its network
>fetching, and HttpClient is using the java.net API's under the covers to
>do the actual network communication -- so if you turn on debugging for
>the java.net API's you should be able to get a better idea of what's
>going wrong.
>
>There's a reference here for enabling debugging for the java.net API's:
>
>http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDeb
>ug.html
>
>There also seem to be ways to turn on debug logging in HttpClient as
>well which may also be helpful (and may very well turn on the java.net
>debugging at the same time) although I've never tried this approach
>myself:
>
>http://hc.apache.org/httpcomponents-client-ga/logging.html
>
>--Jesse
>
>>-----Original Message-----
>>From: Tony Chan (tchan2) [mailto:tch...@cisco.com]
>>Sent: Wednesday, October 12, 2011 6:46 PM
>>To: dev@shindig.apache.org
>>Subject: Failing to connect to https server through gadget
>>
>>Hi everyone,
>>
>>
>>
>>I'm having trouble connecting to an https server through my gadget.
>I'm
>>not sure if it's because I've installed the self-signed certificate
>>incorrectly in the cacerts file or because I'm doing my makeRequest
>>incorrectly. If I do a keytool -list -keystore <path to cacerts> I can
>>definitely see my alias for the key in there. In my makeRequest, using
>>AuthorizationType.NONE gives me a 500 peer unauthenticated error while
>>using AuthorizationType.SIGNED gives me a 200 OK status, but what's
>>returned looks to be a 403 oauthError with text saying "Unable to
>>retrieve consumer key".
>>
>>
>>
>>I have followed the documentation file that came with tomcat
>>"ssl-howto.html" and edited the connector settings in server.xml, but
>>that hasn't seemed to help. I am able to use makeRequest to get a
>>response from a server not using https. I'm rather stumped as to what
>I
>>should try next.
>>
>>
>>
>>Thanks in advance,
>>
>>Tony Chan
