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




-- 

[key:62590808]

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to