While not entirely programming related. I recently purchased a SSL certificate, and during the configuration I need to generate as CSR.
I am running Tomcat behind Apache via mod_jk. I see two options for generating the CSR one for Apache and one for Java based servers. My question is which do i use? At the moment the site needing the SSL is configured to have all requests forwared straight to Tomcat for processing. This however may change to only certain pages. Does it make a difference?
Thanks in advance.
If you are going to use mod_jk then the SSL cert should be generated for apache. mod_jk connects to tomcat over the APR protocol (default 8009) so all SSL handling is done by Apache. This works nice since, in the future, you may only want to proxy dynamic content with mod_jk, assigning the cert to Apache will allow you to proxy static content using HTTPS.
Fyi, the thread you referenced only discussed whether you had to generate the keypair and cert request on the same machine and is not related to running tomcat + apache + SSL. That thread is not relevant to your question.
Related
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?
If I got a signed certificate from letsencrypt.org and baked it into my nginx web server, does that mean I still need to configure express.js to use https?
As in nginx serves me a secure webpage, and I see the https lock on the top left, but do I need to do any extra configuration with express at all??
No node/express does not need to handle ssl - you can have a separate service for node/express and have nginx act as a reverse proxy and do ssl offloading.
Under this configuration, browsers will first hit your nginx web server over HTTPS, nginx will handle the ssl decryption and forward the decrypted HTTP request to your node process.
Your node process doesn't have to know HTTPS is happening at all.
Digital Ocean really has the best docs for setting this up on linux with systemd.
The first link is a clear tutorial on setting up a an nginx reverse proxy to node
The second link shows configuring SSL in nginx w/ a simple reverse proxy (in this specific example - its not a node server on the receiving end but the concepts are the same) to accomplish the SSL termination
We want to use Apache as our reverse proxy to a collection of app servers. We plan to se a CA-signed SSL certificate on the Apache instance but wanted to use self-signed certificates on the app server instances (so that the Apache to app sever connection also was encrypted). We dont want to install a CA-signed SSL certificate on the app server instances if we dont have to.
Will Apache allow this configuration of having self-signed certificates on the app server instances?
If you have a large collection of app servers, it would probably make more sense to have your own internal CA, instead of having to manage each self-signed certificate one by one.
If you want to the connections between an Apache Httpd reverse proxy and its worker nodes to use HTTPS, you can configure the certificates trusted by Apache Httpd using the SSLProxy* directives of mod_ssl (as documented in the introduction of the mod_proxy documentation), in particular SSLProxyCACertificateFile.
You'll need to use mod_proxy_http for this, since AJP connections are not made over SSL/TLS.
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.
I am getting started now on adding SSL login pages to my webapp. I am using apache mod_proxy to proxy tomcat.
Some tutorials showed that I need to get an SSL certificate for apache and proxy my login pages to tomcat on port 8443.
Is port 8443 automatically an encrypted SSL port for tomcat? Do I need both an apache certificate and a tomcat certificate?
Andy
As far as the browser is concerned, Apache Httpd will "terminate" the SSL/TLS connection to your web server. Whether the content it serves is in fact coming from Tomcat doesn't matter to the browser. The browser will only see as far as Apache Httpd in that scenario. If it is set up with a certificate recognised by the browser, this is sufficient.
In addition to this, you may want to encrypt the connection between Apache Httpd and Tomcat. This is only really useful if you don't trust the network between the two (rarely useful on the same host, for example). I don't think mod_proxy_ajp supports SSL/TLS, but mod_proxy_http does, in which case you need to configure the SSLProxy* directives (see introduction): Apache Httpd will be a client in that respect, and Tomcat will need to be configured with a certificate in this case.
If you don't need to encrypt the link between Apache Httpd and Tomcat, the easiest is probably to use mod_proxy_http as a reverse proxy to the plain HTTP port of Tomcat (and make sure that port can't be accessed externally, via a firewall for example).