[WordPress] Let's Encrypt renewal timeout

AsiaViking commented 2 days ago

Platform

Google Cloud Platform

bndiagnostic ID know more about bndiagnostic ID

5e02c49b-857a-8c35-303a-fbbbc396abdd

bndiagnostic output

✓ Processes: No issues found
? Resources: Found possible issues
? Connectivity: Found possible issues
✓ Mariadb: No issues found
✓ Php: No issues found
? Apache: Found possible issues
✓ Wordpress: No issues found

bndiagnostic was not useful. Could you please tell us why?

It did not identify the issue.

Describe your issue as much as you can

I'm unable to renew or obtain a new Let's Encrypt SSL certificate for my WordPress website hosted on a Google Cloud instance with Bitnami. The lego client consistently fails with "Timeout during connect" errors, even after confirming correct DNS settings, firewall rules, and network connectivity.

The certificate was working correctly until it expired about 24 hours ago. It was also set to automatically renew, and has done so successfully in the past without any issues.

The site is running (not secure).

WordPress version: 6.2.0-14 packaged by Bitnami Google Cloud instance with default network settings

Troubleshooting Steps Taken: Firewall Rules: Confirmed that both ingress and egress firewall rules on the Google Cloud instance allow traffic on port 443. Local Firewalls: Verified that no local firewalls (iptables, ufw) are blocking outgoing connections. Connectivity Test: Successfully connected to the Let's Encrypt server using openssl s_client. DNS Verification: Confirmed that the domain name correctly resolves to the public IP address of the Google Cloud instance. Apache Restart: Temporarily stopped Apache to avoid port conflicts during the TLS-ALPN-01 challenge. --http Challenge: Tried using the --http challenge as an alternative, but still encountered timeout errors.

The main error message is: acme: error: 400 :: urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem)

This error occurs for both --tls and --http challenges, suggesting a persistent connectivity issue that prevents the lego client from reaching the domain for validation.

I would appreciate any insights or suggestions from the community on how to resolve this persistent SSL certificate renewal issue. Has anyone else encountered similar problems with lego, Bitnami, or Google Cloud? Are there any specific configurations or troubleshooting steps I might have overlooked?

jotamartos commented 1 day ago

The main error message is: acme: error: 400 :: urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem)

This error occurs for both --tls and --http challenges, suggesting a persistent connectivity issue that prevents the lego client from reaching the domain for validation.

That's a connectivity error when trying to renew the cert. I can't connect to your domain/IP right now, please ensure the services are up and running when trying to renew the cert.

AsiaViking commented 1 day ago

Thx for getting back to me. A bit of panic here. Tried to stop/start the instance as apache did not start again.

sudo /opt/bitnami/ctlscript.sh start Starting services.. Job for bitnami.service failed because the control process exited with error code. See "systemctl status bitnami.service" and "journalctl -xe" for details.

UPDATE: Apache didn't start, but managed to get it back again (SSLCertificateFile and SSLCertificateKeyFile referred to /opt/bitnami/apache/conf/ and not letsencrypt).

Still the same problems with getting a certificate.

AsiaViking commented 5 hours ago

Current Status

**- Apache serves .well-known files correctly for manual tests.

LEGO fails to create challenge files during the process.
No .well-known/acme-challenge requests from Let’s Encrypt are observed in logs.**

1. Verify DNS and Domain Configuration

Checked DNS records for the domains and subdomains.
Confirmed DNS resolves correctly to the server’s IP. 2. Check .well-known Directory Accessibility
Created test files in the .well-known/acme-challenge/ directory.
Tested file accessibility using HTTP requests.

3. Inspect Apache Configuration

Reviewed configuration files (bitnami.conf, httpd-prefix.conf, httpd-app.conf) for .well-known aliases and directives.
Verified that .well-known aliases and directory permissions were properly configured.

4. Verify Permissions for .well-known

Ensured proper ownership and permissions for the .well-known directory.
Confirmed no permission-related errors.

5. Test Apache Logs

Monitored Apache logs (access_log and error_log) during the LEGO command execution.
Confirmed there were no requests to .well-known/acme-challenge during the process.

6. Run LEGO Command

Executed the LEGO command with HTTP challenge and webroot options to generate certificates.
Observed failures with unauthorized errors for specific domains.

7. Debug LEGO Behavior

Monitored the .well-known/acme-challenge/ directory for challenge files during the LEGO command.
Confirmed no files were created during the process.

8. Test Manual Challenge File

Manually placed test files in the .well-known/acme-challenge/ directory.
Confirmed files were accessible via HTTP requests, validating Apache’s functionality.

9. Check Apache Error and Access Logs

Monitored logs to confirm Let’s Encrypt requests during the LEGO command.
No .well-known/acme-challenge requests were observed, suggesting Let’s Encrypt was not reaching the server.

10. Retry LEGO with Staging Server

Attempted to use Let’s Encrypt’s staging server to rule out production-related rate-limiting issues.
Observed similar errors and failures.

11. Verify Connectivity to Let’s Encrypt

Tested connectivity to Let’s Encrypt servers to ensure no network issues.
Confirmed ports 80 and 443 were open, and connections to Let’s Encrypt succeeded.

12. Firewall and Port Configuration

Verified that no firewall rules were blocking traffic on ports 80 or 443.
Confirmed firewall settings were correctly configured.

bitnami / vms