在 Java 中将 HTTPS 与 REST 结合使用
我有一个用 Grizzly 制作的 REST 服务器,它使用 HTTPS,并且与 Firefox 配合得很好。代码如下:
//Build a new Servlet Adapter.
ServletAdapter adapter=new ServletAdapter();
adapter.addInitParameter("com.sun.jersey.config.property.packages", "My.services");
adapter.addInitParameter(ResourceConfig.PROPERTY_CONTAINER_REQUEST_FILTERS, SecurityFilter.class.getName());
adapter.setContextPath("/");
adapter.setServletInstance(new ServletContainer());
//Configure SSL (See instructions at the top of this file on how these files are generated.)
SSLConfig ssl=new SSLConfig();
String keystoreFile=Main.class.getResource("resources/keystore_server.jks").toURI().getPath();
System.out.printf("Using keystore at: %s.",keystoreFile);
ssl.setKeyStoreFile(keystoreFile);
ssl.setKeyStorePass("asdfgh");
//Build the web server.
GrizzlyWebServer webServer=new GrizzlyWebServer(getPort(9999),".",true);
//Add the servlet.
webServer.addGrizzlyAdapter(adapter, new String[]{"/"});
//Set SSL
webServer.setSSLConfig(ssl);
//Start it up.
System.out.println(String.format("Jersey app started with WADL available at "
+ "%sapplication.wadl\n",
"https://localhost:9999/"));
webServer.start();
现在,我尝试用 Java 访问它:
SSLContext ctx=null;
try {
ctx = SSLContext.getInstance("SSL");
} catch (NoSuchAlgorithmException e1) {
e1.printStackTrace();
}
ClientConfig config=new DefaultClientConfig();
config.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, new HTTPSProperties(null,ctx));
WebResource service=Client.create(new DefaultClientConfig()).resource("https://localhost:9999/");
//Attempt to view the user's page.
try{
service
.path("user/"+username)
.get(String.class);
}
并得到:
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:128)
at com.sun.jersey.api.client.Client.handle(Client.java:453)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:557)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:179)
从我在网上找到的示例来看,我似乎需要设置一个 Truststore,然后设置某种 TrustManager。对于我的简单小项目来说,这似乎有很多代码和设置工作。有没有更简单的方法可以说..我信任这个证书并指向 .cert 文件?
I have a REST server made in Grizzly that uses HTTPS and works wonderfully with Firefox. Here's the code:
//Build a new Servlet Adapter.
ServletAdapter adapter=new ServletAdapter();
adapter.addInitParameter("com.sun.jersey.config.property.packages", "My.services");
adapter.addInitParameter(ResourceConfig.PROPERTY_CONTAINER_REQUEST_FILTERS, SecurityFilter.class.getName());
adapter.setContextPath("/");
adapter.setServletInstance(new ServletContainer());
//Configure SSL (See instructions at the top of this file on how these files are generated.)
SSLConfig ssl=new SSLConfig();
String keystoreFile=Main.class.getResource("resources/keystore_server.jks").toURI().getPath();
System.out.printf("Using keystore at: %s.",keystoreFile);
ssl.setKeyStoreFile(keystoreFile);
ssl.setKeyStorePass("asdfgh");
//Build the web server.
GrizzlyWebServer webServer=new GrizzlyWebServer(getPort(9999),".",true);
//Add the servlet.
webServer.addGrizzlyAdapter(adapter, new String[]{"/"});
//Set SSL
webServer.setSSLConfig(ssl);
//Start it up.
System.out.println(String.format("Jersey app started with WADL available at "
+ "%sapplication.wadl\n",
"https://localhost:9999/"));
webServer.start();
Now, I try to reach it in Java:
SSLContext ctx=null;
try {
ctx = SSLContext.getInstance("SSL");
} catch (NoSuchAlgorithmException e1) {
e1.printStackTrace();
}
ClientConfig config=new DefaultClientConfig();
config.getProperties().put(HTTPSProperties.PROPERTY_HTTPS_PROPERTIES, new HTTPSProperties(null,ctx));
WebResource service=Client.create(new DefaultClientConfig()).resource("https://localhost:9999/");
//Attempt to view the user's page.
try{
service
.path("user/"+username)
.get(String.class);
}
And get:
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:128)
at com.sun.jersey.api.client.Client.handle(Client.java:453)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:557)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:179)
From examples that I've found on the web, it seems like I would need to setup a Truststore then setup some sort of TrustManager. This seems like a lot of code and setup work for my simple little project. Is there an easier way to just say..I trust this cert and point to a .cert file?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
当您说“是否有更简单的方法来...信任此证书”时,这正是您通过将证书添加到 Java 信任存储中所做的事情。这非常非常容易做到,您无需在客户端应用程序中执行任何操作即可识别或使用该信任存储。
在您的客户端计算机上,找到您的 cacerts 文件所在的位置(这是您的默认 Java 信任存储,默认情况下位于/lib/security/certs/cacerts。
然后,键入以下内容
: 您的客户端应用程序将能够毫无问题地连接到 Grizzly HTTPS 服务器。
将证书导入到您的信任存储中,之后,如果您不想将证书导入到默认信任存储中, 它可供该客户端应用程序使用,但不适用于您在该计算机上的 JVM 上运行的任何其他应用程序 - 那么您可以仅为您的应用程序创建一个新的信任存储,而不是将 keytool 传递到现有的默认 cacerts 的路径。文件,将 keytool 传递到新信任存储文件的路径:
系统会要求您设置并验证信任存储文件的新密码然后,当您启动客户端应用程序时,使用以下参数启动它:
Easy cheesy,真的。
When you say "is there an easier way to... trust this cert", that's exactly what you're doing by adding the cert to your Java trust store. And this is very, very easy to do, and there's nothing you need to do within your client app to get that trust store recognized or utilized.
On your client machine, find where your cacerts file is (that's your default Java trust store, and is, by default, located at <java-home>/lib/security/certs/cacerts.
Then, type the following:
That will import the cert into your trust store, and after this, your client app will be able to connect to your Grizzly HTTPS server without issue.
If you don't want to import the cert into your default trust store -- i.e., you just want it to be available to this one client app, but not to anything else you run on your JVM on that machine -- then you can create a new trust store just for your app. Instead of passing keytool the path to the existing, default cacerts file, pass keytool the path to your new trust store file:
You'll be asked to set and verify a new password for the trust store file. Then, when you start your client app, start it with the following parameters:
Easy cheesy, really.
这是痛苦的路线:
必须喜欢那六个不同的捕获异常:)。当然有一些重构可以稍微简化代码。但是,我喜欢虚拟机上 delfuego 的 -D 选项。我希望有一个可以设置的 javax.net.ssl.trustStore 静态属性。只需两行代码就完成了。有人知道那会在哪里吗?
这可能要求太多,但是,理想情况下不会使用 keytool。相反,trustedStore 将由代码动态创建,并在运行时添加证书。
一定有更好的答案。
Here's the painful route:
Gotta love those six different caught exceptions :). There are certainly some refactoring to simplify the code a bit. But, I like delfuego's -D options on the VM. I wish there was a javax.net.ssl.trustStore static property that I could just set. Just two lines of code and done. Anyone know where that would be?
This may be too much to ask, but, ideally the keytool would not be used. Instead, the trustedStore would be created dynamically by the code and the cert is added at runtime.
There must be a better answer.
需要记住的是,此错误不仅仅是由于自签名证书造成的。新的 Entrust CA 证书因相同的错误而失败,正确的做法是使用适当的根证书更新服务器,而不是禁用这一重要的安全功能。
Something to keep in mind is that this error isn't only due to self signed certs. The new Entrust CA certs fail with the same error, and the right thing to do is to update the server with the appropriate root certs, not to disable this important security feature.
请查看:http://code.google.com/p/resting/。我可以利用休息来消耗
HTTPS REST 服务。
Check this out: http://code.google.com/p/resting/. I could use resting to consume
HTTPS REST services.
delfuego的答案是解决证书问题最简单的方法。但是,就我而言,我们的第三方网址之一(使用 https)每 2 个月自动更新一次他们的证书。这意味着我还必须每 2 个月手动将证书导入到我们的 Java 信任存储中。有时它会导致生产问题。
因此,我使用 SecureRestClientTrustManager 制定了一种方法来解决此问题,以便能够在不导入证书文件的情况下使用 https url。
方法如下:
The answer of delfuego is the simplest way to solve the certificate problem. But, in my case, one of our third party url (using https), updated their certificate every 2 months automatically. It means that I have to import the cert to our Java trust store manually every 2 months as well. Sometimes it caused production problems.
So, I made a method to solve it with SecureRestClientTrustManager to be able to consume https url without importing the cert file.
Here is the method: