RE: Should @post annotation take 2 parameters?
Hi Conor I haven't tried this, but a quick look at the code seems to indicate that xml|json should work (i.e. use the pipe symbol to separate your media types). The code is in org.restlet.engine.resource.AnnotationInfo.java and it looks like everything after the colon is ignored, so xml:json will be truncated to just xml. Hope this helps Ben -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2583727
Re: Equivalent of Restlet for C++
Hi Jerome
Not sure if this is what you're after, but I've tried Simple XML
http://simple.sourceforge.net/ (XML only, not JSON) for an early prototype and
it seemed to work ok - haven't tried it production though. From memory you
need to have a default constructor with no parameters for XML deserialization,
e.g.
// Needed for deserialization
protected MyObject() {
// Whatever
}
I was following a builder pattern so did not intend to make the constructor
public, it was accessed through a builder class, but the XML deserialization
didn't work unless I defined the constructor.
Hope this helps
Ben
From: Jerome Louvel
Sent: Friday, January 15, 2010 4:51 PM
To: discuss@restlet.tigris.org
Subject: Equivalent of Restlet for C++
Hi all,
For a customer project, we have a need to provide a RESTful HTTP client and was
wondering if anyone had experience to share and recommendations.
Especially, are you aware of equivalents to XStream and Jackson to handle
serialization/deserialization of XML/JSON?
I know about NanoGear, an effort to port Restlet to C++, but it doesn't look
usable in production at this stage:
http://code.google.com/p/nanogear/
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2440510
Re: HTTPS trustAnchors error
Thanks Bruno. Dan, just in case you end up using the latest development
version of Restlet (v1.2), note that the classes have been refactored:
DefaultSslContextFactory has moved to
org.restlet.engine.util.DefaultSslContextFactory, so the sslContextFactory
parameter would be set as follows:
parameters.add(sslContextFactory,
org.restlet.engine.util.DefaultSslContextFactory);
Also in v1.2, PkixSslContextFactory has moved from
com.noelios.restlet.ext.ssl.PkixSslContextFactory to
org.restlet.ext.ssl.PkixSslContextFactory.
You'll get an exception when you start your component if you specify the
wrong one, for example specifying the v1.1 package when using v1.2 results
in:
WARNING: Unable to find SslContextFactory class:
com.noelios.restlet.util.DefaultSslContextFactory
java.lang.ClassNotFoundException:
com.noelios.restlet.util.DefaultSslContextFactory
If you're sticking to Restlet 1.1 for now, then use
com.noelios.restlet.util.DefaultSslContextFactory as Bruno indicated.
Cheers
Ben
--
From: Bruno Harbulot bruno.harbu...@manchester.ac.uk
Sent: Thursday, January 29, 2009 12:51 PM
To: discuss@restlet.tigris.org
Subject: Re: HTTPS trustAnchors error
Hi Dan,
It looks like a bug in the code I wrote... I'm going to look into this.
Can you try using com.noelios.restlet.util.DefaultSslContextFactory
instead of com.noelios.restlet.ext.ssl.PkixSslContextFactory meanwhile?
Best wishes,
Bruno.
Dan Noble wrote:
Hello all,
I am new to Restlets, and I am trying to set up a simple server to accept
HTTPS connections. (I'm using Restlets 1.1.2, Java 1.6 on OSX 10.5 and
my classpath has the following jars:
com.noelios.restlet.ext.ssl.jar
org.jsslutils.jar
org.simpleframework.jar
com.noelios.restlet.jar
org.restlet.jar
com.noelios.restlet.ext.simple_3.1.jar)
I have been following:
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html
To generate the keystore, i used:
keytool -genkey -v -alias serverX -keypass password -keystore
serverX.jks -keyalg RSA -sigalg MD5withRSA -keysize 2048 -validity
3650
and entered password for the keystore password for testing purposes.
Here is the code I have so far:
public static void main(String[] args) {
try {
// Create a new Component.
Component component = new Component();
// Add a new HTTPS server listening on port 8182.
Server server = component.getServers().add(Protocol.HTTPS,
8182);
SeriesParameter parameters =
server.getContext().getParameters();
File pwd = new File(.);
String path = pwd.getCanonicalPath();
String keystorePath = path + /keystore/serverX.jks;
parameters.add(sslContextFactory,
com.noelios.restlet.ext.ssl.PkixSslContextFactory);
parameters.add(keystorePath, keystorePath);
parameters.add(keystorePassword, password);
parameters.add(keyPassword, password);
parameters.add(keystoreType, JKS);
// Attach the sample application.
component.getDefaultHost().attach(,new
MessageForwarderApplication());
// Start the component.
component.start();
System.out.println(Started);
} catch (Exception e) {
// Something is wrong.
e.printStackTrace();
}
}
The exact exception is I'm getting is:
org.jsslutils.sslcontext.SSLContextFactory$SSLContextFactoryException:
Exception in SSLContextFactory
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getPKIXParameters(PKIXSSLContextFactory.java:231)
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getTrustParams(PKIXSSLContextFactory.java:190)
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getRawTrustManagers(PKIXSSLContextFactory.java:163)
at
org.jsslutils.sslcontext.X509SSLContextFactory.getTrustManagers(X509SSLContextFactory.java:346)
at
org.jsslutils.sslcontext.SSLContextFactory.buildSSLContext(SSLContextFactory.java:256)
at
com.noelios.restlet.ext.ssl.PkixSslContextFactory.createSslContext(PkixSslContextFactory.java:72)
at
com.noelios.restlet.ext.simple.HttpsServerHelper.start(HttpsServerHelper.java:267)
at org.restlet.Server.start(Server.java:383)
at org.restlet.Component.startServers(Component.java:1233)
at org.restlet.Component.start(Component.java:1194)
at
com.test.messageservice.MessageService.main(MessageService.java:55)
// --- component.start(); line
Caused by: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183)
at
java.security.cert.PKIXParameters.init(PKIXParameters.java:140)
at
Re: thinking about standard rest service api's
Hi Marc I'll be interested to read through your wiki. A small comment - you've got a typo on 'RestService API Allignment'. 'Allignment' should be 'Alignment'. Regards Ben Johnson -- From: Marc Portier m...@outerthought.org Sent: Thursday, January 15, 2009 3:10 PM To: discuss@restlet.tigris.org Subject: thinking about standard rest service api's Hi all, We've been doing some framework stuff on top of restlet and named that kauri (see http://kauriproject.org/) During that work we're seeing some recurring issues popping up that could be reflected in recurring or even standardized URI pattern designs. Guessing we might not be alone in this feeling we're looking for other people that are likely to share sentiments, feelings, insights, critiques on this. Some first thoughts are listed on our wiki at: http://kauriproject.org/wiki/g2/319-kauri.html Any feedback here, on our list at http://groups.google.com/group/kauri-discuss is welcomed. regards, -marc= -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1026556 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1026696
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 mohamed@gmail.com
Sent: Monday, December 15, 2008 11:24 AM
To: discuss@restlet.tigris.org
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 JRE\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
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 jdmitch...@gmail.com Sent: Tuesday, December 16, 2008 5:04 PM To: discuss@restlet.tigris.org 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=4447dsMessageId=985102 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=985270
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: discuss@restlet.tigris.org
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: discuss@restlet.tigris.org
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 JRE\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
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 JRE\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);
SeriesParameter parameters = server.getContext().getParameters();
parameters.add(sslContextFactory,
com.noelios.restlet.ext.ssl.PkixSslContextFactory);
parameters.add(keystorePath, pathserverX.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 doesn't seem to work
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: discuss@restlet.tigris.org
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 JRE\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
