Develop Reference

GF3 (JDK 6) how to config security protocol to remove obsolete cryptography

In the company that I work we have a server GF 3.1.1 (JDK 6) with CAS which does the authentication of the users in another system. After the last update of Firefox (v. 39x) we are getting the follow information from the browser:
mydomain.com SSL received a weak ephemeral Diffie-Hellman key in
Server Key Exchange handshake message.
And it is not possible to access the site without this workaround or using another browser.
In chrome I can access normally but if I look at the connection properties it says:
Your connection is encrypted with obsolete cryptography.
The connection uses TLS 1.0.
The connection is encrypted using
AES_128_CBC, with SHA1 for message authentication an DHE_RSA as the
key exchange mechanism.
I can't configure all the browsers of our customers or say them only use chrome. Maybe in future chrome can do the same. So my solution is configure the server properly. The problem is that I don't know how can I do that.
I found in GF where I can do the configuration in Configurations > server-config > Network Config > Protocols > http-listner-2 > SSL
Then I found here a blacklist and a whitelist of some ciphers that are recommended to use. I tried to remove all in black and put all those in white. But I still have the issue. I think this list may be out of date.
I appreciate any help.

Finally. I found a solution.
I search a lot and I could find a solution, so I tried to test one by one of the ciphers. So, to work ( I am not saying that is the right way). I had to do this:
At:
Configurations > server-config > Network Config > Protocols > http-listner-2 > SSL
Add all the ciphers available
Remove all the Diffie-Hellman ciphers
Save
After that our application can be opened at any browser again. I hope it may help someone.
For admin:
Configurations > server-config > Service HTTP > Listeners HTTP > admin-listner > SSL
Add all the ciphers available
Remove all the Diffie-Hellman ciphers
Save
Restart
Edit: Comparing with the whitelist here the remaining ciphers that would be part of a new whitelist are:
Whitelist
TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA

I just encountered this problem as well with Chrome and the admin console. The way I got around it was to delete the current ssl certificate for the listener and recreate it using a specific set of ciphers with the --ssl3tlsciphers option. For me it was the admin-listener so first I deleted the current default certificate:
asadmin delete-ssl --type http-listener admin-listener
Then I recreated it using the following command:
asadmin create-ssl --type http-listener --certname s1as --ssl3tlsciphers SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV,SSL_RSA_WITH_NULL_MD5,SSL_RSA_WITH_NULL_SHA,SSL_DH_anon_WITH_RC4_128_MD5,TLS_DH_anon_WITH_AES_128_CBC_SHA,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA admin-listener
I noticed that simply deleting the default certificate doesn't remove all references to it in the domain.xml file. I haven't been able to find the proper way to do this. I just used trial and error. Another method is to modify the domain.xml file where the ssl element for the listener is defined and add the attribute "ssl3-tls-ciphers":
<ssl ssl3-tls-ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV,SSL_RSA_WITH_NULL_MD5,SSL_RSA_WITH_NULL_SHA,SSL_DH_anon_WITH_RC4_128_MD5,TLS_DH_anon_WITH_AES_128_CBC_SHA,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
Both methods require a restart of glassfish.

Thanks, Sertage, that worked!
However, it is also necessary to fix the Protocol for the admin port (usually 4848). (It should, of course, use HTTPS too!)
But, in GF 3.1.2.2, the Protocol 'admin-listener' appears to be kind of pointing to the Protocol 'sec-admin-listener', and that does not have a 'SSL' tab. Changing the SSL parameters the Protocol 'admin-listener' results in an error message, saying 'Could not apply changes. No Configuration found for configs.config.server-config.network-config.protocols.protocol.admin-listener.ssl'. Any suggestions on how to configure the admin port?

Jnlp downloding certificate from server in https protocol

WE are having a webstart application.
Currently it is running fine.
Our jnlp file has unsecure links ie) http://********
When i change this from http to https://********* we are getting ssl handshake error.
How to make this working.
I hope we should install the security certificate in the client machine but our system is vast sowe need to either download the certificate or skip the certifiate checking part while using https.
Currently we are in Java 6. We are going to Migrate our application to Java8
Can someone please suggest some solution.?
Thanks in advance.

Java Security Warning SSL Connection after server change

After a server change, I get nasty SSL warning in browsers (tested FF & Chrome), when loading an applet, used in an JavaEE Application (Serlvet API 3)
The warning says: "Certificate is not valid, and cannot used to identify the website"
The more detailed warning says: "The certificate authority, who provided the certificate, is not trusted." The messages are translated into english, so please excuse slight differences there. After this message, I get the message of Java, which shows that the Applet is ordinary signed (the dialog with the blue sign). So the Applet is working, only the warning message annoys.
Before I moved to another server, everything was fine and worked. No security warnings or anything else. The Applet is signed, by a certificate, which I requested from an CA. (rapidssl)
The old server environment was just a common web space, offered by 3rd party hoster. Now I moved to my own server, which utilizes XEN for hosting VMs. On one of that internal vm's, our webserver is deployed. According to that, I defined firewall rules to route traffic http/https to the vms.
Also the domain was ported, was purchased at old hoster, and the ip of new server is bound to domain.
I use Tomcat 7 as Application Server on an debian based OS.
In old environment, I could use the specified url in CN of my wildcard cert.(e.g. *.domain.com)
In new environment the basic message says: *.domain.com:port is not a trusted site.
I thought actually, that SSL Certs are independent of the used port. I've read that, on some research too. I also searched here in many threads, but the supposed answers didnt work for me.
The certificate and root cert. are imported to Java's own keystore cacerts. In Tomcat 7, I use the JSSE Implementation for SSL, with properly setup keystore files.
I've tried already this, but as im not that experienced with SSL/TLS Technology, the tried solutions maybe even wont solve my problem:
Disabling SNI in Tomcat 7 (dont work)
Adding Host aliases in server.xml (dont work)
Can anyone clarify, what the actual problem is, or has experienced the same issue ?
#edit: The are no error stacktraces in any logs, which I could provide here, also no exceptions gets thrown.

It came clear, thanks to Khanna111 Gaurav Khanna and jwv, that the certificate chain wasnt setup properly. I thought, if there were any problems with the certificate chain, that the browser will notify me about it. It isn't like that.
As we migrated from old hoster to new server, they provided only the certificates, but without the private key.
As im not that much experinced with SSL, I thought that importing the intermediary certs and the acquired cert is enough.. It is not :)
After stumbling on
intermediate-ca-certificate-in-java (link in comment), I've read this, which solved my problem: why doesn't java send the client certificate during SSL handshake? & external website:Import private key and certificate into Java Key Store (JKS)
I had certkey.key,publiccert.crt, intermediate_primary.cer and secondary_primary.cer Files.
The first step was, to convert the .key and .crt file to DER format, as mentioned in last link
via OpenSSL due to keytool's inability to import a key in an existing keystore
After converting to DER Format, I used the Tool ImportKey and created a new keystore with key/cert contained.
The second step was following the instructions of second link (Bruno's Answer), so it was copy&paste the certificate contents, into a single file. After importing the bundle of certificates into keystore, everything was fine.
I hope this can help anyone else, which is also not that familiar with SSL.
p.s. due to my lack of rep, i cannot mention all sites, I've used.. I'll provide them in comments

Setting the right truststore in JBoss 7

I want to send EMails from a JBoss 7 application. The SMTP server needs a TLS connection with a self signed certificate. If I try to send a EMail I get a SSLHandshakeException because the server certificate cannot be checked. To fix this I have add this: http://springinpractice.com/2012/04/29/fixing-pkix-path-building-issues-when-using-javamail-and-smtp/ (putting the SMTP server certificate into a java truststore file)
My problem is now how to set the truststore file to JBoss 7?
I known at stackoverflow and on other forums there are several answer for that propblem. But I didn't found the right.
I have already tried followings:
adding JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/home/stewert.c-on/data/projects/keystore/devel.truststore -Djavax.net.ssl.trustStorePassword=123456" to:
jboss-as-7.1.1.Final/bin/standalone.conf
jboss-as-7.1.1.Final/bin/domain.conf
jboss-as-7.1.1.Final/bin/appclient.conf
adding <jsse keystore-password="123456" keystore-url="/home/stewert.c-on/data/projects/keystore/devel.keystore" truststore-password="123456" truststore-url="/home/stewert.c-on/data/projects/keystore/devel.truststore"/> to jboss-as-7.1.1.Final/standalone/configuration/standalone.xml
But if I check at runtime the system environment variable with 'System.getProperty("javax.net.ssl.trustStore")' I get in every case null!
My environment:
Linux
JBoss 7.1
JDK 7
I'm starting JBoss inside of eclipse Juno
Anybody knows what's going wrong? Where must I set the truststore?
Thanks,
Steffen

Someone asked on the JBoss forum "javax.net.ssl.trustStore - only way to specify client trust?", and the answer is basically "yes".
Their approach was to set that in a system-properties element in the server config XML, which seems like the best way to me too. Better than grubbing about in the run configuration files!

How can I make CLIENT-CERT SSL renegotiation work in Jetty?

I have a webapp that has a public https area, and a private https protected with client certificate using SSL renegotiation.
This configuration works correctly (not without a lot of work) in Tomcat 7 with APR.
Now I'm working with Jetty and I've tried everything but I can't make it work.
The client certificates dialog never appears in the browser, and I always get an HTTP 403 error.
My environment is:
jdk 1.7.0.02
jetty 9.0.0.M3 launched from Eclipse Helios with m2e. (jetty:run)
The server appears to have SSL renegotiation enabled, testing it as indicated here, so I'm quite sure there are no problems with the SSL Renegotiation Security issues.
I've overrided ClientCertAuthenticator (to be able to debug) and created a custom LoginService, and it looks like the X509Cert never appears in the request.
Looks like the SSL renegotiation is never triggered, and authentication fails, because there is not a certificate in the request.
The LoginService configured simply returns true to every validation. I can post them too, if asked, but the important methods never get called.
If I use needCLientCert or wantClientCert application works ok, but then browser asks for the certificate in the public area.
My configuration files:
web.xml: http://pastebin.com/LQ3RcWY4
jetty.xml: http://pastebin.com/iE9xqcLq
jetty-context.xml: http://pastebin.com/rcSsBfRW
pom.xml (jetty part): http://pastebin.com/wBLATggq
Am I missing something obvious? I don't know. I've searched a lot and tried many possible configurations, but, no luck.

http://docs.codehaus.org/display/JETTY/Jetty+Security
Work around by turning off SSL renegotiation in Jetty. If using JVM > 1.6u19 setAllowRenegotiate(true) may be called on connectors
You open your server to the BEAST attack though.