Programmatically Configure SSL for Jetty 9 embedded - ssl

I'm using jetty version 9.0.0.M4 and am trying to configure it to accept SSL connections.
following the instructions in:
http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html
I've managed to write something that works.
However, the code I wrote seems ugly and unnecessarily complex.
Any idea how to do this properly?
final Server server = new Server(Config.Server.PORT);
SslContextFactory contextFactory = new SslContextFactory();
contextFactory.setKeyStorePath(Config.Location.KEYSTORE_LOCATION);
contextFactory.setKeyStorePassword("******");
SslConnectionFactory sslConnectionFactory = new SslConnectionFactory(contextFactory, org.eclipse.jetty.http.HttpVersion.HTTP_1_1.toString());
HttpConfiguration config = new HttpConfiguration();
config.setSecureScheme("https");
config.setSecurePort(Config.Server.SSL_PORT);
config.setOutputBufferSize(32786);
config.setRequestHeaderSize(8192);
config.setResponseHeaderSize(8192);
HttpConfiguration sslConfiguration = new HttpConfiguration(config);
sslConfiguration.addCustomizer(new SecureRequestCustomizer());
HttpConnectionFactory httpConnectionFactory = new HttpConnectionFactory(sslConfiguration);
ServerConnector connector = new ServerConnector(server, sslConnectionFactory, httpConnectionFactory);
connector.setPort(Config.Server.SSL_PORT);
server.addConnector(connector);
server.start();
server.join();

The ServerConnector should be setup with an SslContextFactory.
The rest of the work you are doing in the HttpConfiguration is irrelevant to setting up SSL.
A good example of setting up SSL in embedded mode is maintained in the embedded jetty examples project.
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/examples/embedded/src/main/java/org/eclipse/jetty/embedded/LikeJettyXml.java
Edit: to be more clear (thanks Erik)
Update: June 2016
The Eclipse Jetty Project has moved its canonical repository to github.
The above LikeJettyXml.java can now be found at
https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/examples/embedded/src/main/java/org/eclipse/jetty/embedded/LikeJettyXml.java

For Jetty 9 there is a good reference here and all you need to do is to create the JKS keystore file as explained here.
using the command keytool -genkey -alias sitename -keyalg RSA -keystore keystore.jks -keysize 2048. For some reason what works with jetty 8 is not what works on 9.

For those who can't get above configuration working:
If you are using java 1.7, ensure you have latest update of it. First versions of jvm 1.7 cause problems with accessing https web pages (browser may display: connection reset, connection aborted, or no data received error).

Related

Make Https request with the netty4-http component of Apache Camel

I exposed a simple REST service with Apache Camel like Spring boot microservice, which creates a request to a service in https, using the netty4-http component.
public class RoutingTest extends RouteBuilder {
#Override
public void configure() throws Exception {
restConfiguration()
.host("localhost")
.port("8080");
rest().post("test")
.route()
.setBody(constant("message=Hello"))
.setHeader(Exchange.HTTP_METHOD, constant(HttpMethod.POST))
.setHeader(Exchange.CONTENT_TYPE, constant("application/x-www-form-urlencoded"))
.to("netty4-http:https://localhost/service/test");
}
}
When i call http://localhost:8080/test, I get 400 Bad Request error when the routing call https://localhost/service/test service.From the logs I read that the request arrives in HTTP instead HTTPS format and I don't understand why:
You're speaking plain HTTP to an SSL-enabled server port. Instead use
the HTTPS scheme to access this URL, please.
If I invoke the service https://localhost/service/test with Postman, it works correctly.
SSL is configured with a Self-signed certificate.
How do I create a correct https request with the netty component in apache camel? The documentation only suggests the replacement of the protocol, at most a few options which however do not work.
UPDATE (SOLVED SEE BELOW)
I updated the call in this way
.to("netty4-http:https://localhost/dpm/idp/oauth/token?ssl=true&sslContextParameters=#sslContextParameters");
The ssl = true parameter is mandatory and I have also configured the bean for SSLContextParameters like this:
#Bean(name = "sslContextParameters")
public static SSLContextParameters sslParameters() throws KeyManagementException, GeneralSecurityException, IOException {
KeyStoreParameters ksp = new KeyStoreParameters();
ksp.setResource("C:/myfolder/test.jks");
KeyManagersParameters kmp = new KeyManagersParameters();
kmp.setKeyStore(ksp);
kmp.setKeyPassword("jskPassword");
SSLContextParameters scp = new SSLContextParameters();
scp.setKeyManagers(kmp);
SSLContextBuilder builder = new SSLContextBuilder();
builder.loadTrustMaterial(new TrustSelfSignedStrategy());
SSLContext sslcontext = builder.build();
scp.createSSLContext().setDefault(sslcontext);
return scp;
}
I am fighting a bit with the classes that are deprecated. For testing I leave only one method deprecated because I should work with inheritance.
If I understood correctly, I had to generate a JKS file for the trust zone, starting from my self-signed certificates (.crt and .key files). Once done, I added the instructions for the KeyStoreParameters with the password.
It is almost solved, but now I am getting this error when i execute the
PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
You probably need to configure a sslContextParameters object that you can use to configure the Netty component for SSL.
I am not sure about the parameter name. The docs say sslContextParameters, but I thought it was sslContextParametersRef.
.to("netty4-http:https://localhost/service/test?sslContextParametersRef=#sslConfig");
The #sslConfig means that Camel can get the object from the registry with the identifier sslConfig. So for example with Spring this would be a Spring managed Bean with ID sslConfig.
The Netty component (not http) also has a parameter ssl=true. No idea if this is also needed for Netty-http. So you will have to test a bit with these different parameters.
By the way the docs of the Netty component have an SSL example with context parameter configuration etc. Have a look at it.
Resolved. Some instructions needed for the self-signed certificate were missing.
Below is the complete bean.
#Bean(name = "sslContextParameters")
public static SSLContextParameters sslParameters() throws KeyManagementException, GeneralSecurityException, IOException {
KeyStoreParameters ksp = new KeyStoreParameters();
ksp.setResource("C:/myfolder/test.jks");
ksp.setPassword("jskPassword");
KeyManagersParameters kmp = new KeyManagersParameters();
kmp.setKeyStore(ksp);
kmp.setKeyPassword("jskPassword");
SSLContextParameters scp = new SSLContextParameters();
scp.setKeyManagers(kmp);
SSLContextBuilder builder = new SSLContextBuilder();
builder.loadTrustMaterial(null, new TrustSelfSignedStrategy());
SSLContext sslcontext = builder.build();
scp.createSSLContext().setDefault(sslcontext);
// Necessary for the the self-signed server certificate
TrustManagersParameters tmp = new TrustManagersParameters();
tmp.setKeyStore(ksp);
scp.setTrustManagers(tmp);
return scp;
}
As for the test.jks file, I created it with keytool, the tool supplied with the JDK for managing certificates (creation, export and import).
In my case having already created the certificate with OpenSSL, I had to create only the JKS (Java Keystore) file to be imported. For it is necessary to convert the certificate in the P12 file (it should be an archive) and finally in the JKS.
During the operations you will be asked to enter passwords for both files
- openssl pkcs12 -export -in test.crt -inkey test.key -out test.p12
- keytool -importkeystore -srckeystore test.p12 -destkeystore test.jks -srcstoretype pkcs12
- keytool -importkeystore -srckeystore test.jks -destkeystore test.jks -deststoretype pkcs12
here test is the name of my certificate file. The last operation is not mandatory but it is recommended by keytool itself in order to migrate the JKS format, proprietary format if I understand correctly, to the more common PKCS12 format.
The value jskPassword in the code is the password I set when creating the keystore.
I hope it will help.

wso2is - Adding new keystore

I'm trying to set up a new keystore in wso2is, I follow the 2 guides :
https://docs.wso2.com/display/ADMIN446/Creating+New+Keystores
https://docs.wso2.com/display/Carbon443/Configuring+Keystores+in+WSO2+Products
In the https://docs.wso2.com/display/Carbon443/Configuring+Keystores+in+WSO2+Products it says to change keystore in sec.policy, but the file doesn't exist in IS 5.2.0
Although the guide don't talk about theses files, where the default keystore seem to be used :
conf/identity/EndpointConfig.properties
conf/security/secret-conf.properties
conf/security/cipher-text.properties
I have a webapp calling wso2is, the keystore has been added in the JVM using -Djavax.net.ssl.trustStore=/path/to/newkeystore.jks -Djavax.net.ssl.trustStorePassword=mypassword
When calling oauth2 endpoint (https://myinternaldomain:9443/oauth2/token) I got this error :
TID: [1] [] [2017-01-10 13:30:14,505] #tenant1.com [1] [IS] INFO
{org.wso2.carbon.core.deployment.DeploymentInterceptor} - Deploying
Axis2 service: wso2carbon-sts {tenant1.com[1]} TID: [1] [] [2017-01-10
13:30:14,536] admin#tenant1.com [1] [IS]ERROR
{org.wso2.carbon.core.deployment.DeploymentInterceptor} - Error while
updating wso2carbon-sts in STSDeploymentInterceptor
java.io.IOException: Keystore was tampered with, or password was
incorrect
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:780)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
at java.security.KeyStore.load(KeyStore.java:1445)
at org.wso2.carbon.core.util.KeyStoreManager.getKeyStore(KeyStoreManager.java:146)
I did not change anything regarding keystore in the axis2.xml because all information regarding the keystore are commented.
All other endpoints (soap enpoints) are working fine with SSL, and everything works fine with localhost and default wso2carbon.jks
but I cannot make oauth2/token endpoint work with a new jks.
Thanks for your input, ideas.
Regards
I got it working by adding the public key in the java default keystore
keytool -import -v -alias certalias -file newkeystore.pem -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit
and by doing the following configuration which should definitely be in the wso2is keystore configuration documentation !
http://xacmlinfo.org/2014/11/05/how-to-changing-the-primary-keystore-of-a-tenant-in-carbon-products/

JMeter: "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" while recording in JMeter [duplicate]

I am getting javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake exception when I try to do HTTPS Post of a web service through internet. But same code works for other internet hosted web services. I tried many things, nothing is helping me. I posted my sample code here. Can anyone please help me to resolve this problem?
public static void main(String[] args) throws Exception {
String xmlServerURL = "https://example.com/soap/WsRouter";
URL urlXMLServer = new URL(xmlServerURL);
// URLConnection supports HTTPS protocol only with JDK 1.4+
Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress(
"xxxx.example.com", 8083));
HttpURLConnection httpsURLConnection = (HttpURLConnection) urlXMLServer
.openConnection(proxy);
httpsURLConnection.setRequestProperty("Content-Type","text/xml; charset=utf-8");
//httpsURLConnection.setDoInput(true);
httpsURLConnection.setDoOutput(true);
httpsURLConnection.setConnectTimeout(300000);
//httpsURLConnection.setIgnoreProxy(false);
httpsURLConnection.setRequestMethod("POST");
//httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY);
// send request
PrintWriter out = new PrintWriter(
httpsURLConnection.getOutputStream());
StringBuffer requestXML = new StringBuffer();
requestXML.append(getProcessWorkOrderSOAPXML());
// get list of user
out.println(requestXML.toString());
out.close();
out.flush();
System.out.println("XML Request POSTed to " + xmlServerURL + "\n");
System.out.println(requestXML.toString() + "\n");
//Thread.sleep(60000);
// read response
BufferedReader in = new BufferedReader(new InputStreamReader(
httpsURLConnection.getInputStream()));
String line;
String respXML = "";
while ((line = in.readLine()) != null) {
respXML += line;
}
in.close();
// output response
respXML = URLDecoder.decode(respXML, "UTF-8");
System.out.println("\nXML Response\n");
System.out.println(respXML);
}
Full stacktrace:
Exception in thread "main" javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
at com.labcorp.efone.vendor.TestATTConnectivity.main(TestATTConnectivity.java:43)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
... 8 more
Actually, there are two scenarios here. When I work as a standalone Java program I am getting the above exception. But when I try to execute in weblogic application server, I am getting the below exception: Any clue what could be the reason?
java.io.IOException: Connection closed, EOF detected
at weblogic.socket.JSSEFilterImpl.handleUnwrapResults(JSSEFilterImpl.java:637)
at weblogic.socket.JSSEFilterImpl.unwrapAndHandleResults(JSSEFilterImpl.java:515)
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:96)
at weblogic.socket.JSSEFilterImpl.doHandshake(JSSEFilterImpl.java:75)
at weblogic.socket.JSSEFilterImpl.write(JSSEFilterImpl.java:448)
at weblogic.socket.JSSESocket$JSSEOutputStream.write(JSSESocket.java:93)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.java:192)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:433)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
at com.labcorp.efone.service.impl.WorkOrderServiceImpl.processATTWorkOrder(ATTWorkOrderServiceImpl.java:86)
at com.labcorp.efone.bds.WorkOrderBusinessDelegateImpl.processATTWorkOrder(WorkOrderBusinessDelegateImpl.java:59)
at com.labcorp.efone.actions.ATTWorkOrderAction.efonePerformForward(ATTWorkOrderAction.java:41)
at com.labcorp.efone.actions.EfoneAction.efonePerformActionForward(EfoneAction.java:149)
at com.labcorp.efone.actions.EfoneAction.execute(EfoneAction.java:225)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:751)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at com.labcorp.efone.security.EfoneAuthenticationFilter.doFilter(EfoneAuthenticationFilter.java:115)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3367)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3333)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2220)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2146)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2124)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1564)
at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
Exception: java.io.IOException: Connection closed, EOF detected
Java 7 defaults to TLS 1.0, which can cause this error when that protocol is not accepted. I ran into this problem with a Tomcat application and a server that would not accept TLS 1.0 connections any longer. I added
-Dhttps.protocols=TLSv1.1,TLSv1.2
to the Java options and that fixed it. (Tomcat was running Java 7.)
I faced the same problem and solved it by adding:
System.setProperty("https.protocols", "TLSv1,TLSv1.1,TLSv1.2");
before openConnection method.
Not an answer yet, but too much for a comment. This is clearly not a server cert problem; the symptoms of that are quite different. From your system's POV, the server appears to be closing during the handshake. There are two possibilities:
The server really is closing, which is a SSL/TLS protocol violation though a fairly minor one; there are quite a few reasons a server might fail to handshake with you but it should send a fatal alert first, which your JSSE or the weblogic equivalent should indicate. In this case there may well be some useful information in the server log, if you are able (and permitted) to communicate with knowledgeable server admin(s). Or you can try putting a network monitor on your client machine, or one close enough it sees all your traffic; personally I like www.wireshark.org. But this usually shows only that the close came immediately after the ClientHello, which doesn't narrow it down much. You don't say if you are supposed to and have configured a "client cert" (actually key&cert, in the form of a Java privateKeyEntry) for this server; if that is required by the server and not correct, some servers may perceive that as an attack and knowingly violate protocol by closing even though officially they should send an alert.
Or, some middlebox in the network, most often a firewall or purportedly-transparent proxy, is deciding it doesn't like your connection and forcing a close. The Proxy you use is an obvious suspect; when you say the "same code" works to other hosts, confirm if you mean through the same proxy (not just a proxy) and using HTTPS (not clear HTTP). If that isn't so, try testing to other hosts with HTTPS through the proxy (you needn't send a full SOAP request, just a GET / if enough). If you can, try connecting without the proxy, or possibly a different proxy, and connecting HTTP (not S) through the proxy to the host (if both support clear) and see if those work.
If you don't mind publishing the actual host (but definitely not any authentication credentials) others can try it. Or you can go to www.ssllabs.com and request they test the server (without publishing the results); this will try several common variations on SSL/TLS connection and report any errors it sees, as well as any security weaknesses.
A first step to diagnose the issue is by starting the client - and if you are running the server yourself, a private test instance of the server - by starting Java with the VM option:
-Djavax.net.debug=all
See also https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https
I encountered a similar problem with glassfish application server and Oracle JDK/JRE but not in Open JDK/JRE.
When connecting to a SSL domain I always ran into:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
...
Caused by: java.io.EOFException: SSL peer shut down incorrectly
The solution for me was to install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files because the server only understood certificates that are not included in Oracle JDK by default, only OpenJDK includes them.
After installing everything worked like charme.
JCE 7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
JCE 8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
I think you are missing your certificates.
You can try generating them by using InstallCerts app. Here you can see how to use it:
https://github.com/escline/InstallCert
Once you get your certificate, you need to put it under your security directory within your jdk home, for example:
C:\Program Files\Java\jdk1.6.0_45\jre\lib\security
Let me know if it works.
I ran into a similar issue and found I was hitting the wrong port. After fixing the port things worked great.
In my case, I got this problem because I had given the server a non-existent certificate, due to a typo in the config file. Instead of throwing an exception, the server proceeded like normal and sent an empty certificate to the client. So it might be worth checking to make sure that the server is providing the correct response.
I experienced this error while using the Jersey Client to connect to a server. The way I resolved it was by debugging the library and seeing that it actually did receive an EOF the moment it tried to read. I also tried connecting using a web browser and got the same results.
Just writing this here in case it ends up helping anyone.
You May Write this below code insdie your current java programme
System.setProperty("https.protocols", "TLSv1.1");
or
System.setProperty("http.proxyHost", "proxy.com");
System.setProperty("http.proxyPort", "911");
Thanks to all for sharing your answers and examples. The same standalone program worked for me by small changes and adding the lines of code below.
In this case, keystore file was given by webservice provider.
// Small changes during connection initiation..
// Please add this static block
static {
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()
{ #Override
public boolean verify(String hostname, SSLSession arg1) {
// TODO Auto-generated method stub
if (hostname.equals("X.X.X.X")) {
System.out.println("Return TRUE"+hostname);
return true;
}
System.out.println("Return FALSE");
return false;
}
});
}
String xmlServerURL = "https://X.X.X.X:8080/services/EndpointPort";
URL urlXMLServer = new URL(null,xmlServerURL,new sun.net.www.protocol.https.Handler());
HttpsURLConnection httpsURLConnection = (HttpsURLConnection) urlXMLServer .openConnection();
// Below extra lines are added to the same program
//Keystore file
System.setProperty("javax.net.ssl.keyStore", "Drive:/FullPath/keystorefile.store");
System.setProperty("javax.net.ssl.keyStorePassword", "Password"); // Password given by vendor
//TrustStore file
System.setProperty("javax.net.ssl.trustStore"Drive:/FullPath/keystorefile.store");
System.setProperty("javax.net.ssl.trustStorePassword", "Password");
I encountered this problem with Java 1.6. Running under Java 1.7 fixed my particular rendition of the problem. I think the underlying cause was that the server I was connecting to must have required stronger encryption than was available under 1.6.
I had the same error, but in my case it was caused by the DEBUG mode in Intellij IDE. The debug slowed down the library and then server ended communication at handshake phase. The standard "RUN" worked perfectly.
I run my application with Java 8 and Java 8 brought security certificate onto its trust store. Then I switched to Java 7 and added the following into VM options:
-Djavax.net.ssl.trustStore=C:\<....>\java8\jre\lib\security\cacerts
Simply I pointed to the location where a certificate is.
I was using the p12 which I exported with Keychain in my MacBook, however, it didn't work on my java-apns server code. What I had to do was to create a new p12 key as stated here, using my already generated pem keys:
openssl pkcs12 -export -in your_app.pem -inkey your_key.pem -out your_app_key.p12
Then updated the path to that new p12 file and everything worked perfectly.
How you would solve it is by going to
Settings
Search"Network"
Choose "Use IDEA general proxy settings as default Subversion"
As per https://kb.informatica.com/solution/23/Pages/69/570664.aspx adding this property works
CryptoProtocolVersion=TLSv1.2
With base at TLSv1.2 ALERT: fatal, handshake_failure I obtained after debug with this thread previos answer
-Djavax.net.debug=all
I went to https://www.ssllabs.com/and observed that the web server required a SSLv3 connection deprecate at june 2015, and deprecated at JDKu31 Release notes
I edited the ${java_home}/jre/lib/security/java.security at the line
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024,
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
to
jdk.tls.disabledAlgorithms= RC4, DES, MD5withRSA, DH keySize < 1024,
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
As a final step I got this error
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [javax.net.ssl.SSLHandshakeException]
I fixed this intalling the cert with the java keytool, following this answer PKIX path building failed” and “unable to find valid certification path to requested target”
I get this error when specifying a https url and in the same url explicitly specifying an http port (instead of an https port). Removing the explicit port :8080 solved the issue for me.
Adding certificates to Java\jdk\jre\lib\security folder worked for me. If you are using Chrome click on the green bulb [https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1] and save the certificate in security folder.
I faced the same issue once. I think its because of the URL
String xmlServerURL = "https://example.com/soap/WsRouter";
Check whether its a proper one or not ??
javax.net.ssl.SSLHandshakeException is because the server not able to connect to the specified URL because of following reason-
Either the identity of the website is not verified.
Server's certificate does not match the URL.
Or, Server's certificate is not trusted.
This is what solve my problem.
If you are trying to use debugger make sure you breakpoint is not on URL or URLConnection just put your breakpoint on BufferReader or inside while loop.
If nothing works try using apache library http://hc.apache.org/index.html.
no SSL, no JDK update needed, no need to set properties even, just simple trick :)

wss certificate configuration

I'd like to know if it is possible to configure a certificate for wss when using restcomm sipservlets with a keystoretype PKCS12
I found this post:
SIPML 5 Client and SipServlets not works Using WSS
and looked to modify the suggestion to :
gov.nist.javax.sip.TLS_CLIENT_AUTH_TYPE=Disabled
javax.net.ssl.keystoreFile="conf/STAR_domain.pfx"
javax.net.ssl.keyStorePassword="pkcspass"
javax.net.ssl.keystoreType="PKCS12"
my connector config:
<Connector port="10443"
ipAddress = "ip.address"
protocol="org.mobicents.servlet.sip.startup.SipProtocolHandler"
signalingTransport="wss"/>
When opening a socket to this port I don't get a server hello. Meaning the cert wasn't loaded?
Please Read and follow the steps at http://docs.telestax.com/sip-servlets-security/

ColdFusion CFHTTP I/O Exception: peer not authenticated - even after adding certs to Keystore

I'm currently working with a payment processor. I can browse to the payment URL from our server, so it's not a firewall issue, but when I try to use CFHTTP I get a I/O Exception: peer not authenticated. I've downloaded and installed their latest security cert into cacerts keystore and restarted CF and am still getting the same error. Not only have I installed the providers cert, but also the 2 other Verisign certificate authority certs in the certificate chain. The cert is one of the newer Class 3 Extended Validation certs.
Has anybody come across this before and found a solution?
A colleague of mine found the following after experiencing the same issue when connecting to a 3rd party.
http://www.coldfusionjedi.com/index.cfm/2011/1/12/Diagnosing-a-CFHTTP-issue--peer-not-authenticated
https://www.raymondcamden.com/2011/01/12/Diagnosing-a-CFHTTP-issue-peer-not-authenticated/
We used the solution provided in the comment by Pete Freitag further down the page. It works, but I think should be used with caution, as it involves dynamically removing and adding back in a particular property of the JsafeJCE provider.
For the sake of archiving, here is the original content of Pete Freitag's comment:
I've narrowed this down a bit further, and removing the
KeyAgreement.DiffieHellman from the RSA JsafeJCE provider (which
causes the default sun implementation to be used instead) seams to
work, and probably has less of an effect on your server than removing
the entire provider would. Here's how you do it:
<cfset objSecurity = createObject("java", "java.security.Security") />
<cfset storeProvider = objSecurity.getProvider("JsafeJCE") />
<cfset dhKeyAgreement = storeProvider.getProperty("KeyAgreement.DiffieHellman")>
<!--- dhKeyAgreement=com.rsa.jsafe.provider.JSA_DHKeyAgree --->
<cfset storeProvider.remove("KeyAgreement.DiffieHellman")>
Do your http call, but pack the key agreement if you want:
<cfset storeProvider.put("KeyAgreement.DiffieHellman", dhKeyAgreement)>
I figured this out by using the SSLSocketFactory to create a https
connection, which provided a bit more details in the stack trace, than
when using cfhttp:
yadayadayada Caused by: java.security.InvalidKeyException: Cannot
build a secret key of algorithm TlsPremasterSecret at
com.rsa.jsafe.provider.JS_KeyAgree.engineGenerateSecret(Unknown
Source) at javax.crypto.KeyAgreement.generateSecret(DashoA13*..) at
com.sun.net.ssl.internal.ssl.DHCrypt.getAgreedSecret(DHCrypt.java:166)
Would be great if the exception thrown from ColdFusion was a bit less
generic.
specific to coldfusion 8 with an webserver with modern ssl ciphers:
I use coldfusion 8 on JDK 1.6.45 and had problems with <cfdocument ...> giving me just red crosses instead of images, and also with cfhttp not able to connect to the local webserver with ssl.
my test script to reproduce with coldfusion 8 was
<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">
this gave me the quite generic error of " I/O Exception: peer not authenticated."
I then tried to add certificates of the server including root and intermediate certificates to the java keystore and also the coldfusion keystore, but nothing helped.
then I debugged the problem with
java SSLPoke www.onlineumfragen.com 443
and got
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
and
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 1024 (inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107)
... 10 more
I then had the idea that the webserver (apache in my case) had very modern ciphers for ssl and is quite restrictive (qualys score a+) and uses strong Diffie-Hellman groups with more than 1024 bits. obviously, coldfusion and java jdk 1.6.45 can not manage this.
Next step in the odyssee was to think of installing an alternative security provider for java, and I decided for bouncy castle.
see also http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/
I then downloaded the
bcprov-ext-jdk15on-156.jar
from http://www.bouncycastle.org/latest_releases.html and installed it under
C:\jdk6_45\jre\lib\ext or where ever your jdk is, in original install of coldfusion 8 it would be under C:\JRun4\jre\lib\ext but I use a newer jdk (1.6.45) located outside the coldfusion directory. it is very important to put the bcprov-ext-jdk15on-156.jar in the \ext directory (this cost me about two hours and some hair ;-)
then I edited the file C:\jdk6_45\jre\lib\security\java.security (with wordpad not with editor.exe!) and put in one line for the new provider. afterwards the list looked like
#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
(see the new one in position 1)
then restart coldfusion service completely.
you can then
java SSLPoke www.onlineumfragen.com 443 (or of course your url!)
and enjoy the feeling...
and of course
<cfhttp and <cfdocument worked like a charm and like before we "hardened" our ssl ciphers in apache!
what a night and what a day. Hopefully this will help (partially or fully) to someone out there. if you have questions, just mail me at info ... (domain above).
Did you add it to the correct keystore? Remember that ColdFusion uses it's own Java instance. I spent several hours on this once before remembering that fact. The one you want is at somewhere like /ColdFusion8/runtime/jre/lib/security/
Try with this in CMD
C:\ColdFusion9\runtime\jre\bin>
keytool -import -keystore ../lib/security/cacerts
-alias uniquename -file certificatename.cer
Note: We must choose the correct keystore present inside the security folder,as there are other keystore file present inside bin.If we will import the certificate to those key stores it will not work.
What I just found out was referenced at this article: http://kb2.adobe.com/cps/400/kb400977.html and a few other places after a lot of digging.
If you are looking at this article you have most likely inserted your "server.crt" certificate in the proper root locations and you have probably inserted it into the cacerts file in /ColdFusion9/runtime/jre/lib/security using the command
\ColdFusion9\runtime\jre\bin\keytool -import -v -alias someServer-cert -file someServerCertFile.crt -keystore cacerts -storepass changeit
(if you haven't done this, do it now).
The thing I was running into was that I am setting up ssl on my localhost so after doing these steps I was still getting the same error.
As it turns out, you need to also insert your "server.crt" into the "trustStore" file commonly located in /ColdFusion9/runtime/jre/lib using the command
\ColdFusion9\runtime\jre\bin\keytool -import -v -alias someServer-cert -file someServerCertFile.cer -keystore trustStore -storepass changeit
Hopefully this will save someone time.
I am using JRun. After trying a lot of different things I came across a snippet of information that was applicable in my setup. I had configured an (1)HTTPS SSLService with my own truststore file. This caused the piece of information in the following link to become important.
http://helpx.adobe.com/coldfusion/kb/import-certificates-certificate-stores-coldfusion.html
Note: If you are using JRun as the underlying J2EE server (either the
Server Configuration or the Multiserver/J2EE with JRun Configuration)
and have enabled SSL for the internal JRun Web server (JWS), you will
need to import the certificate to the truststore defined in the
jrun.xml file for the Secure JWS rather than the JRE key store. By
default, the file is called "trustStore" and is typically located
under jrun_root/lib for the Multiserver/J2EE with JRun configuration
or cf_root/runtime/lib for the ColdFusion Server configuration. You
use the same Java keytool to manage the trustStore.
Here is the excerpt from my jrun.xml file:
<service class="jrun.servlet.http.SSLService" name="SSLService">
<attribute name="port">8301</attribute>
<attribute name="keyStore">/app/jrun4/cert/cfusion.jks</attribute>
<attribute name="trustStore">/app/jrun4/cert/truststore.jks</attribute>
<attribute name="name">SSLService</attribute>
<attribute name="bindAddress">*</attribute>
<attribute name="socketFactoryName">jrun.servlet.http.JRunSSLServerSocketFactory</attribute>
<attribute name="interface">*</attribute>
<attribute name="keyStorePassword">cfadmin</attribute>
<attribute name="deactivated">false</attribute>
</service>
Once I imported the certificate into this truststore (/app/jrun4/cert/truststore.jks) it worked after restarting ColdFusion.
(1) http://helpx.adobe.com/legacy/kb/ssl-jrun-web-server-connector.html
Adding the cert to the keystore did not work for me on CF9 Enterprise.
Ended up using the CFX tag, CFX_HTTP5.
I realize this is a very old discussion, but since it still comes up near the top of a search for the "peer not authenticated" error in CF, I wanted to share that for most people, the simple solution is to update the JVM that CF uses. (More in a moment on how to do that.)
The cause of the problem is generally that the service BEING CALLED has made a change that requires a later version of TLS or SSL (and perhaps a change to supported algorithms). Later JVMs offer that, while earlier ones did not. Since CF runs atop the JVM, it's the calls out of CF (va cfhttp, cfldap, cfmail, etc) that "suddenly" start to fail.
And sure, sometimes a cert update is the answer (and even then, you have to do it carefully), but it's not always needed. And updating the JVM also gives other benefits, in terms of bug fixes, etc.
The only challenge is knowing what JVM your version of CF will support. (But even people still running on an old CF version have found that updating the JVM CF uses has solved this problem and not caused any others.)
I discuss all this in a 2019 post:
https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/
Hope that may help someone.