13

I understand this topic was discussed in a couple of older posts, especially Will a self-signed certificate work behind an Apache reverse-proxy? posted by @Ryan

I am facing the same issue but unable to get around it. I have Apache 2.4.12 setup as reverse proxy in front of an Oracle HTTP server. I have valid certs on the proxy server but self signed certs on Oracle HTTP server. The goal is to do https all the way through, but whenever the browser gets to myhost.domain, it throws a cert warning(because of self signed certs). Having authentic certs on Oracle HTTP server is not an option and the users browsers are restricted and hence cannot ignore the self signed cert warning.

Here's my virtual host


LogLevel ERROR
ServerName  myhost.domain
ServerAlias  xxx.xxx.xxx.xx
DocumentRoot D:/xyz/pubdocs
SSLEngine      On
SSLProxyEngine On
SSLCertificateFile      certs/myserver.crt
SSLCertificateKeyFile   certs/myserver.key
SSLCertificateChainFile certs/myserver_chain.crt
SSLProxyCACertificateFile certs/my_self_signed.pem
SSLProxyVerify none
SSLProxyCheckPeerName off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off
SSLProtocol    -all +TLSv1
SSLProxyProtocol +SSLv3 +TLSv1 +TLSv1.1
#SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!NULL:RC4+RSA:+HIGH:+MEDIUM
ErrorLog "logs/abc-error.log"
CustomLog "logs/abc-access.log" cert

ProxyRequests Off  
# IE compatibility
Header set X-UA-Compatible "IE=EmulateIE8"
# Prevent page from being loaded within an IFrame (Cross-Frame Scripting protection)
Header always append X-Frame-Options SAMEORIGIN
# Prevent mime sniffing exploint ; disabled breaks PEM Popup image rendering
# Header set X-Content-Type-Options: nosniff
# Disable caching
Header set Cache-Control "no-cache, must-revalidate, private"
# Enable X-XSS-Protection
Header set X-XSS-Protection: "1; mode=block"
ProxyPass / https://myhost.domain/
ProxyPassReverse / https://myhost.domain/

It seems like using the following directives worked for many people, but doesnt seem to work for me

SSLProxyVerify none

SSLProxyCheckPeerName off

SSLProxyCheckPeerCN off

SSLProxyCheckPeerExpire off

Is there anything else i am missing.

Any help is appreciated.

Thanks, Raj

Community
  • 1
  • 1
Raj M
  • 131
  • 1
  • 1
  • 4
  • Same issue for me, did you ever manage to solve it? – Giovanni Lovato Jan 27 '17 at 11:57
  • Came across this thread and could solve by adding SSLProxyEngine on but that doesn't seem to resolve the issue on the main thread. Saw "SSL Proxy requested for url.com:443 but not enabled [Hint: SSLProxyEngine]" in the logs – Kristofer Feb 26 '18 at 13:58

2 Answers2

1

it has been a while, but we hit the same problem in the year 2022. Here is the setup and the problem:

Reverse proxy Apache 2.4 (Public facing) <---> Keycloak 17 (Internal, works only with https)

All of these are created as docker containers and since keycloak is designed to be only internally visible (behind the reverse proxy), we decided to go with a self-signed certificate. Keep in mind that the self-signed certificate is freshly created every time when the container is build.

Side note: Yes you can create self-signed certificates without a certificate authority (CA) file.

and of course we have all the SSL* Settings mentioned above in the apache config:

SSLProxyVerify none
SSLProxyCheckPeerName off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off

It turns out that having the reverse proxy rule as:

ProxyPass "/auth/" "https://keycloak:8443"
ProxyPassReverse "/auth/" "http://keycloak:8443"
RewriteRule "^/auth$" "/auth/" [R,L]

does not work. The result is a 502 Bad Gateway error. This is because the Apache has a problem with the self-signed certificate of our keycloak. Apparently this is a bug within the proxy_http module.

OUR SOLUTION:

Using the proxy_http2 module works like a charm:

ProxyPass "/auth/" "h2://keycloak:8443"
ProxyPassReverse "/auth/" "h2://keycloak:8443"
RewriteRule "^/auth$" "/auth/" [R,L]

Note the difference: https:// vs h2://

of course for this to work you need to load the proxy_http2 module as well:

  • the http(s)://something entries work with the proxy_http module
  • the h2://something entries work with the proxy_http2 module
Jonas
  • 342
  • 3
  • 8
  • Shouldn't that rather be `https://keycloak:8443` instead of `http://keycloak:8443`? Looks like you were trying to reverse proxy to plain HTTP so something that was listening to HTTPS, so it would be trying to connect using the wrong protocol: that would cause the 502 error, not the certificate verification. – Bruno Feb 25 '22 at 12:32
  • Good catch, but that's my mistake :-) although that should not matter since keycloak would direct to https to https. Regardless I corrected. – Jonas Feb 25 '22 at 13:05
  • Not sure keycloak would. It's not a redirection here, you've specified the port. If 8443 is listening and expecting a connection initiated with the SSL/TLS protocol (which would be quite usual), it's not going to recognise a plain HTTP request coming on that port (unless it does protocol sniffing, which is extremely unlikely). That's very different from an automatic redirection from `http://.../` to `https://...` (which would actually involve two listening ports: 80 and 443). – Bruno Feb 25 '22 at 13:27
-3

It seems that the error is not entirely connected to proxying. The configuration is not entirely clear. I will assume that there are following three machines:

  1. 'laptop' - you
  2. 'proxy' - where the apache with your conf is running
  3. 'oracle' - with some arbitrary webserver

I also assume that all DNS domains aim at the 'proxy' and the rest of the machines are accessed by IP adresses.

The certification path you see from browser is only between 'laptop' and 'proxy'. If you are seeing invalid cert from browser, it meens the 'proxy' failed to authenticate to 'laptop'. If 'oracle' could not identify itself towards 'proxy', the connection would fail outright, throwing 502 error.

So now, what to do next:

  • Check the certificate from the browser. See whose cert it is.
  • If it comes from 'oracle', it means you are not proxying the request at all. Make sure your DNS records aims at the 'proxy' machine.
  • If it comes from 'proxy', but the browser throws fit about wrong CN, you need to create certificate that also includes the 'oracle' domain and put it on the 'proxy' machine.

In case none of it works, try to investigate at which point the following scenario fails:

  1. Laptop asks DNS for 'oracle.domain.com'
  2. DNS returns IP address for 'proxy' machine and sends request.
  3. 'proxy' authenticates to you as provider of the 'oracle.domain.com' service
  4. At this moment you get a green lock icon in browser.
  5. 'proxy' machine resolves the IP adress of the 'oracle' and sends request.
  6. 'oracle' authenticates towards 'proxy' with the self signed cert
  7. content is returned from 'oracle' through 'proxy' to you.

Also, you should include the 'SSLProxyVerify require' to make your config at least a bit secure.

postit
  • 70
  • 4