when i run with https the page say
Felkod: SSL_ERROR_RX_RECORD_TOO_LONG
Check here and post the results:
1 Like
Old topic but I think I have found why my is not working.
I have help a friend with his new server and he also running same system that I do (nethserver reverse proxy and Milestone)
But he working because I have not activate right now HTTPS with letencrypt
So if I run HTTP it works with winsock but when I run HTTPS it does not work??
Not sure how to fix this.
Hi
In your case, https probably doesn’t work because you have a self-created (untrusted CA !) cert.
A lot of “apps”, especially python & java are VERY fussy about ssl certs. Lets Encrypt works without ANY issues, so why not use them?
LetsEncrypt is very easy to use, and you only need a domain (kinda obvious, LE doesn’t work on IPs) and http access to your NethServer…
My 2 cents
Andy
1 Like
I do use Lets Encrypt on my servers.
But I think Milestone does not like Lets Encrypt?
Well, I understood your friend has it working in a similiar environment, with the exception he is using https…
Maybe you need to compare your reverse proxy setting with his…
One thing: Are you forwarding the request with http or https?
That may be an issue…
In this (working) example, I’m not using https, simple http to access the PI-Hole internally:
Maybe you also need “Accept invalid SSL certificate from target”
1 Like
Thanks for replay
I have try both http and https internal to milestone but does not work.
But right now is that ok as long he and I can access from web client even if it not secure it is ok.
Hi @cazz,
DNS Host
Create a DNS Host entry for the domain and pointing to 192.168.1.4
Firewall Object
Create a Firewall Object with IP: 192.168.1.4
Forward the port 8081 to 192.168.1.4
Reverse proxy
Destination URL, use https://192.168.1.4
Disable Require SSL encrypt connection
Enable Forward HTTP “Host” header to target
conf file
Add those 2 lines in the conf file…
RequestHeader set X-Forwarded-Proto "https"
AllowEncodedSlashes NoDecode
… just before
Michel-André
This is not related to proxypass IIUC
https://httpd.apache.org/docs/2.4/en/mod/core.html#page-header
This is needed by some application is it seems but not all. One example is jenkins
https://www.jenkins.io/doc/book/system-administration/reverse-proxy-configuration-apache/
But it uses also the port
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
Maybe we can add an option in the server relative to proxypass and https, default disabled
1 Like
Salut @stephdl
I totally agree with you but:
With the value
NoDecode, such URLs are accepted, but encoded slashes are not decoded but left in their encoded state
If the receiving program is expecting a certain URL suffix from the client, then this parameter will make sure that the complete received URL suffix will be passed by the proxy as it is sent by the client.
That is the reason I suggested that parameter.
Michel-André
Thanks for the replay
Have not have time to try but was going to do that now.
I have to first say I work most with Ubuntu so I’m not sure where to find the config file for proxy forward in CentOS.
/Update find it 
This is related to virtualhost and proxypass but the default is off, the option on is not advised so the two good parameters are nodecode or off
So if this option is needed it must be done in the two panels. It is the first time I read this need, what application needs it ?
Salut @stephdl,
PH32435: ENCODED CHARCTERS (%2F ETC) IN URI.
WebSphere Application Server for IBM i.
Client unable to access WebSphere through HTTP Server/plugin when there is encoded charcters (%2f etc) in URI.
This symptom occurs when client access WebSphere through HTTP Server/plugin.
This symptom does not occur when client access WebSphere directly (not through HTTP Server/plugin).
https://www.ibm.com/support/pages/apar/PM31189.
Problem conclusion
A new value for AllowEncodedSlashes was added, "NoDecode", which accepts URLs with encoded slashes in the path info but does not decode them.
Michel-André
1 Like
The current default Apache value for AllowEncodedSlashes is Off. IIUC if a %3F sequence is sent by the client a 404 response is returned unconditionally.
The NoDecode value is a “relaxed” behavior. I guess Apache at least make an attempt: if the requested file name matches literally, it is returned (e.g. this%3Ffile.gif - but ok, that’s a bit weird case).
Changing the parameter value everywhere on the fly should be safe, but as usual the safest path is defining a prop and change its default value for the next NS release: 7.10. I’d avoid a new UI checkbox because the new default behavior shouldn’t harm in 98% of cases 
That would be the same strategy to be applied here:
1 Like
Current value of AllowEncodedSlashes is good for 99% of configurations.
I’m against on changing the current default, even with a prop.
This seems to me the perfect candidate for a template-custom.
I agree with Davide that a UI option doesn’t make sense for this corner case.
2 Likes
One pro for this setting
A vhost-specific prop (not global) could be a good compromise. If many users enable it we can think again to implement the UI part.
As it is not global, there’s nothing to upgrade with 7.10
1 Like