----- Original Message ----- > From: Pid <p...@pidster.com> > To: Tomcat Users List <users@tomcat.apache.org> > Cc: > Sent: Saturday, December 24, 2011 1:42 AM > Subject: Re: Creating CSR for Purchasing SSL Certificate from VeriSign > > On 23/12/2011 22:42, Mark Eggers wrote: >> ----- Original Message ----- >> >>> From: Christopher Schultz <ch...@christopherschultz.net> >>> To: Tomcat Users List <users@tomcat.apache.org> >>> Cc: >>> Sent: Friday, December 23, 2011 2:08 PM >>> Subject: Re: Creating CSR for Purchasing SSL Certificate from VeriSign >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Conway, >>> >>> On 12/23/11 4:13 PM, Conway Liu wrote: >>>> Also, if we later add another Tomcat site (with a different domain >>>> name) on the same Windows 2008 R2 server, do we have to generate >>>> another CSR to purchase another SSL certificate? >>> >>> Apache httpd and non-APR Tomcat use different certificate storage >>> formats: httpd uses a fairly simple PEM file format where you can have >>> one or more certs concatenated together in a single file (or >>> separately). When using APR with Tomcat, it uses the same format as > httpd. >>> >>> If you aren't using APR, then the underlying Java environment is >>> providing crypto services through a KeyStore which is stored in a >>> completely different format. >>> >>> The certificates themselves are a standardized format, and you can >>> export from one format and import to the other format whenever you >>> want. You just need to figure out the right incantations of > "keytool" >>> and "openssl" to make that happen. >>> >>> So, have no fear of making a decision now that cannot be undone. >>> >>> - -chris >> >> >> One of the things you can do is get a SAN (subject alternate name) > certificate with lots of different host names. If you are running everything > from one IP address / port (named virtual hosts), this is pretty nice. >> >> Apache HTTPD complains a little about using named virtual hosts for > configuration, but it works in practice. It seems that the configuration > parsing > engine doesn't like this on start up, but it works once running. There's > actually a patch in queue to solve that problem. >> >> I suspect that Tomcat using the APR libraries will behave the same. It > looks like Java since 1.5 has supported SAN certificates as well, but I've > not tried this. >> >> You could experiment a little before purchasing a SAN certificate. I have > some links on how to create your own root authority and signed SAN > certificates > if people are interested. > > A note: SSL protects the transport. In the case of HTTP, this means > that the SSL handshake occurs before the receiving party can see which > host header is in use, because the TCP connection process doesn't > include the DNS name, that is resolved away to IP + port beforehand. > > In the case of virtual hosts, this used to mean that an SSL protected > virtual host had to run on its own IP address. > > SAN cert support, wildcard certs now provide an alternative, but both > are dependent on their support in browsers (which is improving). > > > p
SSL SAN cert support in recent browsers is pretty good. For example: http://www.digicert.com/subject-alternative-name-compatibility.htm On my test setup (Apache HTTPD 2.2.21 <-- mod_jk 1.2.32 --> Tomcat 6.0.33) and the latest Firefox or Google Chrome, this works pretty well. SSL SNI support on the other hand is not well supported. In particular IE and Safari on Windows/XP do not support SNI. Most older mobile browsers don't support SNI as well. I ran into this issue recently while setting up Apache HTTPD<-- AJP -->Tomcat with multiple virtual hosts and SSL. . . . . just my two cents. /mde/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
