Philip B. Howells wrote:
Thanks for the prompt response, Jay. Yeah, we have one box (2 processors
:), on one ip. This is just wishing now, but I wonder if there is a way to
extend the ssl handler to be just like apache's handling of vhosts. IOW,
pull the url name from the request, and use that to pick our cert.
The vhosts you're referring to are all non-ssl. The HTTP 1.1 spec
defines an exchange under which the client specifically tells the server
what "host" it connected to when it requests data (The SMTP, POP, and
IMAP specs don't make such a provision). That, however, obviously takes
place after the connection is built up. Traditional SSL connections are
negotiated immediately after the connection is complete, and before the
client and server begin their encrypted conversation. Since the SSL
negotiation takes place before the client has given the server any
information, the only information that the server has is the IP address
that the client connected to (but not the dns hostname that may have
been used).
Due to the limits of the available information, SSL virtual host require
separate IP addresses. That can be done with Courier, too.
However, the option that I'd recommend is that you use the name of your
own service in your client settings. If you're "foo.com Hosting", then
have your clients all use "mail.foo.com" for their server when sending
and receiving, and they won't get any errors or warnings related to SSL.
There's no reason to make the setup any more complicated than that.
8 messages in net.sourceforge.lists.courier-usersRe: [courier-users] courier certificates
