-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessing Check_MK via HTTPS doesn't redirect properly #1
Comments
The URL rewriting doesn't work properly when using a Apache httpd reverse proxy with HTTPS enabled. This should fix some of the issues mentioned in debops-contrib#1
With #10 the most obvious redirect errors should be fixed. Especially access to If the default patches don't apply correctly, refer to the check-mk-raw-1.2.8-read-X-Forwarded-Port-header.patch in There are still two issues that But I guess it makes more sense to port the currently used HTTP(S) proxy from the embedded Apache httpd to a Nginx managed by the |
Using Nginx is probably ideal. Another way what I just came up with for an existing setup is to install redirects for the http vhost for the global apache like this: RewriteEngine on
RewriteRule "^/(site/.*)" "https://{{ domain }}/$1" [R,L]
RewriteRule "." "https://{{ domain }}/site/check_mk/" [R,L] Maybe even change it to HTTP 307. I would try to avoid patching up OMD where possible 😉 I am using:
which does quite a few redirects. As you described the current versions seems to do similar things. Another thing. Since yesterday there is a |
Thanks a lot for your hint. I'll try that. 👍 I'll also have a look at the |
There are multiple issues when running Check_MK with HTTPS enabled:
https://<server>/<site>
an invalid redirect tohttps://<server>:80/<site>/omd
will be returned. This happens because the CGI environment variable${SERVER_PORT}
in/omd/sites/<site>/etc/apache/conf.d/omd.conf
is not properly set to 443.https://<server>/<site>/check_mk
a redirect tohttp://<server>/<site>//check_mk/login.py?_origtarget=index.py
will be returned. This still needs some investigation. After being authenticated, the access via HTTPS works.I didn't check yet, if these issues are known to upstream or if this is specific to our setup.
The text was updated successfully, but these errors were encountered: