Philip Guenther skrev:
On Tue, Aug 11, 2009 at 4:11 PM, kami petersen<[email protected]> wrote:
I'd like to propose that relayd be made to accept
/etc/ssl/hostname.crt
/etc/ssl/private/hostname.key
as well as what's currently looked for:
/etc/ssl/IP-address.crt
/etc/ssl/private/IP-address.key
Currently it is possible to specify hostnames in relay specifications
but it seems that they are resolved to IP-addresses before relayd is
looking for certs.
Do you understand that in SSL, the server has to decide what
certificate to send to the client based on just the remote and local
IPs and ports? Given that, how should the server decide what
certificate to send?
Sorry for being unclear. I'm thinking relayd could deduce what certs to
associate for which relays by adding .crt/.key to the hostname in the
respective listen directive
relay wwwssl_a {
listen on a.com port https ssl
protocol httpssl
forward to 10.0.0.10 port http
}
relay wwwssl_b {
listen on b.com port https ssl
protocol httpssl
forward to 10.0.0.11 port http
}
relay imapssl_a {
listen on a.com port imaps ssl
protocol imaps
forward to 10.0.0.12 port imap
}
would associate /etc/ssl/a.com.crt and /etc/ssl/private/a.com.key with
both wwwssl_a and imapssl_a, and associate /etc/ssl/b.com.crt and
/etc/ssl/private/b.com.key with wwwssl_b.
It's up to the admin to have the certs in place and ensure a.com and
b.com are different IPs. Then after resolution and binding takes place
relayd knows what certificate belongs to what IP/port.
The alternative/additive, a new directive to override default behaviour,
like:
relay wwwssl_c {
listen on c.com port https ssl
certificatefile /some/other/cert.crt
keyfile /some/other/private/key.key
protocol httpssl
forward to 10.0.0.13 port http
}
IP-based virtual hosts in other words. No reason to cripple relayd to
one IP just because it's SSL.
Kami Petersen
(patch? I only wish I could.)
