I'm trying to setup SSL in my local Tomcat 6 installation. For this, I followed the official How-To doing the following:
$JAVA_HOME/bin/keytool -genkey -v -keyalg RSA -alias
tomcat -keypass changeit -storepass changeit
$JAVA_HOME/bin/keytool -export -alias tomcat -storepass
changeit -file /root/server.crt
Then changing the $CATALINA_BASE/conf/server.xml, in-commenting this:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/root/.keystore" keystorePass="changeit" />
After starting Tomcat, I get this Exception:
INFO: Initializing Coyote HTTP/1.1 on http-8080
30.06.2011 10:15:24 org.apache.tomcat.util.net.jsse.JSSESocketFactory getStore
SCHWERWIEGEND: Failed to load keystore type JKS with path /root/.keystore
due to Invalid keystore format
java.io.IOException: Invalid keystore format
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:633)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1185)
When I look into the keystore with keytool -list I get
root#host:~# $JAVA_HOME/bin/keytool -list
Enter key store password: changeit
Key store type: gkr
Key store provider: GNU-CRYPTO
Key store contains 1 entry(ies)
Alias name: tomcat
Creation timestamp: Donnerstag, 30. Juni 2011 - 10:13:40 MESZ
Entry type: key-entry
Certificate fingerprint (MD5): 6A:B9:...C:89:1C
Obviously, the keystore types are different. How can I change the type and will this fix my problem? Thank you!
It looks like the keytool you're using the GNU implementation, not the one from Oracle/Sun or OpenJDK. From the output of keytool -list, it generates a gkr store type, which is a GNU Keyring Store.
I'm not sure whether your run Apache Tomcat using an OpenJDK or Sun/Oracle JRE, in which case this format wouldn't be supported without additional security providers.
If you run Apache Tomcat with a GNU JRE that supports gkr (or at least a JRE where you've added a security provider that supports gkr), you can try keystoreType="gkr" in your <Connector /> configuration.
However, the easiest is probably to use keytool as provided by Oracle or OpenJDK and use the JKS storetype (which would be the default type if you run Apache Tomcat with the OpenJDK or Sun/Oracle JRE). It was probably installed with your JRE but it doesn't look like the $JAVA_HOME you're using point to an Oracle or OpenJDK JAVA_HOME. Some Linux distributions have mechanisms to install multiple JREs and configure links (update-alternatives in the Debian/Ubuntu family).
(As a side-note, it's usually not recommended to run Apache Tomcat as root, which you seem to be doing since $HOME/.keystore is /root/.keystore in your example.)
As Bruno said, I used the "wrong" keytool!
There are those keytools on my Debian 6 installation
root#host:~# locate keytool
/etc/alternatives/keytool
/etc/alternatives/keytool.1.gz
/root/glassfish3/jdk/bin/keytool
/root/glassfish3/jdk/jre/bin/keytool
/root/glassfish3/jdk/man/ja_JP.eucJP/man1/keytool.1
/root/glassfish3/jdk/man/man1/keytool.1
/root/glassfish3/mq/bin/imqkeytool
/root/glassfish3/mq/bin/imqkeytool.exe
/usr/bin/gkeytool
/usr/bin/gkeytool-4.4
/usr/bin/keytool
/usr/bin/jre1.6.0_25/bin/keytool
/usr/bin/jre1.6.0_25/man/ja_JP.eucJP/man1/keytool.1
/usr/bin/jre1.6.0_25/man/man1/keytool.1
/usr/lib/jvm/java-1.5.0-gcj-4.4/bin/keytool
/usr/lib/jvm/java-1.5.0-gcj-4.4/jre/bin/keytool
/usr/lib/jvm/java-1.5.0-gcj-4.4/man/man1/keytool.1.gz
/usr/lib/jvm/java-6-sun-1.6.0.24/bin/keytool
/usr/lib/jvm/java-6-sun-1.6.0.24/jre/bin/keytool
/usr/lib/jvm/java-6-sun-1.6.0.24/jre/man/ja/man1/keytool.1.gz
/usr/lib/jvm/java-6-sun-1.6.0.24/jre/man/man1/keytool.1.gz
/usr/lib/jvm/java-6-sun-1.6.0.24/man/ja/man1/keytool.1.gz
/usr/lib/jvm/java-6-sun-1.6.0.24/man/man1/keytool.1.gz
/usr/share/man/man1/gkeytool-4.4.1.gz
/usr/share/man/man1/gkeytool.1.gz
/usr/share/man/man1/keytool.1.gz
/var/lib/dpkg/alternatives/keytool
root#host:~# echo $JAVA_HOME
/usr
Now I used
/usr/lib/jvm/java-6-sun-1.6.0.24/bin/keytool -genkey -v -keyalg RSA -alias tomcat
-keypass changeit -storepass changeit
To create the keystore- file. Tomcat starts without any problems!
Try specifying your storetype: -storetype JKS (see: http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html)
If you use the GNU jvm and keytool, you can add the following options to the Tomcat connector in server.xml in order get it to work: keystoreType="gkr" algorithm="JessieX509"
The algorithm is mentioned at here
Related
I've trying to setup a cluster by https://docs.confluent.io/platform/current/security/security_tutorial.html with SSL keys and username/password like it is described.
But failed to find a proper way to set up a dname of a key and broker's parameter "super.users"
Its told to create a key with:
# Without user prompts, pass command line arguments keytool -keystore kafka.server.keystore.jks -alias localhost -keyalg RSA -validity {validity} -genkey -storepass {keystore-pass} -keypass {key-pass}
-dname {distinguished-name} -ext SAN=DNS:{hostname}
And later on with configuring broker's server.properties we need to setup a super.users:
Because this tutorial configures the inter-broker security protocol as
SSL, set the super user name to be the distinguished name configured
in the broker’s certificate. (See other authorization configuration
options).
super.users=User:;User:;User:;User:kafka-broker-metric-reporter
The problem is dname must follow a pattern: "CN=cName, OU=orgUnit, O=org, L=city, S=state, C=countryCode"
Moreover, there is a restriction on CN for kafka: it must be equal SAN FQDN setting.
So, a question is:
in case we have a localhost and setting up cluster with single broker, should we set dname for key like "CN=localhost" and the command will be:
keytool -keystore kafka.server.keystore.jks -alias localhost -genkey
-dname "CN=localhost" -ext SAN=DNS:localhost
and then have in server.properties entry:
super.users=User:CN=localhost
?
And if it true, the second question:
In case we still have a localhost and setting up a 2 separate brokers there. So, we will have a same dname?
Actually that's was correct to add users in config with their dname:
super.users=User:CN=localhost
It was not so obvious, but it's works.
Recently We have enabled SSL on AEM and after that we are facing issue to connect with third party services.
For some services we are getting
javax.net.ssl.SSLException: java.security.ProviderException: Could not derive key
Any pointers on how to resolve this issue?
Thanks,
Nidhi
I had this issue a while ago. The cert file was not installed to the java keystore in my case.
Ensure the cert file is installed to the java keystore. This command will list the installed certs, check if your cert is in there, you can search by the alias that was used to install the cert.
keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts
This will help you import to keystore if cert is not installed
keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias"
You can also search by the alias that was used to install the cert
keytool -list -v -keystore keystore.jks -alias youralias
If you have multiple versions of java installed, ensure java_home points to the location of java where the cert is installed. Also check if PATH contains the same path.
I have problem configuring SSL on tomcat 7 (7.0.10) here I am using Thawte SGC Certificate , please read below description carefully help me out .
I have followed below step
1)Generated key using below command
keytool -genkey -keysize 2048 -alias test_self_certificate -keyalg RSA -keystore test_self_certificate.jks -validity 730
this command generated “test_self_certificate.jks” file in current folder
2)This generated CSR using below command
keytool -certreq -alias test_self_certificate -file my_application.csr -keystore test_self_certificate.jks
this command generated “my_application.csr” file in current folder
3)Then I have submitted this CSR to Thawte and got certificate from them in PKCS#7 format , I have copied that certificate text in notepad and saved that file as “signed_certificate.p7b”
4)Then i created New JKS keystore and imported certificate received from Thawte using below command
keytool -import -alias signed_cert -trustcacerts -file signed_certificate.p7b -keystore tomcat_application.jks
this command generated “tomcat_application.jks” file in current folder
5)I have update tomcat server.xml as below ( I have provided correct .jks file path and keystore password )
<Connector port="8001" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="/export/home/parsupport/Tomcat_certs/ tomcat_application.jks " keystorePass="parlive" clientAuth="false" sslProtocol="TLS" />
6)After this change when I start Tomcat I get below Exception and tomcat does not start with SSL
Caused by: javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:310)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:255)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.checkConfig(JSSESocketFactory.java:774)
Important Note : but if I import certificate received from Thawte in keystore (test_self_certificate.jks -- mentioned as first step above) that I have created to generate KeyPair and CSR , and use that keystore to configure tomcat (as described in step 6 as above ) then Tomcat start in SSL mode but when in try to launch HTTPS URL I get untrusted certificate warning .
keytool -genkey -keysize 2048 -alias test_self_certificate [...]
Here, -genkey generates a public/private key pair and stores in into the "test_self_certificate" alias entry, thereby making this a private key entry. (If you use keytool -list, you'll see some private key entries and some certificate entries). -genkey also generates a self-signed certificate to associate with this private key automatically (this is also how the public key is effectively stored by default).
keytool -import -alias signed_cert [...]
If you get a certificate issued for a private key that is stored in a keystore, you need to store this certificate against the right private key entry, not just any entry. Here, you should have used -alias test_self_certificate instead (which may also mean that it wasn't the best choice of alias name, but that's just a detail).
(In some cases, you may also need to make sure you import the full chain.)
I'm having trouble getting ColdFusion to connect to a secure FTP server that uses a self-signed certificate. The connection just times out. I've tested the setup in an FTP client and it works, but you must accept an 'unknown certificate.'
The code, though it's not very helpful:
<cfftp
connection="ftp"
action="open"
server="server"
username="username"
password="password"
port="23456"
passive="true"
secure="true"
/>
Here's the error I get from ColdFusion:
Verify your connection attributes: username, password, server, fingerprint, port, key, connection, proxyServer, and secure (as applicable). Error: Session.connect: java.net.SocketTimeoutException: Read timed out.
Does anyone know if it's possible to accept the certificate? Or if that's even the problem?
I am not sure about cfftp but for cfhttp requests to sites with a self-signed certificate you have to import their certificate into the Java keystore on your ColdFusion server. So you might want to give that a try.
I always export the certificate in DER format
The command to import should be something like this:
keytool -import -v -alias giveUniqueName -file filename.cer -keystore cacerts -storepass thePassword
Here is the command line to verify an imported certificate:
keytool -list -v -keystore cacerts -alias giveUniqueName -storepass thePassword
I did not include the password here but am pretty sure you can Google it. If not, send me a message and I can give it to you.
Also, you may need to supply pathing information depending on where you run the keytool commands from and where your certificate file resides.
Another note, be sure you are updating the correct cacerts file that ColdFusion is using. In case you have more than one JRE installed on that server. You can verify the JRE ColdFusion is using from the administrator under the 'System Information'. Look for the Java Home line.
Oh - and you have to restart ColdFusion after making the import.
UPDATE FOR CF10
I found a forum discussion (here) talking about installing certificates on CF10. The keytool commands appear to be slightly different in their example. In case it is a bit different than CF9, here is what they said:
keytool -importcert -alias giveUniqueName -trustcacerts -file filename.cer -keystore cacerts -storepass thePassword
Trust this certificate? [no]: y
It looks like the verification command line has not changed.
I have just installed a new ssl certificate on GlassFish 3. I also changed all references to s1as to a new certificate alias in config/domain.xml. Everything seems to work fine, but I wonder if I have to change all "s1as" entries in
config/sun-acc.xml, wss-server-config-1.0.xml,wss-server-config-2.0.xml as well ? Do settings in these files affect anything ?
Thanks in advance.
Why you did not use
keytool -delete -alias s1as -keystore
and
keytool <opts> -keystore keystore.jks -validity <val_days> -alias s1as
instead?
sun-acc xml comes in to play while accessing EJB objects that are residing in a remote system
Bottomline is:
You would require to edit sun-acc.xml and other configs that refer to si1as