AutoSSL Not Issuing: How to Fix SSL Certificate Errors

Every domain on Ultra Web Hosting gets a free SSL certificate through cPanel's AutoSSL, which issues and renews certificates automatically so your site loads over HTTPS with a padlock. When AutoSSL cannot issue a certificate, visitors see a "Not Secure" warning or an outright certificate error, and the fix is almost always one of a handful of causes. This guide walks through each one, how to run AutoSSL by hand, and how to confirm the certificate is actually live.

01. How AutoSSL Works on cPanel

AutoSSL is cPanel's built-in service for provisioning free SSL certificates. On Ultra Web Hosting it issues certificates from a trusted certificate authority (Let's Encrypt or the cPanel-branded Sectigo authority, depending on the server) at no cost, and it renews them automatically before they expire. You do not buy anything or paste anything in; when a domain is set up correctly, a valid certificate simply appears.

Under the hood, issuing a certificate requires proving you control the domain. This is called Domain Control Validation (DCV), and AutoSSL uses the HTTP method by default:

1. AutoSSL writes a small verification file under /.well-known/acme-challenge/ in your document root.
2. It tells the certificate authority to fetch that file at http://yourdomain.com/.well-known/acme-challenge/<token>.
3. The CA connects to whatever IP your domain's A record returns and requests that URL over plain HTTP (port 80).
4. If the file comes back with the expected contents, the CA confirms control and issues the certificate. cPanel installs it automatically.

AutoSSL runs on a schedule (typically once a day) and re-checks certificates that are within 30 days of expiry, renewing them silently. When something breaks that fetch, the whole chain stalls, and that is what produces the errors in the next section.

02. The Symptoms You Are Seeing

AutoSSL problems show up in the browser first. Depending on the exact state, you might see any of these:

• "Not Secure" in the address bar - the browser loaded the page over HTTP, or over HTTPS with an invalid certificate. The most common face of a missing AutoSSL cert.
• NET::ERR_CERT_COMMON_NAME_INVALID - a certificate is installed, but it does not cover the exact hostname you visited (for example it covers yourdomain.com but not www.yourdomain.com, or the other way around).
• NET::ERR_CERT_DATE_INVALID - the certificate expired. AutoSSL should renew before this happens, so an expired cert usually means renewal has been failing quietly for weeks.
• NET::ERR_CERT_AUTHORITY_INVALID or a self-signed warning - the browser is being served the server's default self-signed certificate because no real certificate was ever installed for the domain.
• The padlock is missing entirely - the site is reachable but AutoSSL never issued anything for it.

All of these trace back to the same root question: did AutoSSL manage to validate and install a certificate that matches the hostname visitors use? The rest of this guide is the list of reasons the answer is no, in the order they are worth checking.

03. Cause 1: The Domain Does Not Point Here Yet

This is the number one cause on new sites and domain moves. The certificate authority validates by connecting to the IP address your domain resolves to. If that IP is not your Ultra Web Hosting server, the CA either reaches the old host (and gets the wrong file, or no file) or reaches nothing at all, and validation fails.

1. Find your hosting IP: it is on your welcome email and in cPanel under the General Information panel on the right of the home screen (Shared IP Address or Dedicated IP).
2. Check what your domain actually resolves to with our DNS Lookup tool. Look up the A record for both yourdomain.com and www.yourdomain.com.
3. If the A record does not match your hosting IP, fix it: either switch your registrar to our nameservers (ns1.ultranameservers.com, ns2.ultranameservers.com, ns3.ultranameservers.com) or, if your DNS is hosted elsewhere, update the A record there to your hosting IP.
4. Wait for the change to propagate, then re-run AutoSSL (Section 08).

04. Cause 2: An .htaccess Rule Blocks Validation

AutoSSL needs to serve the validation file at http://yourdomain.com/.well-known/acme-challenge/<token> over plain HTTP. Anything in .htaccess that intercepts that request before Apache can serve the file will break validation. Two culprits account for almost all of these failures.

Force-HTTPS redirects

A blanket rule that rewrites every HTTP request to HTTPS will also redirect the CA's plain-HTTP validation request, so the CA never gets the file. The fix is to exclude the ACME path from the redirect:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

The second RewriteCond is the important line: it tells the redirect to leave /.well-known/acme-challenge/ requests alone so AutoSSL can validate.

Hotlink protection and access rules

Hotlink protection, IP deny rules, and some security plugins can also block the ACME path. If you cannot spot the offending rule, temporarily rename .htaccess to .htaccess.bak, run AutoSSL, then restore it:

1. Open File Manager in cPanel and enable Show Hidden Files (dotfiles) from Settings.
2. In your document root (usually public_html), rename .htaccess to .htaccess.bak.
3. Run AutoSSL from SSL/TLS Status (Section 08) and confirm it issues.
4. Rename the file back to .htaccess, then add the ACME exclusion above so the redirect survives future renewals.

05. Cause 3: A CAA Record Disallows the CA

A CAA (Certification Authority Authorization) DNS record lets you list which certificate authorities are allowed to issue certificates for your domain. It is a good security control, but a CAA record that does not include the authority AutoSSL uses will silently block issuance. The AutoSSL log reports this as a CAA restriction.

1. Check whether your domain has a CAA record using our DNS Lookup tool (select the CAA type). Many domains have none, in which case any CA may issue and this is not your problem.
2. If a CAA record exists, confirm it authorizes the AutoSSL authority. For Let's Encrypt the value is letsencrypt.org; for the cPanel/Sectigo authority it is sectigo.com. Not sure which your server uses? Open a ticket and we will tell you.
3. To fix it, edit or add CAA records in cPanel Zone Editor so both authorities are allowed. Two issue records covers the common case:

yourdomain.com.  CAA  0 issue "letsencrypt.org"
yourdomain.com.  CAA  0 issue "sectigo.com"

If your DNS is hosted at Cloudflare or another provider rather than on our nameservers, make the same CAA change there instead.

06. Cause 4: The Domain Is Not Fully Set Up

AutoSSL can only issue for domains cPanel actually knows about and can serve. If a domain or subdomain is half-configured, AutoSSL either skips it or fails validation because there is no document root to write the challenge file into.

• Addon domains with a wrong or missing document root - if an addon domain's document root does not exist or points to an empty folder, the challenge file has nowhere to go. Check Domains in cPanel and confirm the document root path is correct and the folder exists.
• Subdomains that were never created in cPanel - a subdomain that resolves in DNS but was never added under Domains (or the old Subdomains tool) has no vhost, so AutoSSL will not cover it. Create it in cPanel first.
• A missing or broken DNS zone - if the domain has no zone on our nameservers (for example it was added but the zone did not build), validation has nothing to resolve against. Check Zone Editor lists the domain.
• Domains excluded from AutoSSL - a domain can be manually excluded. In SSL/TLS Status, make sure the domain is not showing an "Excluded from AutoSSL" flag; if it is, include it again.

07. Cause 5: A Conflicting Manual Certificate

AutoSSL manages the certificates it issues, but it will not overwrite a certificate you installed by hand or that a third party pushed. If a manually installed certificate is present for the domain, AutoSSL steps back and leaves it alone, even if that certificate is expired, self-signed, or does not cover all your hostnames.

1. Open SSL/TLS in cPanel, then Manage SSL sites. This lists every certificate currently installed and which domain each covers.
2. Look for a certificate on the affected domain that AutoSSL did not issue (it will not be labelled as an AutoSSL/cPanel certificate, or it may be expired or self-signed).
3. If that manual certificate is the problem, uninstall it from this screen. With it gone, AutoSSL is free to issue and install its own.
4. Return to SSL/TLS Status and run AutoSSL (Section 08). It should now provision a fresh certificate for the domain.

08. Run AutoSSL by Hand from cPanel

AutoSSL runs on its own daily, but after you fix one of the causes above you do not have to wait for the next scheduled run. You can trigger it immediately.

1. Log in to cPanel and open SSL/TLS Status (under the Security section).
2. You will see every domain and subdomain on the account with its current certificate status. Domains without a valid certificate show a warning icon.
3. Tick the domains you want to reissue, or click Run AutoSSL to check them all at once.
4. Watch the status update. Issuance usually completes in under a minute if validation succeeds; the icon turns green when a valid AutoSSL certificate is installed.
5. If it fails, click into the domain to read the reason. The message tells you which DCV step failed, which points you back to the matching cause above.

09. Force a Re-Issue or Remove a Stale Cert

Sometimes a certificate exists but is wrong: it covers the bare domain but not www, or it went stale after you added a subdomain, and running AutoSSL does not seem to replace it. Forcing a clean re-issue clears this up.

1. In SSL/TLS Status, find the domain and use the Run AutoSSL option scoped to just that domain. AutoSSL reissues to cover any newly added hostnames.
2. If the stale certificate will not budge, go to SSL/TLS > Manage SSL sites, and uninstall the certificate on that domain. This removes the stale cert cleanly.
3. Return to SSL/TLS Status and run AutoSSL again. With no certificate installed, it issues a fresh one covering all current hostnames for the domain.
4. Confirm both yourdomain.com and www.yourdomain.com now show a valid certificate.

10. Verify the Certificate and When to Ask Us

Once AutoSSL reports success, confirm the certificate is genuinely live and valid, not just installed.

1. Check in the browser: load https://yourdomain.com and https://www.yourdomain.com. Click the padlock and confirm the certificate is valid, not expired, and covers the hostname you visited.
2. Check with our tools: run the domain through our SSL and DNS tools to see the issuing authority, the expiry date, and the covered hostnames from outside your browser cache.
3. Confirm renewal is healthy: back in SSL/TLS Status, a green icon with a future expiry date means AutoSSL will renew it automatically. You do not need to do anything further.
4. Hard-refresh if the browser still shows the old error: certificate and page caches can lag. Try a private window or a different device to rule out local caching.

If you have worked through all five causes and AutoSSL still will not issue, there may be a server-side rate limit (certificate authorities cap how many certificates you can request in a window) or an account-level configuration issue we need to look at. That is our job, not yours.

Quick Recap: Fixing AutoSSL in Five Checks

If you only do a few things from this guide, do these:

1. Confirm the domain resolves to your hosting IP - check the A record with our DNS Lookup tool; the CA cannot validate a domain that points elsewhere.
2. Exclude the ACME path from any force-HTTPS redirect - keep /.well-known/acme-challenge/ reachable over plain HTTP in .htaccess.
3. Check for a blocking CAA record - allow letsencrypt.org and sectigo.com, or remove the CAA record entirely.
4. Make sure the domain is fully set up - correct document root, the subdomain created in cPanel, and a live DNS zone.
5. Remove any conflicting manual certificate, then Run AutoSSL from SSL/TLS Status and verify the padlock in your browser.

Last updated July 2026 · Browse all SSL & HTTPS articles