Troubleshooting ERR_CONNECTION_TIMED_OUT, AWS Port 22, and SSL Expiry Errors

Understanding Connection Timeouts and SSL Failures

At the core of almost every networking issue—whether it is ERR_CONNECTION_TIMED_OUT in Google Chrome, an AWS EC2 SSH Port 22 connection timed out, or a database connection attempt timing out in DBeaver—lies a failure in the initial handshake or a breakdown in the subsequent secure negotiation (like an expired SSL certificate).

When a client attempts to connect to a server, it expects a response within a specific window (typically 30 to 60 seconds). If the server fails to respond, the network drops the packet, or the secure layer (SSL/TLS) rejects the connection due to validity issues, the connection times out.

In this comprehensive guide, we will break down the four major categories of connection timeouts: Web & Browser Timeouts, Infrastructure & SSH Timeouts (AWS/Azure), SSL/TLS Certificate Failures, and Database Connection Timeouts.

Scenario 1: Web & Browser Timeouts (ERR_CONNECTION_TIMED_OUT)

When users encounter ERR_CONNECTION_TIMED_OUT or DNS name resolution failure, the browser has failed to reach the web server. This is often accompanied by HTTP 5xx errors if a proxy or load balancer is involved, such as the infamous 503 Service Temporarily Unavailable AWS Application Load Balancer or Cloudflare's 522 Connection Timed Out.

Root Causes:

1. DNS Resolution Failed: The domain name cannot be resolved to an IP address.
2. Firewall or Security Group Blocking Traffic: The web server is not allowing inbound traffic on ports 80 (HTTP) or 443 (HTTPS).
3. Dead Backend Server: The ALB (Application Load Balancer) or Reverse Proxy (Nginx/HAProxy) cannot reach the target group.

Troubleshooting Steps:

• Test DNS: Run nslookup example.com or dig example.com. If you receive a "DNS request timed out" or "NXDOMAIN", the issue is at the registrar or DNS zone level.
• Check Load Balancer Targets: In AWS, navigate to your EC2 Target Groups. If instances are marked as Unhealthy, the ALB will return a 503 error. Check your application logs on the backend instances to ensure the health check endpoint (e.g., /health) is returning a 200 OK.
• Bypass the CDN: To rule out CDN issues (like Cloudflare 522), use the curl command with the -H flag to send requests directly to the origin server's IP.

Scenario 2: Infrastructure & SSH Timeouts (AWS EC2 Port 22)

One of the most common developer complaints is ssh connect to host port 22 connection timed out or ec2 connection timed out. You spin up a new Amazon EC2 instance or Azure VM, attempt to connect, and the terminal hangs indefinitely before spitting out a timeout error.

Root Causes:

1. AWS Security Groups: The most frequent offender. By default, AWS blocks all inbound traffic. You must explicitly allow TCP Port 22 from your specific IP address.
2. Network ACLs: NACLs act as a subnet-level firewall. If ephemeral ports (1024-65535) or inbound port 22 are blocked, traffic will drop.
3. Route Tables & Internet Gateways (IGW): If your EC2 instance is in a public subnet, the subnet's route table must have a route to 0.0.0.0/0 pointing to an attached Internet Gateway.
4. Local Firewalls / Corporate VPNs: Sometimes, corporate networks block outbound SSH (Port 22).

Troubleshooting Steps:

• Verify Security Groups: Go to the AWS Management Console -> EC2 -> Security Groups. Ensure there is an Inbound Rule for Port 22 where the Source is either your IP or 0.0.0.0/0 (though the latter is a security risk).
• Test Port Connectivity: Before attempting SSH, check if the port is open and responding using netcat: nc -zv <ec2-public-ip> 22. If it times out, the packet is being dropped by a firewall.
• AWS Systems Manager (SSM): If networking is broken, use AWS SSM Session Manager to access the instance via the AWS backbone without needing Port 22 open. Check the OS-level firewall (sudo ufw status or sudo iptables -L).

Scenario 3: SSL/TLS Certificate Expiration & Handshake Failures

A connection might reach the server successfully, but fail during the SSL/TLS negotiation phase. Symptoms include ssl certificate expired, curl 60 peer's certificate has expired, ssl handshake failure, or Java's javax.net.ssl.SSLHandshakeException.

When a certificate expires, browsers show massive security warnings (e.g., "Your connection is not private"), APIs refuse to connect, and services like Exchange or Kubernetes ingest fail entirely.

Root Causes:

1. Expired End-Entity Certificate: The website's main SSL certificate has passed its Not After date.
2. Expired Intermediate/Root CA: For example, the sectigo rsa domain validation secure server ca expired or Let's Encrypt DST Root CA X3 expiration. Even if your site certificate is valid, an expired chain will cause a handshake failure.
3. Protocol Mismatch (SSL Handshake Failed): The client only supports TLS 1.2, but the server only supports TLS 1.3, or there is no overlapping cipher suite.

Troubleshooting Steps:

• Check Certificate Expiry via OpenSSL: The ultimate tool for diagnosing SSL issues is OpenSSL. Run the following command to check the exact expiration date of a remote certificate: openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates
• Check the Full Chain: To see if an intermediate certificate is the problem, use: openssl s_client -showcerts -connect yourdomain.com:443
• Curl Diagnostics: Use curl -vI https://yourdomain.com. The verbose output will show exactly where the SSL handshake fails (e.g., SSL certificate verify result: certificate has expired (10)).
• Renewing Let's Encrypt: If using Let's Encrypt / Certbot, force a renewal with sudo certbot renew --force-renewal and reload your web server (sudo systemctl reload nginx).

Scenario 4: Database Connection Timeouts (MySQL, PostgreSQL, Redis)

Errors like 2003 can't connect to MySQL server on (timed out), psycopg2.OperationalError: could not connect to server: Connection timed out, or AWS RDS connection timed out plague application deployments.

Root Causes:

1. Bind Address Configurations: By default, MySQL (bind-address = 127.0.0.1) and PostgreSQL (listen_addresses = 'localhost') only listen on the loopback interface. They will drop external connection attempts.
2. Cloud Provider Firewalls: AWS RDS requires Security Group rules allowing inbound traffic on port 3306 (MySQL) or 5432 (PostgreSQL) from the IP or Security Group of the application servers.
3. Connection Pool Exhaustion: If your application opens database connections without closing them, the database reaches max_connections. New requests queue up and eventually trigger a connection request timed out (e.g., Oracle ManagedDataAccess timeout).

Troubleshooting Steps:

• Verify RDS Security Groups: Ensure the RDS Security Group allows inbound traffic from your EC2 instance's Security Group ID.
• Check DB Config: SSH into the database server (if not managed RDS) and check postgresql.conf or mysqld.cnf to ensure they are listening on 0.0.0.0 or the specific VPC IP.
• Diagnose Connection Leaks: If connections work initially but time out under load, check your ORM configuration (e.g., SQLAlchemy, Hibernate) to ensure the connection pool is appropriately sized and connections are being returned to the pool.
• Test with Telnet/NC: Run nc -zv <rds-endpoint> 5432 from the application server. If it succeeds, the network is clear, and the issue is likely authentication or pool exhaustion. If it fails, it is a firewall or routing issue.

Advanced Diagnostics: When Everything Looks Correct

What if Security Groups are wide open, DNS resolves, and certificates are valid, but you still get intermittent connection timed out errors?

1. MTU (Maximum Transmission Unit) Mismatch: If small packets (like ping) succeed, but large packets (like an SSH key exchange or large database query) hang and time out, you likely have an MTU black hole. Check Path MTU Discovery or manually lower the MTU on your interface (sudo ifconfig eth0 mtu 1400).
2. Asymmetric Routing: Traffic leaves your network via one path but attempts to return via another path (e.g., dual VPNs or complex VPC peering). Stateful firewalls will drop the returning packets because they didn't see the initial TCP SYN.
3. Resource Exhaustion: A server running at 100% CPU or out of memory may not have the resources to complete a TCP handshake. Check CloudWatch metrics or run top / htop if you have out-of-band access.

Fixing SSL Certificate Expiration Automatically

To prevent err_cert_date_invalid and ssl certificate expired issues from ever happening, automation is key.

1. Implement Certbot with auto-renewal cron jobs.
2. Use Managed Certificates (like AWS ACM - Certificate Manager) attached directly to your ALBs. ACM handles auto-renewal automatically without downtime.
3. Setup Monitoring: Use tools like Datadog, New Relic, or a simple custom Bash script (running via cron) that checks openssl expiration dates and alerts your team 30 days before expiry.