I am trying to get SSL working on a Wildfly 9.0.1 standalone server, but am unsure what certificates if any should be in the keystore created. I have ran the following command from the Wildfly 9 admin guide:
keytool -genkey -alias server -keyalg RSA -keystore server.keystore -validity 365
However, this server exists behind a corporate proxy for which many client applications require us to set certifications. I've done this in the past by saving them with Certificate Export Wizard through Google Chrome, then importing them using keytool.
The Certification path contains a root cert, a sub cert below root, another sub cert for the local URL used by some of our applications, and finally a cert for the URL of the site being accessed.
So, my questions are thus: Which if any of the above certs are necessary for SSL/HTTPS on Wildfly? Do they belong in the same "server.keystore" created by that command, or should the exist separately? And would additional information beyond the certs and the steps outlined in the Admin Guide be necessary to enable SSL/HTTPS on Wildfly 9 when operating within a proxy?
Related
Can GraphDB Free be configured in any way to allow content to be served over HTTPS?
I'm creating a simple front-end web application using Angular2 that makes HTTP requests to the GraphDB SPARQL endpoint.
I'm using Windows IIS and the server has been setup not to trust any content this is not served over HTTPS.
Any insights would be helpful.
According the instructions in GraphDB's configuration file $GDB_HOME/conf/graphdb.properties, to enable HTTPS uncomment the following lines:
# Enable SSL (uncomment to enable)
graphdb.connector.SSLEnabled = true
graphdb.connector.scheme = https
graphdb.connector.secure = true
# GraphDB uses the Java implementation of SSL, which requires a configured key in the Java keystore.
# To setup keystore uncomment the following properties and set keystorePass and keyPass to the actual values.
graphdb.connector.keyFile = <path to the keystore file if different from ${graphdb.home}/keystore>
graphdb.connector.keystorePass = <secret>
graphdb.connector.keyAlias = graphdb
graphdb.connector.keyPass = <secret>
If you use a self-signed certificate add it to the keystore with:
keytool -genkey -alias graphdb -keyalg RSA
If you have a third-party trusted OpenSSL certificate, you would need to convert it to PKCS12 key and then import to the Java keystore with:
keytool -importkeystore -deststorepass MYPASS -srckeystore mypkcs12.p12 -srcstoretype PKCS12
For additional information on how to deal with the third party trusted certificates check this excellent link explaining in great details how to convert import private key and certificate into java keystore
Edited
To locate the $GDB_HOME directory for the desktop installation, check the GraphDB documentation.
I have a xmpp server (openfire 3.9.3) and trying to secure my non-ssl connection to ssl connection.
that's why i have created a self-signed certificate using java keytool as
keytool -genkey -keystore keystore -alias example.com
and i filled the several pieces of information required for the certificate.
the certificate successfully created. and i configured my server to access the keystore file but when restart my xmpp server it says
Unable to access certificate store. The keystore may be corrupt
what should i do for fixing the same issue ?
thanks in advanced
You can :
Delete certs in AdminWEB interface.
Restart openfire
Delete /opt/openfire/resources/security/keystore file
Generate new cert from web interface.
References : http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ssl-guide.html
Hope this help...:)
I am consuming third party web service in my application. It has https url which requires handshake. I am using Weblogic application Server and I want to configure the certificate in my server.
Can anyone please provide me steps to configure that certificate?
Also What is Identity and Trust on Weblogic Console?
Please help!!
Update the cacerts file for the JVM used by WebLogic. Using the WebLogic console, select the server. Then use the Configuration > Keystores tab to find the cacerts file location labeled Java Standard Trust Keystore on this page.
You will want to import the certificate from the web service into this cacerts file. If you are a Windows user, I use a free tool called Keystore Explorer (http://keystore-explorer.sourceforge.net/). This application allows to directly import the certificate using the URL. Do this by opening your cacerts file in KeyStore Explorer then use the Examine SSL option to import the certificate.
I resolved this by using keytool command provided in Jdk bin folder.
I just went to demotrust.jks and imported the third party certificate in it and it worked for me.
I used below command.
${ORACLE_HOME}/product/jrockit-jdk1.6.0_20-R28.1.0-4.0.1/bin/keytool -import -alias [AliasForYourCertificate] -keystore ${ORACLE_HOME}/Middleware/wlserver_10.3/server/lib/DemoTrust.jks -file /home/oracle/[YourCertFile].crt
I have currently deployed a war file in my Jetty 8.x webapps container. I can start the Jetty server and connect to my server using HTTP. I want to be able to connect using HTTPS. What is the easiest way to enable HTTPS on Jetty 8.x? I am willing to use a self-signed certificate if necesssary.
I need the following:
steps to generate and import cert into Jetty (preferably using a self-signed cert)
configuration required in Jetty to support HTTPS / SSL
command line parameters to start Jetty with SSL enabled
Secondly, is anyone aware of how to turn Jetty 8.x so that it can be run as a Windows service?
For more details, I am running into problems enabling SSL on Jetty. I am trying to use a self signed cert for this purpose. I'm using keytool to create a keypair and self signed cert as follows:
keytool -genkey -alias domain -keyalg RSA -keysize 2048 -validity 365 -keystore keystore
I then copy the keystore to my c:\jetty\etc directory. I edit the file 'jetty-ssl.xml' to make sure that the HTTPS port is set to 8443. When I restart the Jetty server, it seems to be listening on port 8443 and the startup sequence doesn't return any errors. However, when I try to connect using HTTPS, I get errors. Is there a prescribed method for generating a self signed cert and using this cert in the SSL configuration with Jetty?
1) http://wiki.eclipse.org/Jetty/Howto/Configure_SSL
2) http://git.codehaus.org/gitweb.cgi?p=jetty-project.git;a=tree;f=jetty-win32;h=e296255dc355f3abf37bf3f4faddfe383505416c;hb=HEAD
You'll need to adapt that for you particular usage, we stopped building it with release quite a while back because its license changed and the version we were using was getting crufty. Alternately take a look at the updated version of the tanuki stuff and if you can handle the license use that.
I have three files from Entrust: *.csr, *.key and *.crt.
So far:
I have brought the *.key and *.crt into a PKCS12 keystore using OpenSSL
I have imported the *.pkcs12 into a keystore using keytool
Using this technique, I am able to use an SSL connection with Jetty
However, I'm getting a Certificate Error in IE (unsecured items in Chrome).
In our case, the certificates are currently being used for domain:80 (Apache) and I'm attempting to "reuse" them for domain:8443 (Jetty).
Am I wrong in thinking that I can use these for Jetty as well? On the same IP/domain, but on a different port and webserver? My gut is telling me that one of these files relates to Entrust recognizing Apache (*.csr) and that I should have to do the same for Jetty?
Edit #1
The error goes as follow:
Certificate Error
Untrusted Certificate
The security certificate presented by this webiste was not issued by a trusted certificate authority
This problem may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage.
But yet Chrome, sees it as valid. I does have to work on IE since it's our standard.
Edit #2
Chrome doesn't complain
Nor does Firefox
Edit #3
I found our CA certificate specified in the Apache conf file. I then proceeded to concatenate our cert with the CA cert into a PKCS12 file. Then, using keytool, I generated the keystore.
I loaded it on the server, rebooted and viewed in IE. IE still shows a certificate issue.
In the concatenated file, I see in this order: our cert and then 2 other certificates.
On a side note, I called Entrust and the CSR saw no problems as he was using IE 8. We're on IE7.
Edit #4
Using this command:
keytool -list -keystore keystore -v
It shows 3 certificates (in this order):
Ours
Owner: CN=Entrust Certification Authority - L1C,
Owner: CN=Entrust.net Certification Authority (2048)
Edit 5
Solved! I guess I had a caching issue. Confirmed with colleagues.
Answer, Concatenating all my certs, including the CA cert, into the keystore solved my issue.
The port number, as stated in the comments, is irrelevant for trusting an SSL/TLS connection.
The problem is that the entire certificate chain from your certificate up to the Entrust root probably looks like this
your cert - intermediate CA 1 - intermediate CA 2 - ... - root CA
To make this work for IE you have to import not only your certificate into the PKCS#12 container, but additionally the intermediate certificates and also the root certificate. Otherwise your SSL implementation won't be able to provide the full path during the SSL handshake and thus IE has no means to build a proper chain to compare to its set of trusted root certificates.
So my advise would be to get the intermediate certificates from the appropriate web sites and importing them with keytool into your PKCS#12 key store.
Once done, IE should from then on accept without complaining.