Setting up a public Wildfly (9.0.2.Final) server, I'm figuring out the
alternatives for doing this with or without Apache as a front towards
Internet. I'd prefer to use Apache as this solves other problems for
me.
I should say: I need to use SSL for securing the data traffic.
I've set up SSL for both Wildfly and Apache.
Looking through blogs and tutorials, I haven't found an alternative
that performs SSL between Apache and Wildfly. That would seem to be a
preferred choice for me, where there one.
I've tried and configured
Configuring Apache using mod_proxy_ajp. This prohibits me from
using SSL between Apache and Wildfly but allow me to close the
firewall for 8080 and 8443.
Configuring Apache using mod_proxy_http. This gets me the
Exception of no secure port to forward to on the Wildfly side
which seems not to have any solution.
Open up the Wildfly ports 8080 and 8443 and letting requsts go
directly to a publicly exposed Wildfly, ehich I hear is not
recommended.
Since all three alternatives have their drawbacks, I got to ask: How are people usually doing this?
Related
I have already installed an Apache HTTP server in my RedHat system, now I need to install a Bitnami application package which contains another Apache. So I am wondering how to make them not disturbing each other?
I guess I need to configure different ports for the two HTTP server. But what if one has 8080 and another has 9090, will we visit http://[ServerName]:8080/something.html and http://[ServerName]:9090/something.html? I think this way is quite inconvenient. Am I wrong or any better idea?
My advice would be to do something like this.
Have one Apache instance listen in port 80 and the other one in port 8080 for example. The Apache instance that listens in port 80 can act as a proxy to the other Apache (port 8080) using the ProxyPass and ProxyPassReverse directives.
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
You would need to define prefixes or virtual hosts and inside them add ProxyPass directives.
I don't know to what kind of user those applications are targeted to but the usual end-user is not used to enter ports when browsing the web.
If you like to use the ports, go for it, but I would recommend using Name-based Virtual Host
so you could use different domains or subdomains to each application.
In addition to the example provided by the docs (in where they just point to different folders) in this digitalocean page they document how to make redirects to different urls.
I completely agree with EndermanAPM that usual end-user is not used to enter ports when browsing the web. Therefore, I would only allow port 80 to be accessed by the end-users.
Additional to the current solutions I see another one:
avoid messing up the settings of the Apache servers in order to not end-up with some malfunctions of your websites
leave the Apache servers listen on their designated ports (8080 respectively 9090)
install a dedicated proxy in front of the Apache servers. The proxy would listen on port 80 and would define redirect rules that would parse the request and would redirect it to the proper Apache server. (see the attached picture)
I recommend you HA Proxy. It is a very fast and reliable http and tcp proxy. I've been using it in production for years, in front of application servers, web servers and even database servers. Once you get used with its syntax, it is pretty easy to use.
I am aware that introducing a new component into the equation might add another source of potential issues. But I think that the architecture is cleaner. Besides, the two Apache servers will not be disturbing each other as you requested. You can shut down any one of the two and the other one would properly work further.
I have an application at /mine running on a Jetty server that supports SPDY. It is sitting behind an Apache firewall that is being used as a proxy.
The application at /mine gets routed by the following config rules on Apache:
RewriteRule ^/mine$ /mine/ [R,L]
ProxyPass /code/ https://jettyserver:9443/mine/ nocanon
ProxyPassReverse /mine/ https://jettyserver:9443/mine/ nocanon
As a result, when I hit apache/mine/, my browser is not negotiating SPDY with my application.
Adding mod_spdy to the proxy would be the correct approach but I cannot currently do that with the Apache we are running.
Is there a way I can get this to work?
For that particular configuration you want to run, I am afraid there is no way to get it working with SPDY or HTTP/2.
Apache configured as a reverse proxy talks HTTP/1.1 to Jetty, so there is no way to get SPDY or HTTP/2 into the picture at all (considering you cannot make Apache talk SPDY).
However, there are a number of alternative solutions.
Let's focus on HTTP/2 only because SPDY is now being phased out in favour of HTTP/2.
The first and simplest solution is just to remove Apache completely.
You just expose Jetty as your server, and it will be able to speak HTTP/2 and HTTP/1.1 to browsers without problems.
Jetty will handle TLS and then HTTP/2 or HTTP/1.1.
The second solution is to put HAProxy in the front, and have it forward to Jetty.
HAProxy will handle TLS and forward clear-text HTTP/2 or HTTP/1.1 to Jetty.
The advantage of these two solutions is that you will benefit of the HTTP/2 support of Jetty, along with its HTTP/2 Push capabilities.
Not only that, Jetty also gets you a wide range of Apache features such as rewriting, proxying, PHP/FastCGI support, etc.
For most configurations, you don't need Apache because Jetty can do it.
The first solution has the advantage that you have to configure one server only (Jetty), but you will probably pay a little for TLS because the JDK implementation used by Jetty is not the most efficient around.
The second solution has the advantage that TLS will be done more efficiently by HAProxy, and you can run it more easily on port 80. However, you have to configure two servers (HAProxy and Jetty) instead of just one.
Have a look at the Jetty HTTP/2 documentation and at the Webtide blogs where we routinely add entries about HTTP/2, configurations and examples.
We have a security requirement to configure SSL between tomcat and apache http server. I am using mod_jk for connection between httpd and tomcat servers.
I couldn't find the correct document which explains my situation. If anyone knows, pl. help me.
Short answer, you need to use the HTTP protocol instead of AJP.
HTTP supports encrypted communications (i.e. HTTPS), but AJP does not. If you want to stick with AJP, you'd need to use encryption at a lower level, like a VPN or encrypted tunnel, and then route your AJP traffic over the encrypted network.
If you switch to HTTP, you can use HTTPD, mod_proxy and mod_ssl to encrypt connections between HTTPD & Tomcat. The standard documentation on this is pretty good.
http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass
http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslproxyengine
We want to front-end our Tomcat instance with an Apache instance (running on the same machine) that will be serving everything on HTTPS and connect Apache to Tomcat using AJP. When using AJP, do we need to do anything to make sure that the connection between Apache and Tomcat is secure? (We dont want passwords to be sniffable on the network between Apache and Tomcat). The O/S is Red Hat Enterprise Linux 6.3
You are saying
Tomcat instance with an Apache instance (running on the same machine)
and later you are saying
We dont want passwords to be sniffable on the network between Apache and Tomcat
This just contradicts each other.
EDIT: AJP is not designed to be secure, if you need security, use mod_proxy_http and proxy over https, or create SSH tunnel. Needless to say, you will have to pay for this overhead.
When using AJP you cannot do anything to ensure it is secure. It isn't. There is no SSL version. You would have to use HTTPS. AJP is designed for the usual case where HTTPD and Tomcat are in the same private LAN and security isn't an issue.
I'm sure this is an FAQ but I couldn't find anything I recognized as being the same question.
I have several web-apps running in Tomcat, with some pages e.g. the login page protected by SSL as defined by confidentiality elements in their web.xmls. One of the apps also accepts client-authentication via certificate. I also have a rather extensive JAAS-based authorization & authentication scheme, and there is all kinds of shared code and different JAAS configurations etc between the various webapps.
I really don't want to disturb any of that while accomplishing the below.
I am now in the process of inserting Apache HTTPD with mod-proxy and mod-proxy-balancer in front of Tomcat as a load balancer, prior to adding more Tomcat instances.
What I want to accomplish for HTTPS requests is that they are redirected 'blind' to Tomcat without HTTPD being the SSL endpoint, i.e. HTTPD just passes ciphertext directly to Tomcat so that TC can keep doing what it is already doing with logins, SSL, web.xml confidentialty guarantees, and most importantly client authentication.
Is this possible with the configuration I've described?
I am very familiar with the webapps and SSL and HTTPS and Tomcat, but my knowledge of the outer reaches of Apache HTTPD is limited.
Happy to have this moved if necessary but it is kind of programming with config files ;)
This sounds similar to this question, where I've answered that it's not possible:
You can't just relay the SSL/TLS traffic to Tomcat from Apache. Either
your SSL connection ends at Apache, and then you should reverse proxy
the traffic to Tomcat (SSL [between Httpd and Tomcat] is rarely useful in this case), or you make
the clients connect to Tomcat directly and let it handle the SSL
connection.
I admit it's a bit short of links to back this claim. I guess I might be wrong (I've just never seen this done, but that doesn't strictly mean it doesn't exist...).
As you know, you need a direct connection, or a connection entirely relayed, between the user-agent and the SSL endpoint (in this case, you want it to be Tomcat). This means that Apache Httpd won't be able to look into the URL: it will know the host name at best (when using Server Name Indication).
The only option that doesn't seem to depend on a URL in the mod_proxy documentation is AllowCONNECT, which is what's used for forward proxy servers for HTTPS.
Even the options in mod_proxy_balancer expect a path at some point of the configuration. Its documentation doesn't mention SSL/HTTPS ("It provides load balancing support for HTTP, FTP and AJP13 protocols"), whereas mod_proxy talks at least about SSL when mentioning CONNECT.
I would suggest a couple of options:
Using an iptables-based load-balancer, without going through Httpd, ending the connections in Tomcat directly.
Ending the SSL/TLS connection at Httpd and using a plain HTTP reverse proxy to Tomcat.
This second option requires a bit more configuration to deal with the client certificates and Tomcat's security constraints.
If you have configured your webapp with <transport-guarantee>CONFIDENTIAL</transport-guarantee>, you will need to make Tomcat flag the connections as secure, despite the fact it sees them coming from its plain HTTP port. For Tomcat 5, here is an article (originally in French, but the automatic translations isn't too bad) describing how to implement a valve to set isSecure(). (If you're not familiar with valves, they are similar to filters, but operate within Tomcat itself, before the request is propagated to the webapp. They can be configured within Catalina) I think from Tomcat 5.5, the HTTP connector secure option does exactly that, without requiring your own valve. The AJP connector also has a similar option (if using mod_proxy_ajp or mod_jk).
If using the AJP connector, mod_proxy_ajp will forward the first certificate in the chain and make it available within Tomcat (via the normal request attribute). You'll probably need SSLOptions +ExportCertData +StdEnvVars. mod_jk (although deprecated as far as I know) can also forward the entire chain sent by the client (using JkOptions +ForwardSSLCertChain). This can be necessary when using proxy certificates (which are meaningless without the chain up to their end-entity certificate).
If you want to use mod_proxy_http, a trick is to pass the certificate via an HTTP header (mod_header), using something like RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s. I can't remember the exact details, but it's important to make sure that this header is cleared so that it never comes from the client's browser (who could forge it otherwise). If you need the full chain, you can try out this Httpd patch attempt. This approach would probably need an extra valve/filter to turn the header into the javax.servlet.request.X509Certificate (by parsing the PEM blocks).
A couple of other points that may be of interest:
If I remember well, you need to download the CRL files explicitly for Httpd and configure it to use them. Depending on the version of Httpd you're using, you may have to restart it to reload the CRLs.
If you're using re-negotiation to get your client-certificate, a CLIENT-CERT directive will not make Httpd request a client certificate as far as I know (this is otherwise done via a valve that can access the SSLSession when using the JSSE connector directly). You may have to configure the matching path in Httpd to request the client-certificate.