When installing Dataminder, two web service ports are set up. One for http and the other for https.
A self-signed certificate is created during installation.
But we need to use a certificate from a certificate authority.
How do you change the certificate used on web service https port?
To replace the default self-signed certificate with certificates from a certificate authority the simplest is to replace
the DMKeyStore file (which is just a standard Java Keystore file) with a new Java Keystore file containing the new certificates.
Note that the new Keystore file must be named and placed at default destination:
DataMinder/Server/Config/Certificates/DMKeyStore
To start using the new certificates file update the DataMinder properties file:
DataMinder/Server/Config/DataMinder.properties
The properties to update are:
dataminder.environment.web.https.keyStorePassword=...
dataminder.environment.web.https.keyAlias=...
dataminder.environment.web.https.keyPassword=....
Update the properties and restart DataMinder. Now DataMinder will use the new certificates.
Note: The certificates are used both for the admin HTTPS and Web Service HTTPS ports.
Related
I am using Spring Security to authenticate using an x.509 certificate, and it works only when the client certificate which is configured in the browser key-store is present in server trust-store.
How it is working currently:
I have configured the SSL client authentication as optional (server.ssl.client-auth=want , like in this post)
I have configured a server trust-store that contains all client certificates. If the certificate presented by the client is in the trust-store, the mutual SSL connection is created.
When I have the client certificate(s) present in the server-side trust-store, Firefox opens a popup with my client-side certificate(s), which I can choose and the mutual SSL connection is established.
I have configured Spring Security to extract the username from the SubjectDN of the client certificate and check it against a UserDetailsService. If a UserDetails object is returned for that username, the authentication process completes successfully
The problem is that if I remove the client-certificate from the server-side trust-store, Firefox doesn't open this popup anymore, and only a one-way SSL connection is made. Even if the Root CA cert is present in the server trust-store.
What I want:
store in the server trust-store only the certificate of a Root Certificate Authority
allow mutual SSL connection when the client presents a certificate issued by the Root CA in the server trust-store (even if the client certificate isn't present in the server trust-store)
I am also intrigued by two resources on the internet. In this tutorial on Baeldung, it says that all client certificates must be stored in the server trust-store for X.509 auth to work (which confirms my experience).
You must remember that for each user that should be verified by the server, its own certificate needs to be installed in the configured truststore. For small applications with only a few clients, this may perhaps be practicable, with an increasing number of clients it may lead to complex key-management for users.
However, this tutorial by #robinhowlett says that
The client will present its certificate in its keystore to the server, and the server will validate the client certificate’s chain using the CA certificate in the server’s truststore.
This is basically what I want to achieve, but am not able to.
Bottom line: did someone manage to store one or more Root CA certificates in the server trust-store and use client certificates issued by these Root CAs to authenticate via X.509 mutual SSL handshake in Spring Security?
I am using Spring Boot 1.5.2.RELEASE (spring-security-web 4.2.2.RELEASE). I have tested my working SSL authentication with Firefox 53.
I found my problem - I was modifying the trust-store (removing the client cert and leaving only the CA cert) while the server was up (Tomcat, in my case). But the trust-store is kept in memory and gets read only once, when the JVM is initialized (details on this ServerFault post). So trust-store changes are not being read during runtime by Tomcat.
So the answer is simple: yes, if only CA certs are present in the trust-store, during the SSL handshake the server communicates to the browser it wants client certificates issued by the trusted CAs and then the browser prompts the user to select a certificate that is issued by a trusted CA (if such a cert is present in the browser keystore).
However, if a CA is added dynamically to the server trust-store while the server is up and running, it won't be detected. The new CA will only be recognized after the server reboots (and the JVM is re-initialized).
I use AdminClient for secure connection to local websphere server:
java.util.Properties props = new java.util.Properties();
props.setProperty(AdminClient.CONNECTOR_TYPE, AdminClient.CONNECTOR_TYPE_SOAP);
props.setProperty(AdminClient.CONNECTOR_HOST, "localhost");
props.setProperty(AdminClient.CONNECTOR_PORT, "8880");
props.setProperty(AdminClient.CONNECTOR_SECURITY_ENABLED, "true");
props.setProperty(AdminClient.USERNAME, "admin");
props.setProperty(AdminClient.PASSWORD, "111111");
props.setProperty("javax.net.ssl.trustStore", "C:/WAS/AppServer/profiles/AppSrv01/etc/DummyClientTrustFile.jks");
props.setProperty("javax.net.ssl.keyStore", "C:/WAS/AppServer/profiles/AppSrv01/etc/DummyClientKeyFile.jks");
props.setProperty("javax.net.ssl.trustStorePassword", "WebAS");
props.setProperty("javax.net.ssl.keyStorePassword", "WebAS");
client = AdminClientFactory.createAdminClient(props);
It's work perfect. But if i try secure connect to remote url (ip or hostname), this code does not work, such SSL exaptions. I think, problem in cert files:
props.setProperty("javax.net.ssl.trustStore", "C:/WAS/AppServer/profiles/AppSrv01/etc/DummyClientTrustFile.jks");
props.setProperty("javax.net.ssl.keyStore", "C:/WAS/AppServer/profiles/AppSrv01/etc/DummyClientKeyFile.jks");
How i can retrive this certificates from remote server using JAVA and make secure connection with AdminClient?
You will need to extract the remote signer certificate and import it into the local WebSphere trust keystore. To do this you can use ikeyman utility to open the remote keystore and export the certificate, and then use the same utility to import the cert into the local Websphere trust store.
The SSL exception should give a clue as to what signer certificate you need to extract from the remote server and import into the local trust store.
Have a look at the http://www-01.ibm.com/software/webservers/httpservers/doc/v1312/ibm/9atikeyu.htm (Exporting Keys and Importing Keys section)
Also, the similar question has already been addressed here:
telling java to accept self-signed ssl certificate
I'd suggest not to put it in your code, but add WebSphere certificate to the Glassfish trusted certs. So you need to perform the following steps:
Extract certificate from WebSphere - the easiest is to access via https using browser any application running on WAS and save certificate to file.
Import that certificate using keytool to the Glassfish trusted store. It should be domains/domain1/config/cacerts.jks (I'm not Glassfish expert, so the path might be different).
Then you should no longer need to set all these javax.net.ssl.* properties.
I built a Web-Service application in Jdeveloper 11.1.1.7 and deployed it on weblogic 10.3.6 with all Key-store and SSL configuration.
SSl Configuration:
Use Server Certs : Checked
Two Way Client Cert Behavior: Client Certs Not Requested. [That is means it is one-way ssl.
Correct me if that wrong]
SSL Listen Port Enabled: Checked
Key-store Configuration:
Custom Identity and Custom Trust. The file path has been specified for those custom key store
A sample client application has been created and everything seems to be fine; I mean the client can not access the server application without specifying the trust store file location where the server certificate is stored and it is trusted at the client end.
By the server certificate I mean the same certificate that has been configured in server Key-store Configuration
for your information the client application referring to trust store as follow:
System.setProperty("javax.net.ssl.trustStore",[Trust-store location goes here]);
System.setProperty("javax.net.ssl.trustStorePassword", [password goes here]);
Till now nothing wrong. Next is the problem details:
For the purpose of testing I tried to access the deployed web-service application using the SoapUI (open source software). What is confusing is the request has been sent, accepted at the server and proceed without specifying any thing for server certificate nor trust store location in SoapUI project configuration !!
Why the SOAP request has been accepted from SoapUI without referring to server certificate? The request should be rejected in this case.
My experience with SoapUI is that it is quite lenient. For example, if it doesn't check if the CN of server certificate matches the fully qualified domain name in the URL. In your case, your server most likely uses a CA signed certificate. Most of the root and intermediate certificates of well known CA's (e.g. VeriSign/Symantec) are already included in the default truststores for most systems. If your server had used a self-signed certificate, then SoapUI would have incurred SSL error unless you import the self-signed certificates into the truststore of the host where SoapUI is running.
I'm trying to configure a Client/Server app after setting up 2-way SSL using the java SSLRMIClientSocketFactory and SSLRMIServerSocketFactory. I know that to set the keystore and truststore on the client I need to set -Djavax.net.ssl.trustStore and -Djavax.net.sslkeyStore.
The way I understand it Java web start downloads the jnlp and verifies the jar and launches the Client java application in a sandbox that then connects to the server application over RMI. The problem is that when the application is run in this sandbox, the default truststore and keystore is not the same as what java web start uses. Instead there is no default keystore and the default truststore is $JAVA_HOME/jre/lib/security/cacerts
Is there a way to use the same truststore and keystore that javaws uses? Ideally I would like to use the same trusted certs and client certs that the browser uses (and by extension javaws). This way If the users configure their certificate through the Java Control Panel, then the application will use the same certificates.
I'm a bit of a newbie when it comes to SSL security on WebSphere.
But basically I am calling a URL from my Java application hosted on WebSphere 6.1. The URL is a web service which is secured via SSL. As an example my URL is:
https://servername:portname/service
I call the web service using cURL using:
--cert test.cer --key
test-privkey.pem --pass "Password"
i.e. I have a .CER file and a .PEM file.
Please could someone advise how I configure WebSphere (through the Admin console) to secure "https://servername:portname/service" using the CER file and PEM file I have.
Thank you.
Whenever using a SSL URL, the JVM tries to recognize the certificate based on its trust store. The truststore file is named 'cacerts' and is present in the java/jre/lib/security folder.For the Webapp to recognize the SSL certificate, the root certificates* of the service must be imported into the cacerts store. This can be done with the help of 'keytool -import' in the java/jre/bin folder.
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tsec_sslexchangesigncerts.html
Whenever using a SSL URL, the JVM tries to recognize the certificate based on its trust store. The truststore file is named 'cacerts' and is present in the java/jre/lib/security folder.For the Webapp to recognize the SSL certificate, the root certificates* of the service must be imported into the cacerts store. This can be done with the help of 'keytool -import' in the java/jre/bin folder.
Root certificate is the Certifying Authority [CA] of a service i.e the Organization that provides the SSL certificate will have a CA cert to identify itself.
Let me know if you need more details.