Since the limited browsers support SNI, can I ask your another question? If
we'd still like to achieve the same scenario without using SNI: most
customers still https access the portal via our delegate FQDN with its
certificate file, and a couples of customers would like to https access our
portal via their own domain name, but with their own ssl cerfiticate, rather
than prompting the certificate dismatching the hostname. How can we achieve
it with one delegate host? If possible, then we prefer to this solution,
insteadof SNI, which requires too much. Could you please tell me the
details? Thanks a lot.
On Sat, Sep 19, 2009 at 7:12 PM, Yutaka Sato <firstname.lastname@example.org> wrote:
> In message <_A4568@delegate-en.ML_> on
> you David Wang <email@example.com> wrote:
> |Actually our delegate host is our portal, acting as the proxy from https
> |http. Most customers access it via our domain with permmitted source IP
> |address list, such as https://portal.abc.com/ with our ssl certificate.
> |been working fine so far. But now some customers would like to access it
> |their own domain, such as https://portal.xyz.com/ with their own ssl
> |certificate. we can ask them to add a DNS A record to resolve the domain
> |our delegate host IP address, but how can delegate achieve the multiple
> |certificates from multiple domains on the same IP address and port?
> |has official support for SNI since 2.2.12 and the details how to
> |We have all delegate settings with a config file named
> |and running delegate with this CLI:
> |$DELEGATED -P443 SERVER=https RESOLV="file:/etc/hosts-dg,dns,sys"
> |RES_VRFY="" +=/var/spool/delegate-nobody/etc/delegate_https.cfg
> |CERTDIR=/var/spool/delegate-nobody/etc/certs, STLS=mitm those settings
> |is followed from your notes CLUSTER and TLS ext. SNI
> |Also can I have another question? that permitted source IP address list
> |seems not working while accessing our portal via those external domains,
> |such as https://portal.xyz.com/.
> Again I must ask why you use MITM for your usage (that I'm not sure yet).
> STLS=mitm only makes sense in a client-side visible HTTP proxy (referred
> by clients as a SSLtnuuel with the CONNECT method).
> In a HTTPS gateway (a proxy at the server-side, or "reverse proxy" that
> is accessed as if it is an origin server), it must be STLS=fcl in a gateway
> for HTTPS client to HTTP server, or STLS=fcl,fsv in HTTPS to HTTPS gateway.
> Also you should be sure that SNI must be supported on the client-side
> (usually in browsers) to enable and available the feature at the
> 9 9 Yutaka Sato <firstname.lastname@example.org> http://delegate.org/y.sato/
> ( ~ ) National Institute of Advanced Industrial Science and Technology
> _< >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
> Do the more with the less -- B. Fuller