Hi, Jakarta-General, Let's vote on where to put this code! Here's the code right now:
http://juliusdavies.ca/commons-ssl/ Forgive my newbieness; I hope these are the right options: [+1] Sub-module in Httpcomponents. [+1] Sandbox. [+1] Full Incubator. [-1] "not-yet-commons-ssl" is not a good project for Apache because... I'm fine with majority rules, assuming there are no "-1" votes. Some background: http://wiki.apache.org/jakarta/JakartaBoardReport-February2007 "The code grant for the not yet commons SSL (formerly named commons-ssl), has been completed, so we can progress to having a vote where SSL should end up on general and based on that result take the correct incubator path (legal / full incubation)." Let's just get this vote out of the way, and then we can move on to other issues in the appropriate venue (HttpComponents, or Sandbox, or Incubator). My original proposal to "jakarta-general" about the project is here: http://www.mail-archive.com/[email protected]/msg12790.html Yesterday I released "not-yet-commons-ssl-0.3.7". Changes described at the bottom of this email. My intention is for 0.3.7 to be the last release outside of Apache. By the way, there's one undocumented feature of common-ssl that's been quite fun: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/OpenSSL.html :-) yours, Julius ps. My vote is: [+0] - Abstaining because I'm too much of a newb to really understand what I'm voting for. On 2/23/07, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 10:20 -0800, Julius Davies wrote: > not-yet-commons-ssl-0.3.7 released! > > http://juliusdavies.ca/commons-ssl/download.html > > Hi Julius, What are your plans regarding not-yet-commons-ssl? Is there anything still blocking the incubation process? There are already two Apache projects (HttpComponents and Synapse) that can potentially benefit from collaboration with not-yet-commons-ssl. So, there is a lot of interest in seeing things moving forward. Oleg
Features as of not-yet-commons-ssl-0.3.7: 1. useStrongCiphers() used by default. ------------------------------------------------------------------------- 40 bit and 56 bit ciphers are now disabled by default. To turn them back on call useDefaultJavaCiphers(). 2. addAllowedName() adds some flexibility to the CN verification. ------------------------------------------------------------------------- Here's a code example using "cucbc.com" to connect, but anticipating "www.cucbc.com" in the server's certificate: SSLClient client = new SSLClient(); client.addAllowedName( "www.cucbc.com" ); Socket s = client.createSocket( "cucbc.com", 443 ); This technique is also useful if you don't want to use DNS, and want to connect using the IP address. 3. SSLServer can re-use a Tomcat-8443 private key if running from inside Tomcat. ------------------------------------------------------------------------- SSLClient server = new SSLServer(); server.useTomcatSSLMaterial(); 4. RMI-SSL support improved. ------------------------------------------------------------------------- Attempts to re-use the Tomcat-8443 private key for all RMI SSL Server sockets. Anonymous server-sockets (port 0) will always be set to port 31099. Analyzes the server certificate CN field and tries to set "java.rmi.server.hostname" to something compatible with that. Probably the only free implementation around that does a good job on the hostname verification! 5. KeyMaterial constructor blows up earlier. ------------------------------------------------------------------------- If a JKS or PKCS12 file is provided that isn't going to work (e.g. no private keys), the KeyMaterial constructor throws an exception right away. 6. getSSLContext() now available to help inter-op with Java 5 SSL-NIO libraries. ------------------------------------------------------------------------- Oleg has been working hard on SSL-NIO for the Apache httpcomponents library. Go check it out! 7. Fixed bug where SSLClient couldn't be used with javax.net.ssl.HttpsURLConnection on Java 1.4.x ------------------------------------------------------------------------- I was wrapping the SSLSocket, but Java 1.4.x guards against that inside HttpsURLConnection and throws this exciting exception: java.lang.RuntimeException: Export restriction: this JSSE implementation is non-pluggable. at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.checkCreate(DashoA6275) at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(DashoA6275) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:560) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(DashoA6275) Silly Java - I'm still using your JSSE implementation, I'm just wrapping it! The KeyStoreBuilder command-line utility can go both ways now (to jks, and to pkcs8 in PEM format). So you can use it to convert a java "keystore" file into an Apache-SSL compatible PEM file for your httpd server! http://juliusdavies.ca/commons-ssl/utilities.html ============================================ $ java -cp commons-ssl-0.3.7.jar org.apache.commons.ssl.KeyStoreBuilder KeyStoreBuilder: outputs JKS file (java keystore) as ./[alias].jks [alias] will be set to the first CN value of the X509 certificate. ------------------------------------------------------------------- Usage1: [password] [file:pkcs12] Usage2: [password] [file:private-key] [file:certificate-chain] ------------------------------------------------------------------- [private-key] can be openssl format, or pkcs8. [password] decrypts [private-key], and also encrypts outputted JKS file. All files can be PEM or DER. ============================================ -- yours, Julius Davies 416-652-0183 http://juliusdavies.ca/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
