I am trying to set up MTLS on a Jetty Server. From the documentation I have seen typically the server certificate is set up such as this
SslContextFactory.Server sslContextFactory = new SslContextFactory.Server();
sslContextFactory.setKeyStorePath("/Users/name/Downloads/server.jks");
sslContextFactory.setKeyStorePassword("changeit");
sslContextFactory.setTrustStorePath("/Users/name/Downloads/server_truststore.jks");
sslContextFactory.setTrustStorePassword("changeit");
sslContextFactory.setNeedClientAuth(true);
However, I want to have different server certificates to validate against depending on which device sent the client certificate? What settings do i need to change, or classes can I override to dynamically validate certificates?
You'll have to download it and then configure your SslContextFactory.Server to use the local copy.
This is a Java SSL engine limitation.
Use the prior answer on how to download a file from Amazon S3 ...
https://stackoverflow.com/a/28569038/775715
For mTLS, just set the SslContextFactory.Server features you want to use for your set of features.
SslContextFactory.Server.setNeedClientAuth(boolean)
This is the javax.net.ssl.SSLParameters.setNeedClientAuth(boolean) feature in the Java JVM.
SslContextFactory.Server.setWantClientAuth(boolean)
This is the javax.net.ssl.SSLParameters.setWantClientAuth(boolean) feature in the Java JVM.
The behavior is standard Java JVM behavior, Jetty does very little here (Jetty only configures the JVM SSLEngine and SSLParameters objects, and handles host/alias matching if using SNI), all of the mTLS behaviors are baked into the JVM.
Everything from this point forward is standard Java behaviors of Client Auth, and Server Keystore/Truststore, there is nothing unique or special about Jetty. It's all a matter of configuring your Keystore/Truststore and issuing valid client certificates from those stores.
If you want multiple server certificates, go for, that's supported by the keystore / truststore.
If you want the client to validate against different server certificates, then the client needs to use the appropriate combination of server hostname and SNI information (this is an extremely common TLS extension).
Related
I've a server which authenticates clients applications and allows them to execute or not. I want to have a secure channel between server and clients. I've written my server with both ssl and ssh protocols but I don't know which one must be used in these scenario and which one is more logical.
both client and server has been written in Qt,c++.
ssl is mostly used in https and web based application and ssh is used for remote administration, so I think that ssh is more appropriate for my server. also I think it's not a good design if I release my application with certificates(exe file along with a certificate.)
Both ssl and ssh use the same, fundamental, cryptographic technologies. Looks like you understand the practical differences between the two, so use whichever one is convenient for your application. As long as you follow proper security practices (keeping your certificates and/or private keys under a watchful eye, etc etc etc), either one will give you the same, basic, level of security.
I have a SOAP webserver developed in Delphi XE2 that exposes some methods and it uses SSL. I built my client also in Delphi XE2, and I use THTTPRIO to connect to webserver. My question is related to the use of SSL certificatest with THTTPRIO. If I call my webservice it works without having a certificate installed, but I think that it shouldn't.
Second scenario :I have a self signed certificate which I installed it and after I made a call to my webservice it works also.
When I inspected my events: HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest and SOAPResponse to string from TStream and seems that it isn't encrypted in both cases. I also found on another forum the same question but with no response.
I searched for info about SOAP SSL Clients with Delphi but couldn't find any new info. Could any of you guys give me some advices regarding this issue?
If I call my webservice it works without having a certificate
installed, but I think that it shouldn't.
Not many web services require client certificates (with exceptions like banking and other high risk environments). It is more common that clients want to verify the server identity, and this is done with server certificates.
So I would say this web service does work in a normal, expected way.
HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest
and SOAPResponse to string from TStream and seems that it isn't
encrypted in both cases
This is correct, the message payload will appear unencrypted because SSL / TLS does encryption on the transport layer. Your application will not see the encrypted data, which actually makes things easier.
You can add encryption for the message payload, there are generic libraries for this (however I have no experience with using encryption HTTPRio).
Im working on some JSON-based web service that is supposed to work with Android application.
I would like to encrypt data transport between client (android) and server (virtual server in datacenter).
I don't have to make sure that my server is my server, just data encryption.
I have no idea how to use HTTPS.
Do I just put my PHP files in private_html and use https://example.com url?
To use HTTPS, you don't have to do anything in the coding of your web service - it's all in your hosting. Here the are steps you can follow. The specific instructions differ in your hosting (IIS, Apache, AWS/Azure, etc), but you can google specifics on how to accomplish any of these steps for whatever host and application framework you decide.
Buy an SSL certificate (there are many different vendors, but expect between $75-$200 for the certificate) based on the vendor, reputation, and level of security you need.
Generate a certificate signing request (CSR) from the server you'll be hosting.
Upload the CSR to the SSL vendor who will validate and provide the certificate for your use.
Import the SSL certificate into your application server, and configure the site to use the certificate. For instance, if you're hosting Microsoft IIS, you'd import the SSL certificate and then add HTTPS bindings on 443 to the specific website hosting your web service.
Another point of security. Since you are deploying SSL, you don't have to do any application level encryption (assuming you are not putting sensitive information in query strings - use POST if you think you need to). You probably would want to implement some security to restrict access to your web service so only your app can access it. Best practice is some level of OAuth, but at a minimum some type of pre-shared key in the header of the request is a lot better than nothing.
Here are some additional sites for more information:
https://www.digicert.com/ssl-certificate-installation.htm
https://support.godaddy.com/help/category/742/ssl-certificates-installing-ssl-certificates?prog_id=GoDaddy
If you don't want to pay for a certificate, you can use certificate signet by your own CA and add the root certificates into your application using HTTPClient and keystores
Here there's some guides
http://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
http://developer.android.com/reference/org/apache/http/client/HttpClient.html
KeyStore, HttpClient, and HTTPS: Can someone explain this code to me?
http://blog.antoine.li/2010/10/22/android-trusting-ssl-certificates/
You can limit users to use JUST and only HTTPS in apache, IIS or whatever do you use. If your client connects to your server, his communications will be likely to encrypted, because he is already using HTTPS. And for responsing in HTTPS you virtually cannot send HTTPS responses, as far as I know, unless that other side isn't also a website (for example, if you have your website, you could send such a response e.g. to Google). You should be okay to send data like http status codes (OK, NotModified, PageNotFound, ...), or if you want something more, or if it is a requirement, then there you still have JSON and you could encode it as well, with some encoding algorithms, or use binary JSON format.
Check if your hosting company provides a free public shared https address. Most of them do.
If you want to understand how to do it right, follow this thread
Warning: Don't stick with the solution below for production.
If you plan o use an https endpoint without a certificate you have to make sure to disable peer verification, check this answer
I have two computer systems each having an apache server. One machine is a client machine and the other is a server machine. I want both the client request and the server response to be encrypted thus making the data transfer safe.
Could someone please give pointers/steps on how I could make progress in this front.
The communication doesn't involve any GUI components meaning the communication is purely a backend one.
Both the client and the server are coded in java. I am using Axis2 and jaxws for the communication.
Currently I am able to send the client request and receive the server response without SSL enabled. Now If I enable SSL does it mean that I should also modify the existing code according to the SSL or the current working code still holds good.
You have many options here. Since you mention SSL...
On each server generate an asymmetric key-pair (RSA 2048 is a safe choice). Then create a self signed certificate on each server. Then copy each certificate to the other machine and mark it as trusted by the Java environment that apache is using and that NONE OTHER are trusted. Configure SSL/TLS on each of the apaches to use a good symmetric cypher (3DES is a safe choice, but there are other newer ciphers if you want leading edge). Next ensure that all access between Tomcat servers is via https URLs and you should be in decent shape.
An alternative is to use IPSEC to establish a static tunnel between the two servers using certificates or other trust bases.
One fairly simple option is to use stunnel, which is available via the standard package-manager on most *NIX systems. You configure an stunnel as a client (and server if you with) on one server and then another as the server (and client if you wish) and then configure your Tomcat instance(s) to connect to localhost:XYZ where XYZ is the port where stunnel is listening.
The nice part about using stunnel is that you can use it to tunnel any protocol: it is neither a Tomcat-specific nor a Java-specific technique, so you can use it for other applications in the same environment if you want.
What advantages are there between implementing SOAP messages over SSL by modifying the web.xml/ejb-jar.xml VS modifying the WSDL with a WS-Policy?
Our project can acheive its goal of having our clients (ourselves) access the Web Service over a secured connection by adding a transport-guarantee but we're not sure if that is a complete/correct solution.
With SSL, you get a point-to-point encryption between client and service. If the service is not the ultimate receipient of the message, but a proxy that routes this message to another service, you have no encryption between the two services, or you have to configure that also.
WS-Security configured via WS-Policy has the potential to give you end-to-end encryption between the client and the ultimate receipient of the message, because you can encrypt the message body. You do not need to configure SSL for every pair of communicating entities. Every proxy can just route the message on, as defined in the header.
That said, if you do not need end-to-end guarantees, but point-to-point is enough (which is your scenario, as far as I understand), I would say that using SSL is a fair choice.
Another thing to consider is that the WS-Security implementations of client and service need to be able to interoperate. SSL generally is quite mature, but my personal experience is that WS-Security implementations are not. So, if you have different WS-* Stacks for client and server, it might be some hacking and trial-and-error to find a policy configuration that works for both.