We are in line and my points are only minor, almost to be seen as nitpicking (which is not my aim) or rather willingness to clarify details.
In this case I really want to have a new subdomain (yes, technical implemented as vhost) because we have multiple customers with different domains, services and servers. Some services are provided via the above described Zentyal machine and port 443.
So i want to provide a new unique subdomain to all our customers to give them the ability to change their passwords.
Clear enough... let me explain further what I meant:
you want to provide access to
https://secure.whatever_domaine/so far so good. What I'm fighting against is to call this "subdomain". That's it and, at the end, it doesn't matter and should not be seen as blocking point in our debate but I'm convinced that using the right wording helps getting structured ideas, especially for admins not having everything clear in mind (and you are obviously not in this category
)
in above URL,
what_ever_domain is THE domain and
secure is either
host or
vhost matching either
A or better
CNAME record in DNS.
If you had to provide access to URL like:
https://secure.something.whatever_domain/, then
something will be the real subdomain.
There are two techniques to get encrypted http connections known as 'ssl' and 'tls'.
The new one is 'tls' but It's not supported by a wide range of common (mostly older) browsers. Tls can handle multi domains because the encryption will start at a later communication level but ssl don't.
When a ssl connection will be initiated, first the connection will be secured and then the URL will be send to the server. Therefore the Server has to deliver it's certificate before the client told him which domain he want to contact. The client (Browser) verifies the certificate against the URL. If you are running multiple vhost with different domains only one Domain can be handled correctly via the ssl stack.
I'm right?
I fully share, except for what concerns, again, your "domain" wording
With one exception:
If all your domains are subdomains of the same domain and you are providing the same wildard certificate each connection is valid from the browser point of view.
In any other ssl-case (I hope) you will get a certification error (Invalid certificate ... bla, bla, bla...)
yes and no
HTTPS is, from my standpoint, often misunderstood. Goal is of course to build encryption thanks to tunnelling but also to ensure, as much as possible, that web site you access is really the one you expect to access.
As you rightly explains, on same IP, you can have only one Apache listener on port 443, meaning only one certificate, by design.
Use of generic certificate is one pretty obvious solution but is you do not intend to have too many vhosts (and not too many subdomains
), then another option could be to have multi-named certificates using the SubjectAltNames feature. Doing so, client will get more confidence that server he is accessing is exposing service with certificate matching service name.
Another approach, of course, is to use alternate IP but this is not always easy especially when having many services.
With the exception of webmail and usercorner, I don't feel Zentyal is performing very well for what concerns support of web server.
As you have experienced it already, customizing your vhost conf is not very easy neither flexible.
That's where your reverse proxy approach fully makes sense to me: run reverse proxy at Zentyal level and redirect HTTP requests to internal web server(s) running your web sites. It also provides load balancing and fail-over that cannot be provided (for the time being ?) by Zentyal
Topic: Tip: usercorner (port 8888) redirect to new subdomain at port 443 with mod_proxy (Read 8978 times)