I have already developed a grizzly-based-HTTP-Server. In order to test my Server I also developed a grizzly-based-Client, which can comunicate with my Server using http-Messages. I instantiate my http-Server using grizzly as following:
HttpServer server = HttpServer.createSimpleServer();
server.addListener(new NetworkListener("server","127.0.01",8081);
server.getServerConfiguration().addHttpHandler(new Handler());
try {
server.start();
Thread.currentThread().join();
} catch (IOException e) {
e.printStackTrace();
}catch (InterruptedException e) {
e.printStackTrace();
}
Now I want to secure the communication between them. When I am searching for Informations about possible implementation of ssl in grizzly, I found this link SSL with Grizzly and Jersey. I noticed that I should use SSLContextConfigurator combined with Jersey. This means for me that I must modify my grizzly based Server, which is totally based on grizzly. Before doing this step, I must be sure that I can implement my AES-preshared-key using Jersey Combined with grizzly. Till now I found no example that Shows how to use AES-preshared-key in Java.
According to my readings about preshared-key-method, I knew that I should use javax.crypto.Cipher. Now I am confused about adding this functinality(ssl with preshared key) to my Server. Any idea?
Have you checked SSLEngineConfigurator docs? You can add TLS v1.2 ciphers from this page to enabledCipherSuites in your ssl configuration. That page also gives you the list including compatibility with different JDK versions.
This should give you an idea how to proceed with SSL using Grizzly.
Related
I have multiple microservices that get its initial configurations off a config-server, and the API requests should pass through an api-gateway first. I've managed to enable HTTPS on each microservice with server.ssl.* along with a self-signed keystore generated using keytool. Accessing each microservice directly through https is no problem but I ran into a lot of errors when I try to go through the api-gateway first. All the errors were either unable to find valid certification path to requested target, not an SSL/TLS record or trustanchors parameter must be non-empty even if I add the various server.ssl.trust-store properties.
I've bypassed it for now by adding the following lines to the main class of my api-gateway:
ClassPathResource resource = new ClassPathResource("SSL.jks");
try {
System.setProperty("javax.net.ssl.trustStore", Paths.get(resource.getURI()).toString());
} catch (IOException e) {
e.printStackTrace();
}
System.setProperty("javax.net.ssl.trustStoreType", "jks");
System.setProperty("javax.net.ssl.trustStorePassword","password");
I would like to know if there is a better way to do this instead of "hard-coding" it like this. I also haven't added HTTPS to the config-server but I assume I will end up having to do this. I'm also not understanding how I can "auto-import" the certificates (if that's how I have to do it) for it to work in production? Importing the self-signed certs to my java only makes sense for my local machine.
I've set up a websocket connection using Java-WebSocket with a working two-way TLS connection. However, to make Client Authentication possible I'd like to be able to get the information attached to the Client Certificate. This will contain some information about the client connecting so it would be useful to have.
I've looked through all the data in debug mode for the connection and the data it contains, but cannot find any reference to the certificate. Most questions online seem to be about the standard javax websocket, but the one I'm using is made by TooTallNate (https://github.com/TooTallNate/Java-WebSocket)
I would like to be able to get a certificate from an established session. Is this possible?
Apparently in the new version the possibility of getting the SSLEngine from a session has been made possible. This should be present starting from version 1.4.1, which is currently a SNAPSHOT.
For anyone else stumbling across this question, this is a solution that works as of the 1.4.1-SNAPSHOT build used. This code should function in any of the server events. In my case I placed this in the onOpen event, which I'm guessing is where you'd want it to be as well. I haven't fully tested this with a non-SSL server but since there is a check in place it SHOULD be fine. Please test beforehand, however.
Certificate[] certificates = null;
if(webSocket.hasSSLSupport()) {
try {
certificates = webSocket.getSSLSession().getPeerCertificates();
} catch (SSLPeerUnverifiedException e) {
logger.error("Could not read SSL Certificates");
e.printStackTrace();
}
}
I'm trying to make a third-party SOAP service call that uses HTTPS from local (development environment) AEM 5.6.1. The SOAP service accepts the requests with a minimum TLS Protocols of TLSv1.1.
I have AEM 5.6.1 that uses JDK7 and for JDK7 the default TLSv1.
To achieve the minimum acceptable TLS. I tried the below two approaches:
Approach 1:
Made AEM start with -Dhttps.protocols=TLSv1.2
Approach 2:
Updated the SSLContext to update TLS.
SSLContext context = null;
try {
context = SSLContext.getInstance("TLSv1.2");
context.init(null, null, new java.security.SecureRandom());
SSLContext.setDefault(context);
LOGGER.info("Currecnt TLS:" + SSLContext.getDefault().getProtocol());
}catch (Exception e){
LOGGER.error("Error while updating TLS:",e);
}
First one doesn't work will, but the other one to update the TLS protocol for AEM to TLSv1.2.
But I'm still unable to access the service. The error remains the same.
Error:
The required TLS connection level has not been met. SSL Protocol level: TLSv1
Reference:
https://stackoverflow.com/a/42291244/4802007
https://stackoverflow.com/a/32346644/4802007
I would like to know 2 things here,
Am'I missing anything that is stopping the proper TLS update.
Is there any way to update the TLS only for this particular service, instead of changing it globally.
Thanks
This is a bug in CQ 5.5/5.6. The core issue boils down to the fact that in older CQ version SSLv3 was not allowed to be disabled by config and therefore TLS parameters never took effect.
You need to contact Daycare support and ask for a hotfix for your version.
Alternatively, check out this HF from your package share account: HOTFIX-5220 as this may have the fix for your TLS issue.
AEM 6.0 released a hotfix for this issue available via package share. Use your login and search for HOTFIX-5238 under 6.0 and ask Daycare for a back port or a compatible package for your version of AEM if the above mentioned hot fix does not work for you.
My project use xfire as a web service client api. My project is in legacy Servlet/JSP. We used XFire eclipse plugin to generate client stub.
Web-service has Migrated to SLL (HTTPS). Is there any easy way to consume Webservice over SSL in XFire.
I found some code at http://docs.codehaus.org/display/XFIRE/HTTP+Transport.
I have some confusion there too. It motivates to use not-so-common-ssl which is in Alpha and I don't know if it is stable enough to be used in production.
// Technique similar to http://juliusdavies.ca/commons- ssl/TrustExample.java.html
HttpSecureProtocol protocolSocketFactory = new HttpSecureProtocol();
// "/thecertificate.cer" can be PEM or DER (raw ASN.1). Can even be several PEM certificates in one file.
TrustMaterial trustMaterial = new TrustMaterial(getClass().getResource("/thecertificate.cer"));
// We can use setTrustMaterial() instead of addTrustMaterial() if we want to remove
// HttpSecureProtocol's default trust of TrustMaterial.CACERTS.
protocolSocketFactory.addTrustMaterial(trustMaterial);
// Maybe we want to turn off CN validation (not recommended!):
protocolSocketFactory.setCheckHostname(false);
Protocol protocol = new Protocol("https", (ProtocolSocketFactory) protocolSocketFactory, 8443);
Protocol.registerProtocol("https", protocol);
Now above is a way to create a Protocol factory and getting it registered with Apache HTTPclient api. But id doesnot say what to do further with the generated stub.
Please feel free to ask more information if any.
We can't move to other web-service client api so that is not an option.
Managed to solve my own problem.
This is how I did it. XFire use Apache Http client internally so setting Security certifect detail on this Api will do the job. We will use no-yet-common-ssl.jar for this purpose.
First we will create org.apache.commons.ssl.TrustMaterial using commons and then set it in HttpSecureProtocol which is a child of javax.net.ssl.SSLSocketFactory.
Suppose XYZ.cer is the client certifect provided by service provider.
HttpSecureProtocol protocolSocketFactory = new HttpSecureProtocol();
protocolSocketFactory.addTrustMaterial(TrustMaterial.DEFAULT); //for trusting all the certifects in java trusted Store.
protocolSocketFactory.addTrustMaterial(new TrustMaterial(getClass().getResource("/XYZ.cer")));
Protocol protocol = new Protocol("https", (ProtocolSocketFactory)protocolSocketFactory, 443);
Protocol.registerProtocol("https", protocol);
If this is a web Application you can do this in ServletContextListener or in any part of code that executes when application boots.
Now you can use any ssl service using Xfire client stub. Any service which implement the above certifect.
Now why this work. Because XFire uses Apache Http Client as a connection api and we are telling Http client to use the above TrustManager when HTTPS is used.
I want to register a ServLet on a specified port, because my port 80 using by another programs that i need them and i can close and kill them.
This is my code for registering servlet :
HttpService httpService = (HttpService) super.addingService(reference);
if (httpService == null)
return null;
try {
System.out.println("Registering servlet at /simple");
httpService.registerServlet("/simple", new SimpleServlet(), null,
null);
} catch (Exception e) {
e.printStackTrace();
}
You can definitely only set the port of the HttpService itself, but it will never try to use port 80 by default. Would it be an idea to configure the server you've got at 80 to proxy certain parts to the OSGi service?
This stuff is a bit trickier than it seems. Getting all the web stuff working (especially more advanced stuff like Filters) isn't that easy.
Pax Web made it much easier. (this bundle contains Jetty and all its dependencies, so you can remove the jetty you are using now)
The port can be configured using OSGi configuration, but by default it is on 8080.
No, this can only be done at container level. Which is your application server? For tomcat, check out the port parameter of the HTTP connector.