My Web Host is Totally Lying to Me About "Propagate," Right?

I think my web host may be feeding me a lot baloney about this:

  1. Created addon domains, cPanel shared hosting.
  2. Made sure DNS was properly pointed first, verified at
  3. No redirects or .htaccess files.
  4. Browser errors, not secured; verified no SSL at
  5. HTML “GET” request does work at

It’s been around 10 hours with no Let’s Encrypt, though it was supposed to be applied. One addon I added hours after the first batch already has it.

Web host claims this:

The Domains MUST fully propagate at LetsEncrypts servers first before the LetsEncrypt cron on our system will add the certificate. They will pull the from their servers, if this reports a 404 error, no certioficate will be generated. Please note that full propagation can and sometimes will take up to 24 hours. Regardless of the cron running if the domain has not fully propagated at the LetsEncrypt servers then no cer will be issued until the .well-known directory is readable so it can pull its acme-challenge encoded file which the cron places in that directory.

Please let us know the domains you are still having issues with so we can check the error logs generated at LetsEncrypt. Hopefully the above explanation explains why the domains just dont GET a certificate after being added.

Okay, so…

That’s total nonsense, right?

And how do I catch them if they are lying? For example, how do I “check the error logs generated at LetsEncrypt” which they would claim to exist?

I’m not an expert, so please try to explain to someone who doesn’t know as much as you do most likely.

Also, I did see this from 2016 which would seem to confirm they must be lying, but I’m still not sure: I have to wait until DNS propagate for issuing certificate?.


As far as I’m aware, the information you found is correct: Let’s Encrypt queries your authoritative name servers directly, so it doesn’t have to wait for DNS propagation. That doesn’t necessarily mean your host is lying though; they may simply be misinformed. EDIT: see below

You can check your DNS at which uses a configuration very similar to what Let’s Encrypt uses; if that test can find your domain it’s a pretty safe bet that Let’s Encrypt can, too.


It’s not total nonsense. Particularly for newly registered domains, it can take a while for the name to be publicly available everywhere on the Internet, and while that’s going on, the domain may be visible in some places and not in others.

However, their comment about propagation is just a best guess. As they said in their message, they need to know which domains are affected so they can check their logs and see what’s wrong. You should send them that info and they may be able to help more.


Specifically relating to cPanel, I will add that the certificate issuance will often run on a long-ish schedule, if your site missed the window/failed a couple of times, there may be an extended delay.

The host may be able to forcefully issue the certificate from the admin interface.


There are two concepts that often get conflated: caching and propagation. Because Let’s Encrypt queries authoritative name servers, caching is not an issue. However, propagation may still be. Specifically, if you newly register, the authoritative nameservers for com have to be updated with the new delegation. Those nameservers tend to be a little slow to propagate because of the sheer volume of updates they have to deal with.


You learn something every day. Especially here :slight_smile:


Thanks for these replies everyone, they are very helpful and help with the learning process for this. This is part of my first long awaited venture into SSL and Let’s Encrypt and I feel I’ve been getting the hang of it pretty nicely but still have a way to go.

The newest domain was registered in early December, so I don’t believe that could be an issue.

They gave me some of the supposed log info, like the following. First a bunch of these for affected addon domains:

8:xx:xx PM The website “”, owned by “username”, has a faulty SSL certificate (OPENSSL_VERIFY:0:18:DEPTH_ZERO_SELF_SIGNED_CERT NOT_ALL_DOMAINS). AutoSSL will attempt to replace this certificate.

Next, this:

Heres the full error logs for the account from LetsEncrypt. [I.e., the rep was referring to the above.]

8:xx:xx PM WARN (XID wkzbf3) The ACME function “” indicated an error: “Error creating new cert :: too many certificates already issued for: see (The request exceeds a rate limit)” (429, “Too Many Requests”, urn:acme:error:rateLimited). at bin/ line 679.

You have exceeded your rate limits for LetsEncrypt. Please check this out and see why the limits were set. You will have the certificates issues eventually however we are not holding it up, LetsEncrypt are.

I added bold to that last sentence, because…

That last sentence about “eventually” is nonsense, yes?

Here is my current understanding:

When you are using shared cPanel hosting with a “main domain” to which you add “addon domains,” there is a fixed “rate limit” of the total # of LE certificates that can be installed which pertain in any way to that main domain. Ergo, any certificate issued for and the “www.exampleaddon…” version is considered to be a certificate for main domain, and will fail if you have reached the total # limit for

Next, my understanding from reading the rate limits page is that there is no limit on the number of distinct domains for which the LE certs can be issued, hence you still have the option to LE secure and every permutation of it which does not include main domain if the addon itself does not have too many subdomains. Not only is that my understanding of the LE rate limits page, but that has also been my experience (though unfortunately not with this host).

The problem with the host I am dealing with re this issue is that they do not allow shared hosting customers to have access to the means of manually securing the addons after you have reached the rate limit for the main domain, so you have to wait for their cron job to secure them. But their cron job or script which supposedly runs every 20 minutes has failed to do that.

So it seems both that the support rep is contradicting what has already been indicated about the rate limit, and is just schmoozing me with baloney about how the certificates will be applied at some nebulous future “eventually.”

My understanding is that the rate limit in this case is a fixed number, only unless you apply for and are granted an increase, and that for “plan B” in which you proceed to secure the addons as distinct domains, the only rate limit if you do not have many subdomains for each which you would be concerned about would be the 10 certs per 3 hours per IP.

Some of the support staff have also said what I think is nonsense about how Let’s Encrypt functionality is not native to cPanel and therefore other hosts who allow customers to have more control to “Issue” and install Let’s Encrypt in cases like this have made some special proprietary plugin or something. Sure, strictly speaking yes, I don’t doubt Let’s Encrypt is “not purely native” to cPanel, but so what. In my observation that appears to be partially false bamboozling. It seems to me that cPanel has been working with Let’s Encrypt and there is standard functionality which has been created to be plugged into or used with cPanel, even if each provider is able to do some degree of customization. For example, it seems the “Issue” feature is a standard item, not something each host dreamed up on its own with differing code. And I seriously doubt everyone running and talking about “AutoSSL” simply dreamed different versions of that by the same name up on their own.

So my understanding is that it cannot be true that the addons will “eventually” be covered, assuming anyone wants to live and operate that way, and that the support rep must be wrong about that.

My understanding is that this particular host could easily allow this standard “Issue” functionality to shared hosting customers, could also allow them to run AutoSSL manually while excluding subdomains that fall under the rate limit on the main hosting domain, just as numerous other hosts do this or that or both, but that they are simply trying to push people into more expensive plans before people are ready or are even close to needing such more expensive plans.

And yes, if any of my observations and understanding of what I have learned and experienced so far is off in any way, do please let me know. My experience so far is certainly consistent with what I’ve written, however.

This is not quite right because if renewals happen after new issuances, the renewals will not be blocked by the rate limit. Also, renewals do not ordinarily happen every rate-limit period (they're recommended to happen only once every 60 days, which is a lot more than the 7-day window for the rate limits).

There is a nice tool to check rate limit status from the copy of the Certificate Transparency logs hosted on

Some people who were facing rate limits on a large shared domain have used this tool to schedule their issuance requests for the exact right moment when the rate limit will expire. Because of the rule that I mentioned above, this will not necessarily break other users' renewals (though it won't scale well if there are lots of people using lectl at the same time and racing each other for priority, as with airline check-in sites where many airline passangers may be using a script to all try to check in during the first second that check-ins are allowed in order to get boarding priority).

You're right that

  • cPanel's implementation and many other providers' implementations aren't a super-great match for LE's rate limit model when you have multiple customers' domains being issued under the same registered domain name.

  • This is a frustrating situation for end users.

However, I also don't want to say that the provider is lying, but may simply not understand some of the subtleties about the rate limit rules or not know how to communicate their impact to customers very well. I would say that to better align with LE's rate limit model, it would be good to register your own domain for your exclusive use or be sure that all shared domains used by multiple customers are on the Public Suffix List or have applied for a Let's Encrypt rate limit exemption.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.