views:

75

answers:

3

I have some resources I must access with SSL that use self-signed certificates. In general, most tools have a simple setting to allow these to be accessed without error or just a warning. However, it seems like the proper way to do this with the JVM is to import the signing certificate into a keystore as a CA.

I have a groovy script I'd like to use, but I'd prefer my script to work standalone on any any JVM without modifying the keystore or distributing a new keystore. Is there a simple way to override the certification verification?

+1  A: 

i just had to go thru this with a grails app i am working on. You will only deal with the keystore once. Assuming you have the cert, just put it into your keystore, then point your jvm at the keystore via command line props...

edit - i dont know of any way to bypass the need for the keystore. But you can create one with just the cert(s) you need and pass it around with your app. You only do it once.

edit edit -- here is the command for the keytool and the java CL prop

keytool -import -trustcacerts -alias www.the-domain.com -file the-cert.der -keystore store.jks

-Djavax.net.ssl.trustStore=/path/to/store.jks
hvgotcodes
A: 
$ echo 'insecure' >>~/.curlrc
amphetamachine
+1  A: 

After a bit of research, I found this post. Here's what I ended up using:

import javax.net.ssl.HostnameVerifier
import javax.net.ssl.HttpsURLConnection
import javax.net.ssl.SSLContext
import javax.net.ssl.TrustManager
import javax.net.ssl.X509TrustManager

def nullTrustManager = [
    checkClientTrusted: { chain, authType ->  },
    checkServerTrusted: { chain, authType ->  },
    getAcceptedIssuers: { null }
]

def nullHostnameVerifier = [
    verify: { hostname, session -> true }
]

SSLContext sc = SSLContext.getInstance("SSL")
sc.init(null, [nullTrustManager as X509TrustManager] as TrustManager[], null)
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory())
HttpsURLConnection.setDefaultHostnameVerifier(nullHostnameVerifier as HostnameVerifier)
ataylor
In general, hvgotcodes is a better solution. Your mileage may vary, of course. The problem with your solution is that all hosts are now valid instead of just the handful you actually intend to let through.If your code is tightly controlled, and you are certain that you'll only be connecting to "trusted" sources, you'll be fine. However, you are vulnerable to DNS misdirection and any number of other problems from which you'd be protected if you import your certificates into a truststore.You can also set the javax.net.ssl.trustStore property at run time, if you more dynamic behavior.
Brian M. Carr
In general, I agree. But there are certain scripting contexts where it's nice to just ignore certificate management altogether; for example where test servers are dynamically generated and the clients' keystores would have to be continuously kept in sync. It's also worth noting that other dynamic languages such as ruby and python make this a simple configuration setting and don't enforce the certificate chain by default, respectively.
ataylor