This error means the connection to port 443 was actively refused — a network-level failure that happens before any TLS handshake even begins, meaning it's not a certificate issue at all despite occurring in an HTTPS context.
What to check
- Is your web server's SSL/TLS listener actually configured and running on port 443, not just port 80?
- Is a firewall (server-level or network/cloud security group) blocking inbound traffic on port 443?
- Is the web server process itself running at all, or has it crashed or failed to start?
This is a connectivity/server-configuration issue to resolve before certificate troubleshooting is even relevant — no certificate configuration can fix a port that nothing is listening on.
What this error indicates that's fundamentally different from a certificate problem
This error means no service responded on port 443 at all — fundamentally a networking or server-configuration issue (nothing listening on that port, a firewall blocking it) rather than anything related to certificate content, chain, or validity, since a certificate error requires a service to actually respond first.
How to check whether a firewall or security group is blocking the connection
Testing connectivity to the specific port using a simple tool like telnet or nc (netcat) from outside your own network isolates whether the issue is a firewall or security group blocking the port entirely, versus the server itself not actually listening on it — two different problems requiring different fixes.
What server-side checks confirm whether a service is actually listening on port 443
Running `netstat -tlnp | grep 443` or the equivalent command directly on the server confirms whether any process is actually bound to and listening on port 443 — if nothing is listed, no web server or proxy is configured to accept HTTPS connections at all, regardless of any certificate configuration.
How cloud security groups add an additional layer beyond the server's own firewall
In cloud environments, a security group or network ACL operates independently of and in addition to any firewall rules configured on the server itself — confirming both layers explicitly allow port 443 traffic is necessary, since a correctly configured server-level firewall can still be blocked by a more restrictive cloud-level security group.
A final note on proactive monitoring
For infrastructure you manage, adding an automated check that regularly confirms port 443 is actually reachable from outside your network, not just that a service is configured to listen on it, catches a firewall or network-level regression before a visitor reports it to you first.
What the exact commands look like for confirming a service is listening on the correct port
Running ss -tlnp | grep :443 (or the older netstat -tlnp | grep :443 on systems without ss) directly on the server confirms exactly what process, if any, is bound to and listening on port 443, immediately revealing whether the issue is a missing service or something else entirely.
How to test port connectivity externally, independent of the server's own local checks
Using an online port-checking tool, or testing from a completely different network (like your phone's cellular connection rather than your office network), confirms whether port 443 is actually reachable from the broader internet, not just from your own local network's specific vantage point.
A quick closing checklist
A quick closing checklist covers confirming a service is actually listening on port 443, checking both your server's own firewall and any cloud security group rules, and testing connectivity from an entirely external network to rule out purely local network issues.
Why cloud-native load balancers sometimes add their own additional layer to check
If your infrastructure sits behind a cloud provider's managed load balancer, confirming the load balancer itself is correctly configured and healthy, not just your origin server, is a necessary additional check beyond what you'd need for a simple, single-server setup.