Error 429 due to multiple host changes

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: Install Lets Encrypt Certificate (Siteground)

It produced this output: "" indicated an ACME error: 429 Too Many Requests (429 urn:ietf:params:acme:error:rateLimited (The request exceeds a rate limit) (Error creating new order :: too many failed authorizations recently: see Rate Limits - Let's Encrypt)).

My web server is (include version): Siteground Singapore

The operating system my web server runs on is (include version): Linux?

My hosting provider, if applicable, is: Siteground

I can login to a root shell on my machine (yes or no, or I don't know): No

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Siteground Site Tools

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Hi Guys,
I'm hoping you can help. My story - I have a new client (domain = and will be re-building their website for them. Firstly, I migrated a copy of their website to my Fast Comet VPS Host Account, tested it, re-directed the A-Record to point to the new host IP address, then following propagation I successfully added a Let's Encrypt SSL Certificate to the domain via Cpanel.
I then created a sub-domain ( to use as a staging platform to re-build the new website, however I realised that in order for the sub-domain to be secure I would need to add a Lets Encrypt SSL Wildcard to the primary domain.

After attempting to add the wildcard and getting a failed result, I discovered that I would need to have the Name Servers pointing to my hosting account in order to add the wildcard SSL, not just have the A-Record pointed.

So I was left with 2 choices: 1. copy all of the DNS records from the existing Name Server host to the FastComet host, then point the nameservers, OR 2. move the website to my Siteground Host with the staging facility and re-point the A record, then again install the Lets Encrypt Certificate on the Siteground Host after propagation, then simply created the staging site.

I went with Option 2 however with having requested a wild card more than once on the FastComet Host, then removing and re-adding the standard SSL certificate on the FastComet host, then requesting the certificate on the Siteground Host (all within a couple of hours), I'm guessing that is what caused the 429 error.

I have now re-directed the A Record back to the FastComet host as there is an active SSL Certificate there, however I cannot secure the staging site on the subdomain. What do you suggest I do to get past this point?

Quick question, when you get a 429, do you need to wait 1 week to re-issue a certificate to the affected domain? It would greatly appreciated if someone could confirm this or correct me. Thanks guys :slight_smile:

The good news about your 429 error is that it will be gone after an hour. The rate limit you've hit is related to the number of failed authorization attempts you've made.

This is not the long rate limit, related to creating too many certificates.

Why? Why can't you get a regular certificate for the subdomain only?


Hi _az, thanks for the response, that's awesome news!
I tried to put a regular certificate on the subdomain and it failed so I assumed I need a wild card on the primary domain instead... I only have an A record pointed from the Name Server to the Website host for the primary domain...

1 Like

From your story, I gather that will be hosted on a different server - the Fastcomet hosting service?

If so, that's where you need to create the certificate for At Fastcomet, not on Siteground.

So in your DNS control panel (with Crazy Domains), you would:

  • Have an A record for → the Siteground IP address
  • Have an A record for → the Siteground IP address
  • Have an A record for → the Fastcomet IP address

That way:

  • Siteground will be able to continue renewing your existing certificate for
  • Fastcomet will be able to create a certificate for
  • Both domains will be secured: two certificates on two different hosting services, for the respective domains hosted on each service.

Let me know if I misunderstood.

Wildcards are definitely a pain in the ass. You have correctly identified that changing your nameservers would be required to make it work. IMO, this is unnecessary in your case, and you can simplify things with the above approach.


Thanks_Az, that's very helpful.
I was initially going to have both the primary domain (website) and also the staging subdomain (website) on the fastcomet account, however after having the wildcard issue, I decided to move the primary to my Siteground account where there is no need for me to create the subdomain as I just use Siteground's built in staging facility for the staging site. I can now continue down that path as I should be able to re-issue the regular SSL certificate to the primary domain and then just create the staging site...

Of course I will have to re-direct the A record once again and give it some time to propagate first :slight_smile:

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