Re: Well HTTPS
Thanks Ben, Excellent work and documentation ... just what i's seeking now i can run my secured Restlets under HTTPs and further protect these using Basic Authentication you really helped me a lot guys .. Thank you All and keep up the good work.. All the best... John D. Mitchell wrote: > > On Tuesday 2008.12.16, at 01:39 , Ben Johnson wrote: > [...] > > Thanks for writing that up! I'm sure that's going to be quite helpful > to people. > >> Personally, I prefer Bruno's suggestion of using >> the Java VM parameters on your Java client program: >> >> -Djavax.net.ssl.trustStore=C:\\somedir\\serverX.jks >> -Djavax.net.ssl.trustStoreType=JKS >> -Djavax.net.ssl.trustStorePassword=password > > Um, er, actually it's generally considered bad security practice to > put sensitive information (like a password) on the command-line since > it's relatively easy for other users/programs to see it. > > Happy holidays, > John > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=985102 > > -- View this message in context: http://n2.nabble.com/Well-HTTPS-tp1509583p1672082.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=986418
Re: Well HTTPS
Thanks for pointing out the security hole John - I should have clarified that I like this approach for a dev/test environment, not a production one. -- From: "John D. Mitchell" Sent: Tuesday, December 16, 2008 5:04 PM To: Subject: Re: Well HTTPS > On Tuesday 2008.12.16, at 01:39 , Ben Johnson wrote: > [...] > > Thanks for writing that up! I'm sure that's going to be quite helpful > to people. > >> Personally, I prefer Bruno's suggestion of using >> the Java VM parameters on your Java client program: >> >> -Djavax.net.ssl.trustStore=C:\\somedir\\serverX.jks >> -Djavax.net.ssl.trustStoreType=JKS >> -Djavax.net.ssl.trustStorePassword=password > > Um, er, actually it's generally considered bad security practice to > put sensitive information (like a password) on the command-line since > it's relatively easy for other users/programs to see it. > > Happy holidays, > John > > -- > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=985102 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=985270
Re: Well HTTPS
On Tuesday 2008.12.16, at 01:39 , Ben Johnson wrote: [...] Thanks for writing that up! I'm sure that's going to be quite helpful to people. > Personally, I prefer Bruno's suggestion of using > the Java VM parameters on your Java client program: > > -Djavax.net.ssl.trustStore=C:\\somedir\\serverX.jks > -Djavax.net.ssl.trustStoreType=JKS > -Djavax.net.ssl.trustStorePassword=password Um, er, actually it's generally considered bad security practice to put sensitive information (like a password) on the command-line since it's relatively easy for other users/programs to see it. Happy holidays, John -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=985102
Re: Well HTTPS
Hi Mohamed
Bruno and I wrote up some documentation based on this discussion:
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html
This describes the steps you need to take for a client to communicate with a
server via HTTPS; 'Step 3' describes two ways of getting a client to trust
the server's certificate. Personally, I prefer Bruno's suggestion of using
the Java VM parameters on your Java client program:
-Djavax.net.ssl.trustStore=C:\\somedir\\serverX.jks
-Djavax.net.ssl.trustStoreType=JKS
-Djavax.net.ssl.trustStorePassword=password
These arguments tell the Java VM where to find your certificate.
As far as authentication goes, I haven't tried doing that yet, but there is
documentation for that too here:
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/112-restlet.html
Hope this helps.
Ben
--
From: "Mohamed Abdel-Aziz Bayoumi"
Sent: Monday, December 15, 2008 11:24 AM
To:
Subject: RE: Well HTTPS
> Hi Ben,
>
> Thanks for your extraordinary post you really helped me out understand a
> lot
> about HTTPS ... i just wanted to ask >> what shall i do if i want a client
> (on a different machine) to access my restlet HTTPS configured Simple web
> server ?? please i need detailed steps/instructions on how to do it cuz
> i'm
> new to this ... shall i send him my .cer file ?? or only the public key ??
> if so how can i retrieve it ? ... also what if want to make basic
> authentication to my resources using an encrypted username and password ?
> ... plz help and thanks in advance :)
>
> All the best
>
>
> Ben Johnson wrote:
>>
>> Hi
>>
>> I am new to Restlet and web programming, HTTP and SSL certificates in
>> general, but hopefully my recent experiences will help. I spent the last
>> several days trying to find a Restlet example using HTTPS (there isn't
>> one), and eventually pieced together the following (using Windows XP SP2
>> with Java 6, Eclipse, Restlet 1.1.1):
>>
>> 1) Create your keys and certificate. I tried both 'keytool' and IBM's
>> KeyMan to do this (KeyMan is easier, but more work to obtain, as you need
>> to register, etc...). Using keytool from a command prompt you need to
>> enter two commands - the first one creates the keystore file with the
>> keys, the second certifies it (self-certification, ok for testing). The
>> most important thing is that the name of the machine you will be using
>> the
>> certificate on matches what you specify (in the example below, my machine
>> is called 'serverX'):
>>
>> keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias serverX
>> -keypass password -keystore serverX.cer -storepass password -keyalg "RSA"
>> -storetype "PKCS12" -provider sun.security.provider.Sun
>>
>> keytool -selfcert -alias serverX -keystore serverX.cer -storepass
>> password
>> -storetype "PKCS12"
>>
>> The keystore file has now been created and self-certified: in this
>> example
>> it is called 'serverX.cer' and was saved in the current directory. There
>> are two passwords: one for the keys and one to access the keystore. I
>> set
>> them both to 'password' for testing. The name of the keystore file
>> ('serverX.cer') is not important, I just used that for consistency.
>>
>> 2) To prevent warnings in a browser, add the keystore to the 'Trusted
>> Root
>> Certification Authorities' on your computer. In Windows XP, I just used
>> Internet Options (via IE7 or Control Panel - Internet Options). On the
>> 'Content' tab, click 'Certificates', then go to 'Trusted Root
>> Certification Authorities' tab, click 'Import...' and follow the steps to
>> import your keystore file (in my example, 'serverX.cer'). It will give
>> warnings about not being verified, which is ok for testing (but it must
>> be
>> properly signed for production).
>>
>> 3) In order for Java security to recognise the certificate, it needs to
>> be
>> added to \lib\security\cacerts, which is the Java certificates file.
>> This is important when you use a Restlet client to connect to the server
>> via HTTPS (but it did not seem to be needed by my browser - it needed the
>> IE options update described in point 2). On my system, 'cacerts' is
>> "C:\Program Files\Java\jre6\lib\security\cacerts". I had some trouble
>> adding my 'serverX' certificate to it, but the following keytool commands
>>
RE: Well HTTPS
Hi Ben,
Thanks for your extraordinary post you really helped me out understand a lot
about HTTPS ... i just wanted to ask >> what shall i do if i want a client
(on a different machine) to access my restlet HTTPS configured Simple web
server ?? please i need detailed steps/instructions on how to do it cuz i'm
new to this ... shall i send him my .cer file ?? or only the public key ??
if so how can i retrieve it ? ... also what if want to make basic
authentication to my resources using an encrypted username and password ?
... plz help and thanks in advance :)
All the best
Ben Johnson wrote:
>
> Hi
>
> I am new to Restlet and web programming, HTTP and SSL certificates in
> general, but hopefully my recent experiences will help. I spent the last
> several days trying to find a Restlet example using HTTPS (there isn't
> one), and eventually pieced together the following (using Windows XP SP2
> with Java 6, Eclipse, Restlet 1.1.1):
>
> 1) Create your keys and certificate. I tried both 'keytool' and IBM's
> KeyMan to do this (KeyMan is easier, but more work to obtain, as you need
> to register, etc...). Using keytool from a command prompt you need to
> enter two commands - the first one creates the keystore file with the
> keys, the second certifies it (self-certification, ok for testing). The
> most important thing is that the name of the machine you will be using the
> certificate on matches what you specify (in the example below, my machine
> is called 'serverX'):
>
> keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias serverX
> -keypass password -keystore serverX.cer -storepass password -keyalg "RSA"
> -storetype "PKCS12" -provider sun.security.provider.Sun
>
> keytool -selfcert -alias serverX -keystore serverX.cer -storepass password
> -storetype "PKCS12"
>
> The keystore file has now been created and self-certified: in this example
> it is called 'serverX.cer' and was saved in the current directory. There
> are two passwords: one for the keys and one to access the keystore. I set
> them both to 'password' for testing. The name of the keystore file
> ('serverX.cer') is not important, I just used that for consistency.
>
> 2) To prevent warnings in a browser, add the keystore to the 'Trusted Root
> Certification Authorities' on your computer. In Windows XP, I just used
> Internet Options (via IE7 or Control Panel - Internet Options). On the
> 'Content' tab, click 'Certificates', then go to 'Trusted Root
> Certification Authorities' tab, click 'Import...' and follow the steps to
> import your keystore file (in my example, 'serverX.cer'). It will give
> warnings about not being verified, which is ok for testing (but it must be
> properly signed for production).
>
> 3) In order for Java security to recognise the certificate, it needs to be
> added to \lib\security\cacerts, which is the Java certificates file.
> This is important when you use a Restlet client to connect to the server
> via HTTPS (but it did not seem to be needed by my browser - it needed the
> IE options update described in point 2). On my system, 'cacerts' is
> "C:\Program Files\Java\jre6\lib\security\cacerts". I had some trouble
> adding my 'serverX' certificate to it, but the following keytool commands
> work if you know the password for cacerts ('changeit' is the default I
> believe):
>
> keytool -export -alias serverX -file serverX.jks -storetype "PKCS12"
> -keystore serverX.cer -keypass password
> keytool -import -alias serverX -file serverX.jks -noprompt -trustcacerts
> -keystore "C:\Program Files\Java\jre6\lib\security\cacerts"
>
> The first command exports the certificate from PKCS12 format into X.509
> (JKS) format, which is what cacerts needs. In my case, I had to use
> KeyMan to set the password for the 'cacerts' file (I set it back to the
> default of 'changeit'), so when I ran 'keytool -import ...' I could enter
> the correct password. There may be a better/easier way to do this.
>
> 4) In your Java Restlet server program, in addition to the standard
> Restlet jar files, you also need jar files for HTTPS. The only HTTPS
> connector I could get to work correctly was 'Simple', which uses these jar
> files:
>
> lib/com.noelios.restlet.ext.simple_3.1.jar
> lib/org.simpleframework_3.1/org.simpleframework.jar
> lib/com.noelios.restlet.ext.ssl.jar
> lib/org.jsslutils_0.5/org.jsslutils.jar
>
> (Grizzly compiled and ran, but gave inconsistent results - appeared to be
> missing requests; Jetty threw an error saying it couldn't register
> 'AjpServerHelper').
>
> 5) Your Restlet server code should then look something like this:
>
> package com.jpc.samples;
>
> import org.restlet.Component;
> import org.restlet.Server;
> import org.restlet.data.Parameter;
> import org.restlet.data.Protocol;
> import org.restlet.util.Series;
>
> public class SampleServer {
>
> public static void main(String[] args) throws Exception {
> // Create a new Component.
> Component component = new Component();
RE: Well HTTPS
Hi Ben,
Excellent!
Let us know if you need help regarding the wiki edition. You can also check
editing instructions here:
http://wiki.restlet.org/about/2-restlet.html
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Ben Johnson [mailto:[EMAIL PROTECTED]
Envoyé : samedi 29 novembre 2008 16:57
À : discuss@restlet.tigris.org
Objet : Re: Well HTTPS
Hi Jérôme
Sure, I'll try to put it together next week - I'd like to refine the
certificate / key store instructions so it's clear what needs to be done on
a server versus what needs to be done on a client.
Regards
Ben
--
From: "Jerome Louvel" <[EMAIL PROTECTED]>
Sent: Friday, November 28, 2008 2:12 PM
To:
Subject: RE: Well HTTPS
>
> Hi all,
>
> I think that Ben's step-by-step tutorial (with Bruno's remarks) would be a
> great addition to Restlet's User Guide!
>
> There is now a shell page "Configuring HTTPS", crying for such content:
> http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restle
> t.html
>
> Ben, I saw that you already registered an account on the wiki and now you
> have edition rights (like all registered users).
>
> Would you be open to contributing the content of your post to this page?
>
> Best regards,
> Jérôme Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -Message d'origine-----
> De : Ben Johnson [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi 21 novembre 2008 18:51
> À : discuss@restlet.tigris.org
> Objet : Re: Well HTTPS
>
> Thanks for the feedback Bruno; I'm still learning about certificates and
> Restlet, and I appreciate your clarifications!
>
> Regards
> Ben
> --
> From: "Bruno Harbulot" <[EMAIL PROTECTED]>
> Sent: Friday, November 21, 2008 2:54 PM
> To:
> Subject: Re: Well HTTPS
>
>> Hi,
>>
>> Ben Johnson wrote:
>>> Hi
>>> I am new to Restlet and web programming, HTTP and SSL certificates in
>>> general, but hopefully my recent experiences will help. I spent the
>>> last
>
>>> several days trying to find a Restlet example using HTTPS (there isn't
>>> one), and eventually pieced together the following (using Windows XP SP2
>>> with Java 6, Eclipse, Restlet 1.1.1):
>>> 1) Create your keys and certificate. I tried both 'keytool' and IBM's
>>> KeyMan to do this (KeyMan is easier, but more work to obtain, as you
>>> need
>
>>> to register, etc...). Using keytool from a command prompt you need to
>>> enter two commands - the first one creates the keystore file with the
>>> keys, the second certifies it (self-certification, ok for testing). The
>>> most important thing is that the name of the machine you will be using
>>> the certificate on matches what you specify (in the example below, my
>>> machine is called 'serverX'):
>>> keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias
>>> serverX -keypass password -keystore serverX.cer -storepass
>>> password -keyalg "RSA" -storetype "PKCS12" -provider
>>> sun.security.provider.Sun
>>> keytool -selfcert -alias serverX -keystore serverX.cer -storepass
>>> password -storetype "PKCS12"
>>> The keystore file has now been created and self-certified: in this
>>> example it is called 'serverX.cer' and was saved in the current
>>> directory. There are two passwords: one for the keys and one to access
>>> the keystore. I set them both to 'password' for testing. The name of
>>> the keystore file ('serverX.cer') is not important, I just used that for
>>> consistency.
>>
>> Usually, the extension for JKS keystores is "jks" and the extension for
>> PKCS#12 keystores is "p12". "cer" tends to be used for X.509 certificates
>> in DER format (application/x-x509-ca-cert), which are files containing
>> just the certificate: this is the format produced by "keytool -export".
>> It looks from the example below that you've used "jks" for that, whereas
>> it's not actually a JKS file but a cer file.
>>
>>
>>> 2) To prevent warnings in a browser, add the keystore to the 'Trusted
>>> Root Certification Authorities' on y
Re: Well HTTPS
Hi Jérôme
Sure, I'll try to put it together next week - I'd like to refine the
certificate / key store instructions so it's clear what needs to be done on
a server versus what needs to be done on a client.
Regards
Ben
--
From: "Jerome Louvel" <[EMAIL PROTECTED]>
Sent: Friday, November 28, 2008 2:12 PM
To:
Subject: RE: Well HTTPS
Hi all,
I think that Ben's step-by-step tutorial (with Bruno's remarks) would be a
great addition to Restlet's User Guide!
There is now a shell page "Configuring HTTPS", crying for such content:
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restle
t.html
Ben, I saw that you already registered an account on the wiki and now you
have edition rights (like all registered users).
Would you be open to contributing the content of your post to this page?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Ben Johnson [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 21 novembre 2008 18:51
À : discuss@restlet.tigris.org
Objet : Re: Well HTTPS
Thanks for the feedback Bruno; I'm still learning about certificates and
Restlet, and I appreciate your clarifications!
Regards
Ben
--
From: "Bruno Harbulot" <[EMAIL PROTECTED]>
Sent: Friday, November 21, 2008 2:54 PM
To:
Subject: Re: Well HTTPS
Hi,
Ben Johnson wrote:
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in
general, but hopefully my recent experiences will help. I spent the
last
several days trying to find a Restlet example using HTTPS (there isn't
one), and eventually pieced together the following (using Windows XP SP2
with Java 6, Eclipse, Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's
KeyMan to do this (KeyMan is easier, but more work to obtain, as you
need
to register, etc...). Using keytool from a command prompt you need to
enter two commands - the first one creates the keystore file with the
keys, the second certifies it (self-certification, ok for testing). The
most important thing is that the name of the machine you will be using
the certificate on matches what you specify (in the example below, my
machine is called 'serverX'):
keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias
serverX -keypass password -keystore serverX.cer -storepass
password -keyalg "RSA" -storetype "PKCS12" -provider
sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass
password -storetype "PKCS12"
The keystore file has now been created and self-certified: in this
example it is called 'serverX.cer' and was saved in the current
directory. There are two passwords: one for the keys and one to access
the keystore. I set them both to 'password' for testing. The name of
the keystore file ('serverX.cer') is not important, I just used that for
consistency.
Usually, the extension for JKS keystores is "jks" and the extension for
PKCS#12 keystores is "p12". "cer" tends to be used for X.509 certificates
in DER format (application/x-x509-ca-cert), which are files containing
just the certificate: this is the format produced by "keytool -export".
It looks from the example below that you've used "jks" for that, whereas
it's not actually a JKS file but a cer file.
2) To prevent warnings in a browser, add the keystore to the 'Trusted
Root Certification Authorities' on your computer. In Windows XP, I just
used Internet Options (via IE7 or Control Panel - Internet Options). On
the 'Content' tab, click 'Certificates', then go to 'Trusted Root
Certification Authorities' tab, click 'Import...' and follow the steps
to
import your keystore file (in my example, 'serverX.cer'). It will give
warnings about not being verified, which is ok for testing (but it must
be properly signed for production).
Since your .cer is in fact a .p12, this might import the private key as
well (that's what you would do if you wanted to use client-certificate
authentication). In fact, the actual .cer exported by keytool should be
sufficient. Just to clarify the extensions:
keytool -export -alias serverX -file serverX.cer -storetype
"PKCS12" -keystore serverX.p12 -keypass password
(Shouldn't this be "-storepass" rather than "-keypass" by the way?)
3) In order for Java security to recognise the certificate, it needs to
be added to \lib\security\cacerts, which is the Java certificates
file. This is important when you use a Restlet client to connect to the
serve
RE: Well HTTPS
Hi all,
I think that Ben's step-by-step tutorial (with Bruno's remarks) would be a
great addition to Restlet's User Guide!
There is now a shell page "Configuring HTTPS", crying for such content:
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restle
t.html
Ben, I saw that you already registered an account on the wiki and now you
have edition rights (like all registered users).
Would you be open to contributing the content of your post to this page?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Ben Johnson [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 21 novembre 2008 18:51
À : discuss@restlet.tigris.org
Objet : Re: Well HTTPS
Thanks for the feedback Bruno; I'm still learning about certificates and
Restlet, and I appreciate your clarifications!
Regards
Ben
--
From: "Bruno Harbulot" <[EMAIL PROTECTED]>
Sent: Friday, November 21, 2008 2:54 PM
To:
Subject: Re: Well HTTPS
> Hi,
>
> Ben Johnson wrote:
>> Hi
>> I am new to Restlet and web programming, HTTP and SSL certificates in
>> general, but hopefully my recent experiences will help. I spent the last
>> several days trying to find a Restlet example using HTTPS (there isn't
>> one), and eventually pieced together the following (using Windows XP SP2
>> with Java 6, Eclipse, Restlet 1.1.1):
>> 1) Create your keys and certificate. I tried both 'keytool' and IBM's
>> KeyMan to do this (KeyMan is easier, but more work to obtain, as you need
>> to register, etc...). Using keytool from a command prompt you need to
>> enter two commands - the first one creates the keystore file with the
>> keys, the second certifies it (self-certification, ok for testing). The
>> most important thing is that the name of the machine you will be using
>> the certificate on matches what you specify (in the example below, my
>> machine is called 'serverX'):
>> keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias
>> serverX -keypass password -keystore serverX.cer -storepass
>> password -keyalg "RSA" -storetype "PKCS12" -provider
>> sun.security.provider.Sun
>> keytool -selfcert -alias serverX -keystore serverX.cer -storepass
>> password -storetype "PKCS12"
>> The keystore file has now been created and self-certified: in this
>> example it is called 'serverX.cer' and was saved in the current
>> directory. There are two passwords: one for the keys and one to access
>> the keystore. I set them both to 'password' for testing. The name of
>> the keystore file ('serverX.cer') is not important, I just used that for
>> consistency.
>
> Usually, the extension for JKS keystores is "jks" and the extension for
> PKCS#12 keystores is "p12". "cer" tends to be used for X.509 certificates
> in DER format (application/x-x509-ca-cert), which are files containing
> just the certificate: this is the format produced by "keytool -export".
> It looks from the example below that you've used "jks" for that, whereas
> it's not actually a JKS file but a cer file.
>
>
>> 2) To prevent warnings in a browser, add the keystore to the 'Trusted
>> Root Certification Authorities' on your computer. In Windows XP, I just
>> used Internet Options (via IE7 or Control Panel - Internet Options). On
>> the 'Content' tab, click 'Certificates', then go to 'Trusted Root
>> Certification Authorities' tab, click 'Import...' and follow the steps to
>> import your keystore file (in my example, 'serverX.cer'). It will give
>> warnings about not being verified, which is ok for testing (but it must
>> be properly signed for production).
>
> Since your .cer is in fact a .p12, this might import the private key as
> well (that's what you would do if you wanted to use client-certificate
> authentication). In fact, the actual .cer exported by keytool should be
> sufficient. Just to clarify the extensions:
>
> keytool -export -alias serverX -file serverX.cer -storetype
> "PKCS12" -keystore serverX.p12 -keypass password
>
> (Shouldn't this be "-storepass" rather than "-keypass" by the way?)
>
>
>> 3) In order for Java security to recognise the certificate, it needs to
>> be added to \lib\security\cacerts, which is the Java certificates
>> file. This is important
Re: Well HTTPS
John D. Mitchell wrote: For what it's worth... For production use, I've come to the point where I do *NOT* like implementing SSL solutions directly in Java. The extra overhead, hassles, etc. just aren't worth it in general. For example, for both Krugle and MarkMail, we have SSL (ala HTTPS) handled directly by the load-balancers and everybody behind them is blissfully unaware and this makes the management of all of the backend servers much much cleaner, easier, faster, etc. That's a good point. I think the couple of advantages (load-balancing excluded) that I find in using an Apache HTTPD front-end are: - it's easier to set up out of the box on a Linux machine to run on privileged port 443, - with this configuration, the private key is only readable by root, not by the user running the Java connector. I can't disagree with you on the complexity of setting up SSL in Java, as it was one of the reasons I started jSSLutils; I hope it may have improved that sort of configuration a bit (at least it has for me). Of course, if you're doing really sensitive stuff and need finer granularity (medical, financial, etc.) then you're stuck and need to do that but in those cases you're already stuck dealing with a lot of threats that you can't take for granted anyways so the Java-specific hassles aren't such a big issue. I've experienced problems with mod_jk (only) a couple of times: when doing about 200 connections in less than a second, the connections would appear in the Apache logs, but nothing happened on the AJP side. I have been unable to reproduce this, perhaps the problem was fixed as part of an update of the Jetty libs in Restlet. I wanted to try mod_proxy_ajp. Unfortunately, it doesn't support sending the entire chain of client certificates (just the first one) to the Java back-end, and I need the whole chain for my application. The other option would be to remove the Apache HTTPD intermediary. I also find that Java makes it easier to change the way certificates are trusted/validated, especially if they're not standard, or from unusual standards (e.g. proxy certificates). [But I shall refrain from going off on my tirade about big complicated SSL installations that then talk to an unencrypted database over an unencrypted connection.] :-) I think it's OK if you're sure no one can listen on the network in between, but it's sometimes hard to check. I shall also refrain from talking about SSL support in JDBC drivers :-) Best wishes, Bruno.
Re: Well HTTPS
For what it's worth... For production use, I've come to the point where I do *NOT* like implementing SSL solutions directly in Java. The extra overhead, hassles, etc. just aren't worth it in general. For example, for both Krugle and MarkMail, we have SSL (ala HTTPS) handled directly by the load-balancers and everybody behind them is blissfully unaware and this makes the management of all of the backend servers much much cleaner, easier, faster, etc. Of course, if you're doing really sensitive stuff and need finer granularity (medical, financial, etc.) then you're stuck and need to do that but in those cases you're already stuck dealing with a lot of threats that you can't take for granted anyways so the Java-specific hassles aren't such a big issue. [But I shall refrain from going off on my tirade about big complicated SSL installations that then talk to an unencrypted database over an unencrypted connection.] :-) Hope this helps, John
Re: Well HTTPS
Thanks for the feedback Bruno; I'm still learning about certificates and
Restlet, and I appreciate your clarifications!
Regards
Ben
--
From: "Bruno Harbulot" <[EMAIL PROTECTED]>
Sent: Friday, November 21, 2008 2:54 PM
To:
Subject: Re: Well HTTPS
Hi,
Ben Johnson wrote:
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in
general, but hopefully my recent experiences will help. I spent the last
several days trying to find a Restlet example using HTTPS (there isn't
one), and eventually pieced together the following (using Windows XP SP2
with Java 6, Eclipse, Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's
KeyMan to do this (KeyMan is easier, but more work to obtain, as you need
to register, etc...). Using keytool from a command prompt you need to
enter two commands - the first one creates the keystore file with the
keys, the second certifies it (self-certification, ok for testing). The
most important thing is that the name of the machine you will be using
the certificate on matches what you specify (in the example below, my
machine is called 'serverX'):
keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias
serverX -keypass password -keystore serverX.cer -storepass
password -keyalg "RSA" -storetype "PKCS12" -provider
sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass
password -storetype "PKCS12"
The keystore file has now been created and self-certified: in this
example it is called 'serverX.cer' and was saved in the current
directory. There are two passwords: one for the keys and one to access
the keystore. I set them both to 'password' for testing. The name of
the keystore file ('serverX.cer') is not important, I just used that for
consistency.
Usually, the extension for JKS keystores is "jks" and the extension for
PKCS#12 keystores is "p12". "cer" tends to be used for X.509 certificates
in DER format (application/x-x509-ca-cert), which are files containing
just the certificate: this is the format produced by "keytool -export".
It looks from the example below that you've used "jks" for that, whereas
it's not actually a JKS file but a cer file.
2) To prevent warnings in a browser, add the keystore to the 'Trusted
Root Certification Authorities' on your computer. In Windows XP, I just
used Internet Options (via IE7 or Control Panel - Internet Options). On
the 'Content' tab, click 'Certificates', then go to 'Trusted Root
Certification Authorities' tab, click 'Import...' and follow the steps to
import your keystore file (in my example, 'serverX.cer'). It will give
warnings about not being verified, which is ok for testing (but it must
be properly signed for production).
Since your .cer is in fact a .p12, this might import the private key as
well (that's what you would do if you wanted to use client-certificate
authentication). In fact, the actual .cer exported by keytool should be
sufficient. Just to clarify the extensions:
keytool -export -alias serverX -file serverX.cer -storetype
"PKCS12" -keystore serverX.p12 -keypass password
(Shouldn't this be "-storepass" rather than "-keypass" by the way?)
3) In order for Java security to recognise the certificate, it needs to
be added to \lib\security\cacerts, which is the Java certificates
file. This is important when you use a Restlet client to connect to the
server via HTTPS (but it did not seem to be needed by my browser - it
needed the IE options update described in point 2). On my system,
'cacerts' is "C:\Program Files\Java\jre6\lib\security\cacerts". I had
some trouble adding my 'serverX' certificate to it, but the following
keytool commands work if you know the password for cacerts ('changeit' is
the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype
"PKCS12" -keystore serverX.cer -keypass password
keytool -import -alias serverX -file
serverX.jks -noprompt -trustcacerts -keystore "C:\Program
Files\Java\jre6\lib\security\cacerts"
The first command exports the certificate from PKCS12 format into X.509
(JKS) format, which is what cacerts needs. In my case, I had to use
KeyMan to set the password for the 'cacerts' file (I set it back to the
default of 'changeit'), so when I ran 'keytool -import ...' I could enter
the correct password. There may be a better/easier way to do this.
If for some reason, you can write to that file (which is likely to be
shared by all users on that system), you can specify your own truststore
Re: Well HTTPS
Hi, I'm not sure you're clear on what certificates, signing and encryption are. Roughly speaking, an X.509 certificate is the combination of a public key and some information (subject distinguished name, date from/to, other attributes) that has been signed using a private key usually corresponding to another certificate. The signer (CA) asserts authority on the validity of the information in this certificate by signing it, but the certificate itself is not enciphered and it's meant to be public. The certificate of the signer (corresponding to its private key) may be an intermediate CA or a root CA certificate. In the latter case, it's a self-signed certificate (which means that it's been signed with its own private key). Why would you trust such a CA certificate? That's a "leap of faith". Browsers and operating systems come with a bundle of CA certificates they trust by default (Verisign, Thawte, ...), but you could have your own PKI and set your own within your organisation. As Ben pointed out in another message on this thread, the default set of trusted CA certificates in the JVM is in a file called "cacerts". It's however up to you to make sure you want to trust the CA certificates it contains. Similarly IE, Firefox, OSX Keychain come with their set of trusted CAs. The only reasons you'd trust them are: - you trust the copy of the software you've obtained is genuine, and - you trust the company/organisation that produced that software to have made the right choices, because it has bundled the CA certificates it wanted you to have. Best wishes, Bruno. Mohammed Al-Adawi wrote: Hi Given X = Public key and some data; Trusted Certificate is X which is digitally signed by CA private key. Digitally signed means hashing X and then encrypt it with CA private key. if that is true CA public key must be some where and NOT encrypted so you can decrypt certificate, You can say that I have an emotional problem coming from the fact: "NO ONE said that CA public key is there available", also no one said where it is stored!! keystore, truststore, or it is not encrypted nor hashed. Can you solve my emotional problem?? Thanks
Re: Well HTTPS
Hi,
Ben Johnson wrote:
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in
general, but hopefully my recent experiences will help. I spent the
last several days trying to find a Restlet example using HTTPS (there
isn't one), and eventually pieced together the following (using Windows
XP SP2 with Java 6, Eclipse, Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's
KeyMan to do this (KeyMan is easier, but more work to obtain, as you
need to register, etc...). Using keytool from a command prompt you need
to enter two commands - the first one creates the keystore file with the
keys, the second certifies it (self-certification, ok for testing). The
most important thing is that the name of the machine you will be using
the certificate on matches what you specify (in the example below, my
machine is called 'serverX'):
keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias serverX
-keypass password -keystore serverX.cer -storepass password -keyalg
"RSA" -storetype "PKCS12" -provider sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass
password -storetype "PKCS12"
The keystore file has now been created and self-certified: in this
example it is called 'serverX.cer' and was saved in the current
directory. There are two passwords: one for the keys and one to access
the keystore. I set them both to 'password' for testing. The name of
the keystore file ('serverX.cer') is not important, I just used that for
consistency.
Usually, the extension for JKS keystores is "jks" and the extension for
PKCS#12 keystores is "p12". "cer" tends to be used for X.509
certificates in DER format (application/x-x509-ca-cert), which are files
containing just the certificate: this is the format produced by "keytool
-export".
It looks from the example below that you've used "jks" for that, whereas
it's not actually a JKS file but a cer file.
2) To prevent warnings in a browser, add the keystore to the 'Trusted
Root Certification Authorities' on your computer. In Windows XP, I just
used Internet Options (via IE7 or Control Panel - Internet Options). On
the 'Content' tab, click 'Certificates', then go to 'Trusted Root
Certification Authorities' tab, click 'Import...' and follow the steps
to import your keystore file (in my example, 'serverX.cer'). It will
give warnings about not being verified, which is ok for testing (but
it must be properly signed for production).
Since your .cer is in fact a .p12, this might import the private key as
well (that's what you would do if you wanted to use client-certificate
authentication). In fact, the actual .cer exported by keytool should be
sufficient. Just to clarify the extensions:
keytool -export -alias serverX -file serverX.cer -storetype "PKCS12"
-keystore serverX.p12 -keypass password
(Shouldn't this be "-storepass" rather than "-keypass" by the way?)
3) In order for Java security to recognise the certificate, it needs to
be added to \lib\security\cacerts, which is the Java certificates
file. This is important when you use a Restlet client to connect to the
server via HTTPS (but it did not seem to be needed by my browser - it
needed the IE options update described in point 2). On my
system, 'cacerts' is "C:\Program Files\Java\jre6\lib\security\cacerts".
I had some trouble adding my 'serverX' certificate to it, but the
following keytool commands work if you know the password for cacerts
('changeit' is the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype "PKCS12"
-keystore serverX.cer -keypass password
keytool -import -alias serverX -file serverX.jks -noprompt -trustcacerts
-keystore "C:\Program Files\Java\jre6\lib\security\cacerts"
The first command exports the certificate from PKCS12 format into X.509
(JKS) format, which is what cacerts needs. In my case, I had to use
KeyMan to set the password for the 'cacerts' file (I set it back to the
default of 'changeit'), so when I ran 'keytool -import ...' I could
enter the correct password. There may be a better/easier way to do this.
If for some reason, you can write to that file (which is likely to be
shared by all users on that system), you can specify your own truststore
using -Djavax.net.ssl.trustStore=mytruststore.jks
-Djavax.net.ssl.trustStore=JKS
-Djavax.net.ssl.trustStorePassword=ABCDEFGH as JVM parameters.
If you're requiring client-authentication (in which case it makes sense
to set up a trust store on the server), you can used the truststorePath,
truststorePassword and truststoreType parameters of the Restlet Server
when you're using the sslContextFactory (as you've done below).
There's currently no SSLContextFactory support in the client connectors
of Restlet, so you'll have either to modify the central cacerts as you
did, or use the SSL system properties.
As a side note, the "C:\Program Files\Java\jre6\lib\se
RE: Well HTTPS
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in general,
but hopefully my recent experiences will help. I spent the last several days
trying to find a Restlet example using HTTPS (there isn't one), and eventually
pieced together the following (using Windows XP SP2 with Java 6, Eclipse,
Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's KeyMan
to do this (KeyMan is easier, but more work to obtain, as you need to register,
etc...). Using keytool from a command prompt you need to enter two commands -
the first one creates the keystore file with the keys, the second certifies it
(self-certification, ok for testing). The most important thing is that the
name of the machine you will be using the certificate on matches what you
specify (in the example below, my machine is called 'serverX'):
keytool -genkey -dname "CN=serverX, OU=IT, O=JPC, C=GB" -alias serverX -keypass
password -keystore serverX.cer -storepass password -keyalg "RSA" -storetype
"PKCS12" -provider sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass password
-storetype "PKCS12"
The keystore file has now been created and self-certified: in this example it
is called 'serverX.cer' and was saved in the current directory. There are two
passwords: one for the keys and one to access the keystore. I set them both to
'password' for testing. The name of the keystore file ('serverX.cer') is not
important, I just used that for consistency.
2) To prevent warnings in a browser, add the keystore to the 'Trusted Root
Certification Authorities' on your computer. In Windows XP, I just used
Internet Options (via IE7 or Control Panel - Internet Options). On the
'Content' tab, click 'Certificates', then go to 'Trusted Root Certification
Authorities' tab, click 'Import...' and follow the steps to import your
keystore file (in my example, 'serverX.cer'). It will give warnings about not
being verified, which is ok for testing (but it must be properly signed for
production).
3) In order for Java security to recognise the certificate, it needs to be
added to \lib\security\cacerts, which is the Java certificates file. This
is important when you use a Restlet client to connect to the server via HTTPS
(but it did not seem to be needed by my browser - it needed the IE options
update described in point 2). On my system, 'cacerts' is "C:\Program
Files\Java\jre6\lib\security\cacerts". I had some trouble adding my 'serverX'
certificate to it, but the following keytool commands work if you know the
password for cacerts ('changeit' is the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype "PKCS12" -keystore
serverX.cer -keypass password
keytool -import -alias serverX -file serverX.jks -noprompt -trustcacerts
-keystore "C:\Program Files\Java\jre6\lib\security\cacerts"
The first command exports the certificate from PKCS12 format into X.509 (JKS)
format, which is what cacerts needs. In my case, I had to use KeyMan to set
the password for the 'cacerts' file (I set it back to the default of
'changeit'), so when I ran 'keytool -import ...' I could enter the correct
password. There may be a better/easier way to do this.
4) In your Java Restlet server program, in addition to the standard Restlet jar
files, you also need jar files for HTTPS. The only HTTPS connector I could get
to work correctly was 'Simple', which uses these jar files:
lib/com.noelios.restlet.ext.simple_3.1.jar
lib/org.simpleframework_3.1/org.simpleframework.jar
lib/com.noelios.restlet.ext.ssl.jar
lib/org.jsslutils_0.5/org.jsslutils.jar
(Grizzly compiled and ran, but gave inconsistent results - appeared to be
missing requests; Jetty threw an error saying it couldn't register
'AjpServerHelper').
5) Your Restlet server code should then look something like this:
package com.jpc.samples;
import org.restlet.Component;
import org.restlet.Server;
import org.restlet.data.Parameter;
import org.restlet.data.Protocol;
import org.restlet.util.Series;
public class SampleServer {
public static void main(String[] args) throws Exception {
// Create a new Component.
Component component = new Component();
// Add a new HTTPS server listening on port 8183
Server server = component.getServers().add(Protocol.HTTPS, 8183);
Series parameters = server.getContext().getParameters();
parameters.add("sslContextFactory",
"com.noelios.restlet.ext.ssl.PkixSslContextFactory");
parameters.add("keystorePath", "serverX.cer");
parameters.add("keystorePassword", "password");
parameters.add("keyPassword", "password");
parameters.add("keystoreType", "PKCS12");
// Attach the sample application.
component.getDefaultHost().attach("", new SampleApplication());
// Start the component.
component.start();
}
}
The HTTP examples all show 'component.getContext().getParameters().add(...) but
this does
Re: Well HTTPS
Hi
Given
X = Public key and some data;
Trusted Certificate is X which is digitally signed by CA private key.
Digitally signed means hashing X and then encrypt it with CA private key.
if that is true CA public key must be some where and NOT encrypted so you can
decrypt certificate,
You can say that I have an emotional problem coming from the fact: "NO ONE said
that CA public key is there available", also no one said where it is stored!!
keystore, truststore, or it is not encrypted nor hashed.
Can you solve my emotional problem??
Thanks
--- On Mon, 11/17/08, Thierry Boileau <[EMAIL PROTECTED]> wrote:
From: Thierry Boileau <[EMAIL PROTECTED]>
Subject: Re: Well HTTPS
To: discuss@restlet.tigris.org
Date: Monday, November 17, 2008, 3:06 PM
Hello,
I suggest you have a look at this
http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security (and then choose the
"keytool" documentation) and
http://blogs.sun.com/andreas/entry/no_more_unable_to_find.
You can find an explanation about the role of the keystore and the trustore
(try to get a clear idea of what these notions are). Try also to get what is a
server self certificate and how a client can trust it.
Then, you can make the link with the server connectors that support HTTPS
(http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html).
Each of them require some parameters, especially some dedicated to the
server's keystore ("keystorePath", "keystorePassword",
etc).
>Sorry it seems basic questions, but I feel that it will be easer to u to
answer it.
I don't think it's basic questions, but don't panic! Just read a
little bit more.
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
> WARNING
> BRAIN OVERHEATING /\
>
> I have read this
>
> http://en.wikipedia.org/wiki/Https
>
>
> and I want to implement HTTPS, in my sample application I converted
component.getServers().add(Protocol.HTTP, 8182);
>
> to
>
> component.getServers().add(Protocol.HTTPS, 8182);
>
>
> Now Jersy is asking me a lot of questions in the shell (key and pass), I
guess the answer and I wrote "me" as an answer for both questions!!
>
>
> /home/java/.keystore is not found and Exception is thrown...
>
> Is .keystore our Public Key Certificate, if yes, Is it created using
gensslcert??
>
> and where is the private key?
> if HTTPS is authenticating both sides (as I hardly understand) then there
must be one or two public keys and two private keys so server can authenticate
client and client can authenticate browser. the browser will authenticate the
server because server will send private key, (automatically I hope),
>
> if this is true how the server will authenticate the browser...
>
> MOST important question how I get all of this implemented, Is there
something else I should know?
>
> Sorry it seems basic questions, but I feel that it will be easer to u to
answer it. especially that Jersy documentation on the WWW is big. and I
am even confused about HTTPS
>
> by the way Thanks Thierry
>
> Thanks
>
Re: Well HTTPS
Hello,
I suggest you have a look at this
http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security (and then choose
the "keytool" documentation) and
http://blogs.sun.com/andreas/entry/no_more_unable_to_find.
You can find an explanation about the role of the keystore and the
trustore (try to get a clear idea of what these notions are). Try also
to get what is a server self certificate and how a client can trust it.
Then, you can make the link with the server connectors that support
HTTPS
(http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html).
Each of them require some parameters, especially some dedicated to the
server's keystore ("keystorePath", "keystorePassword", etc).
>Sorry it seems basic questions, but I feel that it will be easer to u
to answer it.
I don't think it's basic questions, but don't panic! Just read a little
bit more.
Best regards,
Thierry Boileau
--
Restlet ~ Core developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
WARNING
BRAIN OVERHEATING /\
I have read this
http://en.wikipedia.org/wiki/Https
and I want to implement HTTPS, in my sample application I converted
component.getServers().add(Protocol.HTTP, 8182);
to
component.getServers().add(Protocol.HTTPS, 8182);
Now Jersy is asking me a lot of questions in the shell (key and
pass), I guess the answer and I wrote "me" as an answer for both
questions!!
/home/java/.keystore is not found and Exception is thrown...
Is .keystore our Public Key Certificate, if yes, Is it created using
gensslcert??
and where is the private key?
if HTTPS is authenticating both sides (as I hardly understand) then
there must be one or two public keys and two private keys so server
can authenticate client and client can authenticate browser. the
browser will authenticate the server because server will send private
key, (automatically I hope),
if this is true how the server will authenticate the browser...
MOST important question how I get all of this implemented, Is there
something else I should know?
Sorry it seems basic questions, but I feel that it will be easer to u
to answer it. especially that Jersy documentation on the WWW is
big. and I am even confused about HTTPS
by the way Thanks Thierry
Thanks
