|
|||
|
|||
Hi
We run CommitCRM web server (nonSSL) on default port (4961) and I am trying to add Apache reverse proxy to allow secure access to CommitCRM for clients via webserver. Main reasons for it: 1. Secure the traffic. 2. don't expose CommitCRM server (running on Windows) to the internet. As you can imagine I failed with the hask. with my current setup it keeps the server name but changes port number to 4961. Not sure if this is something that configured wrongly on Apache or CommitCRM Web App overwrites it. I just wonder if anyone tried it and been more successful or anyone can help with it. my setup is: CommitCRM server http://192.168.1.6:4961/ Proxy server CentOS release 6.8 (Final) Apache/2.2.15 Config file <VirtualHost *:443> ServerName myserver.co.uk SSLEngine on SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateFile /etc/httpd/ssl/commit/2_myserver.uk.crt SSLCertificateKeyFile /etc/httpd/ssl/commit/myserver.co.uk.key SSLCertificateChainFile /etc/httpd/ssl/commit/1_root_bundle.crt ProxyRequests off ProxyPreserveHost on SSLProxyEngine on Loglevel info ErrorLog logs/myserver.co.uk_error.log TransferLog logs/myserver.co.uk_transfer.log ProxyPass / http://192.168.1.6:4961/ ProxyPassReverse / http://192.168.1.6:4961/ Header edit Location ^http://192.168.1.6:4961/ https://myserver.co.uk/ </Virtualhost> Regards Artak |
|
|||
|
|||
Thank you for posting and for providing all details.
Using a reverse proxy will most like not work. The system wasn't designed for it and as you can see it falls back to the configured port (4961). With SSL you should use Microsoft IIS as the back end for the Web interface, unlike using it as a Windows service. Visit Microsoft IIS as the Web Server for the Web Interface to learn all about how to configure it. Hope this helps. |
|
|||
|
|||
I also suggest that you use a UTM to protect the access to the CommitCRM Web server. I know there are brands like Ubiquiti Unifi series USG routers, Sonicwall, Fortigate, even the pFsense, can do GeoIP filtering and block access only to the client base that you have. That will significantly reduce threats in terms of breach of access to the web-facing server.
|