Diagnose SSL Pending on New Subdomain: Complete Troubleshooting Guide

## Introduction After creating a new subdomain on is-cool-me, such as myapp.is-pro.dev, you expect HTTPS to work immediately. Instead, you see a "pending" status and your browser flags the site as not secure. The SSL pending state means that the automated certificate authority has not yet issued or validated a certificate for your hostname. This guide walks through a systematic diagnostic approach — from DNS verification to certificate issuance timing — so you can pinpoint the exact cause and get your subdomain serving traffic over HTTPS. ## Prerequisites Before beginning diagnosis, ensure you have: - An active subdomain provisioned through the is-cool-me dashboard (for example, myapp.is-pro.dev). - Access to a terminal with `dig`, `openssl`, and `curl` installed. - Basic familiarity with DNS record types, particularly A, CNAME, and CAA records. - Access to your DNS provider's dashboard if you manage records externally. ## Why SSL shows pending after creating a subdomain When you create a subdomain on is-cool-me, the platform requests an SSL certificate from Let's Encrypt on your behalf. Let's Encrypt uses the ACME protocol to verify domain ownership before issuing a certificate. This validation requires your subdomain to resolve to the correct IP address via DNS and be reachable over port 80. If DNS has not propagated, records point to an incorrect target, or an intermediary proxy intercepts validation requests, the certificate authority cannot complete its checks and the status remains pending. The typical issuance window is one to five minutes, but external factors can extend this. ## Step-by-step diagnosis Follow these steps in order to isolate the root cause: 1. **Verify DNS resolution**: Use `dig` to confirm your subdomain resolves correctly. Run `dig +short myapp.is-pro.dev A` to check the A record. The output should match the IP address assigned by is-cool-me. 2. **Check propagation**: Run `dig @8.8.8.8 myapp.is-pro.dev +short` to query Google's public resolver, then `dig @1.1.1.1 myapp.is-pro.dev +short` for Cloudflare's resolver. If these return different results, propagation is still in progress. 3. **Inspect the certificate**: Use `openssl s_client -connect myapp.is-pro.dev:443 -servername myapp.is-pro.dev /dev/null | openssl x509 -noout -issuer -subject` to see what certificate is currently served. If the issuer is not Let's Encrypt, the certificate has not yet been provisioned. 4. **Test HTTP reachability**: Let's Encrypt validates over port 80. Run `curl -I http://myapp.is-pro.dev` to confirm the subdomain is reachable. A timeout indicates a DNS or firewall issue blocking validation traffic. 5. **Review DNS records**: Log into your DNS provider and verify there are no stale or conflicting records. A leftover CNAME record pointing to a different target will prevent the A record from functioning correctly. ## Common blockers and how to resolve them Wildcard subdomains require DNS-01 validation, which is more complex than the HTTP-01 challenge used for single subdomains. If you are using a wildcard like *.is-pro.dev, ensure your DNS provider supports API-based TXT record creation for automated validation. Cloudflare proxy mode is another frequent culprit. When the orange cloud is enabled, all traffic routes through Cloudflare's edge network. During the Let's Encrypt HTTP-01 challenge, the validation request hits Cloudflare instead of your origin server. Temporarily switching to DNS-only mode (grey cloud) allows validation traffic to reach the origin directly. Once the certificate is issued, you can re-enable proxy mode safely. Stale DNS cache can also cause issues. If your local resolver has cached an old value, Let's Encrypt will see the stale record. Wait for the TTL to expire, or flush your local DNS cache with `sudo systemd-resolve --flush-caches` on Linux or `sudo dscacheutil -flushcache` on macOS. ## Cloudflare proxy vs DNS-only impact on SSL When a record is proxied, Cloudflare terminates TLS at its edge and serves its own certificate. This works for visitors but can interfere with Let's Encrypt validation because the challenge request is handled by Cloudflare rather than reaching your origin server directly. For new subdomains where SSL is still pending, set the record to DNS-only mode until the certificate is issued. Once Let's Encrypt confirms issuance and the dashboard shows an active certificate, toggle the record back to proxied mode. This ensures validation completes without interference while still giving you Cloudflare's performance benefits in production. ## How to force SSL re-issue If the certificate is stuck in pending and you have verified DNS is correct, trigger a re-issue from the is-cool-me dashboard. Navigate to the subdomain settings and look for the SSL or certificate section. The re-issue action sends a fresh ACME challenge to Let's Encrypt. Before triggering this, confirm DNS records are correct, propagation is complete, and no proxy mode is blocking port 80 traffic. A fresh request typically resolves within one to five minutes. ## When to contact support If you have verified DNS propagation, confirmed port 80 reachability, disabled proxy mode, and still see pending after fifteen minutes, contact support. Provide the following: `dig +short myapp.is-pro.dev` output, `curl -I` output from port 80, and the `openssl s_client` certificate chain output. This information helps the team identify whether the issue is on the platform side or related to your DNS configuration. ## How to verify it works 1. Run `dig +short myapp.is-pro.dev` and confirm the IP matches your subdomain's assigned address. 2. Execute `curl -I http://myapp.is-pro.dev` and confirm you receive a 200 or 301 response. 3. Run `openssl s_client -connect myapp.is-pro.dev:443 -servername myapp.is-pro.dev /dev/null | openssl x509 -noout -issuer` and confirm the issuer is "Let's Encrypt" or "R3". 4. Open your subdomain in a browser and verify the padlock icon appears with no certificate warnings. 5. Check the is-cool-me dashboard to confirm the SSL status shows "Active". ## Conclusion and next steps Diagnosing a pending SSL certificate requires a methodical approach to DNS, network reachability, and certificate issuance timing. By following the steps in this guide, you can rule out common blockers such as DNS propagation delays, Cloudflare proxy interference, and stale cache entries. Once your certificate is active, review our SSL Certificate Setup guide for best practices on maintaining long-term HTTPS reliability across your is-cool-me subdomains. ## FAQ 1. **How long does SSL provisioning typically take after creating a subdomain?** Let's Encrypt validation and certificate issuance usually completes within one to five minutes on is-cool-me. If it takes longer, DNS propagation or a configuration issue is most likely the cause. 2. **Can Cloudflare proxy mode prevent SSL from activating?** Yes. When Cloudflare proxy is enabled, the Let's Encrypt HTTP-01 validation challenge is intercepted by Cloudflare's edge instead of reaching your origin server. Temporarily switching to DNS-only mode allows validation to complete. 3. **What DNS record type does Let's Encrypt use for validation?** For standard subdomains, Let's Encrypt uses the HTTP-01 challenge, which requires a valid A record pointing to a server that responds on port 80. Wildcard certificates require the DNS-01 challenge with a TXT record. 4. **How do I check if DNS has fully propagated?** Use `dig @8.8.8.8 myapp.is-pro.dev +short` and `dig @1.1.1.1 myapp.is-pro.dev +short`. If both resolvers return the same correct IP address, propagation is complete for those resolvers. 5. **What should I do if SSL remains pending after fifteen minutes?** Verify DNS records are correct and propagated, ensure port 80 is reachable with `curl -I`, and confirm no proxy mode is active. If all checks pass, trigger a re-issue from the dashboard or contact support with your diagnostic output.