As of yesterday afternoon, we have noticed that if we create a new task and do not add the Project to it, all works fine, but as soon as we edit that task and add a Project, the screen goes gray and we cannot do anything new with it.
If I create a new task and work through the fields tabbing down and filling them in, as soon as I get to the Project one and select a Project, same thing, I get a grayed out screen and cannot proceed further.
Has anyone else experienced this and is there a fix?
So far the only thing I’m seeing is in node-socketio.log:
{ Error: unable to verify the first certificate
at Error (native)
at TLSSocket. (_tls_wrap.js:1092:38)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:610:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:440:38) code: ‘UNABLE_TO_VERIFY_LEAF_SIGNATURE’, response: undefined }
{ Error: unable to verify the first certificate
at Error (native)
at TLSSocket. (_tls_wrap.js:1092:38)
at emitNone (events.js:86:13)
at TLSSocket.emit (events.js:185:7)
at TLSSocket._finishInit (_tls_wrap.js:610:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:440:38) code: ‘UNABLE_TO_VERIFY_LEAF_SIGNATURE’, response: undefined }
SSL Checker shows that our certificate chain is intact, but I’ve come up with something very interesting:
We run a reverse proxy server using squid on our firewall to route inbound traffic to the appropriate places. Both the proxy server SSL certificate chain and the internal server certificate chains are valid. However:
From inside the office (which bypasses the reverse proxy server and routes the traffic direct from the workstaiton to the ERP server) it works fine.
From outside the office (which goes through the reverse proxy server) we see the grayed out behavior and I find the following errors in Chrome’s debug log:
Actually, 443 is for HTTPS, which can be used for autodiscover, but is most often used for secure, encrypted transactions between a browser and a web server. For instance, we use it to encrypt the information between our service techs and the system at our office so our customers information is not exposed. Banks use it for secure banking transactions, hospitals use it to stay in compiance with HIPAA, etc… So it’s not just used for Exchange’s autodiscover, it’s used for anything that should be secured and encrypted with a purchased encryption certificate from a trusted vendor. In our case, that’s Comodo, but it could also be a variety of other SSL Certificate providers out there.
Actually, I found a “solution” to this problem, but it’s not really a solution. We have a block of 13 usable static IP addresses at our office from our ISP, and we use about 7 of them for various services. I just grabbed the next one in the list and set up a NAT rule on the firewall to forward 443 traffic direct to the ERP server. That solved the problem for outside use since those folks were the only ones having the problem – it worked fine from inside the office. So the issue has something to do with the reverse proxy server solution being between the remote browser and the ERP server. At the moment I’m experimenting with another reverse proxy / load balancer solution to see if it’s specific to squid or if the problem persists across other reverse proxy solutions such as apache and nginx.
-Paul
Addendum: I should also mention that I updated our external DNS records to route the traffic through the new external IP address instead of through the reverse proxy solution.
