I've been searching and haven't found a solution for this yet.
I have a LAMP server running Centos 5 and cPanel. I have converted the site from http to https. The site works just fine. However, periodically there are ERR_CONNECTION_REFUSED errors on my PC only. This happens only over https and only periodically. Port 443 is open on the server.
FTP, Remote MySQL, SSH, and HTTPS connections are refused during that brief period. I've checked the server's firewall to allow my ip and unblock my ip. The ip is allowed and was never blocked.
We have other PCs connected to the same network with no issues during the brief period where only my connection is refused. I've cleared my cookies and cache with no luck. However, when I run a trace route, it stops at the first hop in our network.
Any suggestions with what I need to do or look at?
Do you think it is a server related issue?
Do you think it is an internal network related issue?
Could it be the issuer of the SSL cert?
You're probably running into a full backlog queue. A Windows server will actively refuse a connection if the backlog queue is currently full. The defence is to increase the backlog or speed up the accept loop.
Related
This server worked not too long ago (I don't have a specific date). We use it for testing and had successfully deployed a few applications. Upon returning to the project I could no longer access the applications chrome saying the site cannot be reached when I netstat -an | grep 'LISTEN'.
I can see the unsecured port but the SSL port is missing in action. I asked the networking team if the ports were being blocked and they said no. I tried to force the application to use the secure port by disabling the unsecured port, restarting the managed server but the it fails to start with this configuration.
Any thoughts? SSL is not really my area of expertise (this is my first exposure). When googling the title I didn't see any results that matched the problem I am having, or at least I did not realize they did...
The server will restart if I enable the unsecured port.
# Gerardo Arroyo, yes this seems to be the issue. I assumed that this server used the same certs as other servers in the test system but it seems I was wrong. I will request a new cert from the networking team. Thank you
We have been battling with an issue where I've been getting a 5006 error using "SagePay Server" for 24 hours after moving a nopcommerce site to a new server with a different IP address.
We use a free cloudflare service with SSL enabled on Cloudflare in Full SSL mode and then a self signed certificate on our server so the connection is always secured end to end. This was also the same on the old server.
When moving servers we simply updated the IP address in couldflare to point at the new IP address but we started getting 5006 errors during the checkout process...
SagePay support told us they could not connect to our notification URL which was using SSL. Our server showed no attempt from their server to connect to ours yet SapePays log files show an "internal_error" with no more useful information.
However it is possible to the call the notification URL passed to SagePay from a browser and it works without issue.
After talking with SagePay on several occasions it would seem the SagePay system does not support websites / traffic using SSL with SNI which means they can not connect to the notification URL over SSL.
In a time when IPv4 addresses are fast running out I would imagine more and more people will start to use SNI for SSL so they can run multiple sites using SSL from one IPv4 address - a massive oversight on SagePay's part me thinks.
Contrary to JaxUK, I can confirm SagePay does support SSL/TLS with SNI. Hope this helps someone
As the title says, I have a web server on which ssl connections initiated from the local server are extremely slow - 1 minute+ time to load even a hello world txt. Non-ssl connections are not affected. However the same pages/files/web services are served up as expected with little to no delay from any non-local source connection.
For clarification, by local host I mean including domain name, loopback IP as well as assigned network IP.
Any suggestions?
Port Address Translation and an SSL redirect on our F5 was the root cause. /sigh to IT that makes changes without notifying application support, development or product management.
I've got an abuse message from Spamhouse with following:
The host at this IP address is currently being used to distribute malware.
Malware distribution located here:
http://xxx.xx.xx.xxx:8080/get/get.php
Where http://xxx.xx.xx.xxx is our domain.
We've found that any request to port 8080 returns Malware.
We use Apache 2 on server. But there are now any setting on port 8080.
Just looing for ideas how to fix that bug?
At the moment we closed port 8080. But there are still some malware inside.
Will appreciate for any suggestions.
Pull that server offline now.
Deploy new server.
Ensure all relevant OS and application updates are applied.
Double check security configuration.
Restore your data from a verified backup.
Then investigate the original server logs/etc. for clues as to how you were infected in the first place.
I have been trying to connect to a partner's web service which is running on HTTPS default port 443. I had been under wrong impression that they had not open firewall ports for us because telnet from my server was unable to establish a connection. For example, I was typing:
$ telnet <vendor's host> 443
After waiting a long time (Around 15-20 seconds), it prints out that it connected but immediately also says that the connection closed:
Connected to <host>.
Escape character is '^]'.
Connection to <host> closed by foreign host.
However, on running the SOAP UI from the server and hitting a URL that is hosted on the same host and port works fine.
Just wondering why telnet connection gets tripped. Is there any kind of setting possible at the server side?
Maybe you're actually making a Telnet connection? But then it closes because the server finds no interesting conversation, because the server is expecting SSL negotiations to complete.
Understand that Telnet is not very different than TCP. ][CyberPillar: Telnet may discuss that.) So what would you expect the SSL server to do with a TCP connection? In the case of an HTTPS server (which is what I'm presuming, since you mentioned TCP port 443), I would expect the HTTPS server to want to immediately perform SSL negotiation. If a client does not successfully provide SSL negotiation, then the client may just be an attacker trying to use up the server's resources. So, the server won't be wasting resources by responding in interesting ways (like printing out an informative message). That would be the behavior that provides the most desirable results, most of the time. Most connections from clients who know what they are doing will be HTTPS connections by a client that does know how to negotiate SSL.
I would expect similar results from many other protocols that are designed to use encryption. Offhand, I don't know that this behavior is absolutely required by any specific technical specifications/requirements. However, what I do know is that the description you provide, which notes the behavior you experienced, is really not surprising to me whatsoever. Perhaps just from some experience I've had, it's what I would expect. The results you describe would not be surprising to me, even if your firewall was doing nothing. Consequently, I don't offhand know whether your firewall is effectively doing anything noteworthy with this traffic. Maybe the firewall is blocking it, or maybe the firewall is passing it to an HTTPS server which is just handling the connection in a way that you weren't expecting.