I have a setup with Netscaler, plus apache 2.2.16 configured as a reverse proxy to tomcat servers.
I do the SSL offloading at the Netscaler level, but my client has made a request to redirect a specifig page to their CRM login page thats using an SSL Cert. https://$ip
When the SSL is offloaded at the netscaler level, the virtual host received unencrypted traffic, but with the clients request, I need to enable the SSL engine on apache and put the certs in the config, hence the proxy rejects the non encrypted traffic coming in on port 443.
I proxypass / to the backend.. so I am out of clue on how i should fix this particular problem.
Any comment or help are most welcome.
If the traffic to the backend must be encrypted, there's no point in using the NetScaler for SSL offload. Just set up an SSL bridge on the NetScaler to pass the traffic through to the backend, and handle the redirection on the server.
Related
I have a wildcard SSL certificate on my apache server. It works perfectly with my domain, but the mistake is that it works with all the domains on my apache server ! And I don't want it, when I go on https://www.mywebsitewithouthttps.com, firefox tell me that the page is not secure because the certificate is for www.mydomainwithhttps.com. If I add an exception for this SSL error on my browser, it is not "mywebsitewithouthttps.com" that is display but "mydomainwithhttps.com" (on this URL : https://www.mywebsitewithouthttps.com) !
I don't want my certificate to work for all the other domains ! It's a big problem because Google is crawling and indexing all my other domains on HTTPS with the content of mydomainwithhttps.com :-(
This my virtualhost for SSL :
NameVirtualHost *:443
<VirtualHost *:443>
ServerName www.mydomainwithhttps.com
DocumentRoot "/home/mydomainwithhttps/www"
suPHP_Engine On
suPHP_AddHandler x-httpd-php
suPHP_UserGroup mydomainwithhttps users
AddHandler x-httpd-php .php
SSLEngine on
SSLCertificateFile /certificates/ssl_certificate.crt
SSLCertificateKeyFile /certificates/www.mydomainwithhttps.com.key
SSLCACertificateFile /certificates/IntermediateCA.crt
</VirtualHost>
If you make a HTTPS request the client will establish a TCP connection to the relevant IP and port (usually 443) at the server. If the connection succeeded it will start the TLS handshake and during the TLS handshake it will get the certificate for validation.
If you have multiple servers at the same IP address and port they all share the same TCP listener. Since the TCP connection attempt has no information about the targets server name but only has the targets IP address and port the listener will accept all connection attempts, even if the (yet unknown) target hostname has no HTTPS configured.
Modern clients then send the target hostname inside the TLS handshake and only then the server knows what the client wants. If it has HTTPS configured for the requested name the server can send the appropriate certificate. If HTTPS is not configured for this name the server will either send a default certificate or close the connection (maybe send a TLS alert when closing).
In summary this leaves you with the following options:
Use a different IP address for HTTPS sites and non-HTTPS sites. This way the TCP connection will already fail because the server is not listening for connections on this IP:port.
Configure your server to return an error when the client requests a hostname for which no HTTPS is configured. This way the client will probably get some strange error message about HTTPS problem in the browser. I'm not sure but maybe you can setup Apache this way when using the SSLStrictSNIVHostCheck on option. If this option does not help then apache might not support this kind of setup.
Configure your server to use a default certificate (usually the first configured certificate) whenever the name does not match or the client does not support SNI. The client will get a certificate mismatch warning in the browser. This is the setup you currently have.
Setup HTTPS properly for all domains either by having separate certificates or by including them all into a single certificate.
Thus to make sure that the bots don't assume that your site can do HTTPS you need to go with option 1 or 2. Please note also that in all of these cases you expect the bots to support SNI, which not all do. Therefore for best compatibility you would need to use a separate IP address for each HTTPS site.
You can configure the multi domain with SSL and with different certificate on both UBUNTU and RHEL by following multi donain with ssl
The problem is that Apache will try to find config for https://www.mywebsitewithouthttps.com/ and when it doesn't, it will default back to the first https config (the one for mydomainwithhttps).
This will show a cert error but, as you've experienced, if you click through, you see the wrong site.
I cannot however understand Google crawling and indexing the site. I would have thought it would have stopped when it saw the cert error? I'd be very surprised if that is not the case but if it's not you can put a rewrite rule on for those hostname a to redirect back to http.
There's only 2 ways around this:
Get certs for the other domains so you can connect via https. You can still redirect back to http if you really want.
Separate out the servers with https to a different server (or a different IP on the same server and set up Apache config to listen on port 443 on https IP address only).
That's just the way Apache (and most - if not all - other webservers) work.
How can I set up proxy which listens on https and proxies the requests to other server on https without setting up SSL certificate on Apache for inbound https requests?
I just need to proxy the request over https connection.
If you don't have the SSL certificate in question on your apache box, it will be very difficult to set up proxying. The site configurations usually rely on the Host header and the URI path, which you won't have if you can't unwrap SSL.
Instead, if all SSL traffic is to be forwarded unconditionally, you might consider a TCP proxy instead of an application proxy.
There are several ways of setting this up, and it will vary depending on your chosen platform. If you're running on Linux, you can easily set up an iptables rule to forward requests to 443 to some remote host.
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
I've used both Apache and nginx as a reverse proxy performing HTTPS termination (listening on port 443) and forwarding the unencrypted HTTP traffic to Tomcat on port 8080 before.
However, what I need to do now is do the opposite. I have some client applications running on localhost that are (for simplicity) just talking plain HTTP. I want to be able to tell these client apps to use a forward proxy (on localhost) that will convert them to HTTPS and use a client-side certificate for the communication to the origin. Ie, the client will think it is communicating plain HTTP on port 80, but the traffic will actually leave the host as HTTPS on port 443.
Does anyone know how to configure mod_proxy to do this (or even if it is possible)?
At a further stage, I may need to configure the proxy to use different client certificates based on headers set by the client and also have mod_proxy use RFC 5077 (quick session resumption).
It doesn't have to be Apache (so if nginx or squid can do the function I'm happy with that) as long as it's not a resource hog. We already have Apache running as a reverse proxy anyway so it would be handy if Apache can do it.
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).