Quoting Doug Poland <[EMAIL PROTECTED]>:
David DeSimone wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Doug Poland <[EMAIL PROTECTED]> wrote:
I have DNS resolution, the problem ( I think ) is in that pf simply
sees the packet destined for my single public IP (because all my
public host names must resolve to the same public IP address) and port
443.
I am not sure how you expect this to work. The web browser will expect
the server to send a certificate with its identity as part of the
initial SSL negotiation. The client has not yet sent its request, so
the web server has no idea which of the three domains the browser wanted
to talk to, so it does not know which certificate should be sent. This
is the reason why every SSL site must have its own unique (public) IP
address.
- -- David DeSimone == Network Admin == [EMAIL PROTECTED]
I see what you are getting it. I told pf to simply route all https
requests to a fixed private IP. When I pointed my browser at the
FQDN, firefox told me I had a certificate problem... i.e., the
certificate returned was not the one expected.
So, is the bottom line, one *cannot* hide multiple (NAT'd) SSL hosts
behind a single public IP? So my only solution, given apache and one
public IP, is a single host listening on 443 and each "domain" would
have to be served as a <Directory></Directory>. e.g.,
https://secure.example.com/webmail/
https://secure.example.com/subversion/
instead of
https://webmail.example.com
https://subversion.example.com
This is actually more a DNS solution than anything else.
For example there is nothing to stop you from using the following
in example.com's zone file:
$ORIGIN example.com
@ IN SOA ns.example.com. rootexample.com. (
...
)
IN A pu.bl.ic.IP
IN NS ns.example.com.
IN NS another-ns.some-domain.tld.
webmail IN A pu.bl.ic.IP
subversion IN A pu.bl.ic.IP
another-host IN A pu.bl.ic.IP
where pu.bl.ic.IP = your internet routeable IP.
then simply setup another zone to route your private
IP block. This requires a "multi-view" named configuration.
But will give you all the routing you require to get this
done. Given the above, you'll be able to self-sign all of
your hosts certs - or better still, have them signed "officially".
But if you self-sign, you can have example.com sign all the
hosts certs that are within example.com.
Anyway, point being; you can resolve alot of what you are trying
to accomplish with a little DNS trickery.
Best wishes.
--Chris
--
Regards,
Doug
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
panic: kernel trap (ignored)
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"