Hi, David, What do you mean, exactly?
Do you have several certificates? If so, then no, can't share several certificates on one socket. There isn't enough information available to the plain socket (source ip, source port, target ip, target port is all we have!) to decide on a certificate to use when building up the SSL. Do you have a single certificate with several domain names listed inside it? If so, then standard Java JSSE as far back as Java 1.3 should work just fine on the server or the client. Not-yet-commons-ssl is also fine with this. (Verisign is clever, though, and they charge full price for each domain added to the certificate). Do you have a wildcard in your certificate's CN field? (e.g. CN=*.credential.com)? Then, again, Java JSSE as far back as Java 1.3 is fine with that. Same for not-yet-commons-ssl. When acting as a client, not-yet-commons-ssl (by default) is more lax compared to java.net.URL with hostname verification: CN=*.foo.com java.net.URL will complain when connecting to "a.b.c.foo.com" (similar to IE6). Not-Yet-Commons-SSL doesn't complain (similar to Curl and Firefox). Mind you, that behaviour can be changed: SSLClient client = new SSLClient(); client.setHostnameVerifier( HostnameVerifier.STRICT ); Here's the Javadoc explaining how Hostname Verification works in Not-Yet-Commons-SSL: http://juliusdavies.ca/commons-ssl/javadocs/org/apache/commons/ssl/HostnameVerifier.html Hope this helps! yours, Julius On 2/23/07, David Fisher <[EMAIL PROTECTED]> wrote:
Hi Julius - I have a question. Does "not-yet-commons-ssl" allow me to "virtual host" multiple domain ssl certificates on a single socket on a Tomcat 4.1.31 server? That would be awesome if it does. Unofficial "+1" Regards, Dave Fisher On Feb 23, 2007, at 11:57 AM, Julius Davies wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- yours, Julius Davies 416-652-0183 http://juliusdavies.ca/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
