Auto renewal not working when using stackpath with origin host

I have many sites hosted on Cloudways. all of them are set for auto-renewal SSL certificate.

I also am using Stackpath WAF for all my sites. This is similar to cloudflare, to block most malware to the origin domain.

Previously, the certificate would auto-renew automatically without any problem. Lately, for many of my sites, the auto-renew is not happening and then the site appears to be down.

My solution is to manually temporarily change the DNS settings in my DNS manager to bypass Stackpath and go to the origin site and THEN revoke the old certificate and then create a new certificate and then re-activate my Stackpath settings in the DNS manager.

I have more than 100 sites and I'm hoping that you can return the settings to how it was before.... where the auto-renew would work EVEN WHEN STACKPATH WAS ENGAGED.

Does anyone know anything about this?

Thank you,

Howard Richman

We can try to help you.

What ACME client (eg, certbot) and challenge type are you using? HTTP, DNS, ALPN?

What errors do you get when you try to renew with Stackpath enabled?


Thank you, When stackpath is enabled, it is not possible to CREATE or RENEW the certificate. I've learned in creating a new site initially I must create the SSL certificate first and THEN engage stackpath because that changes the A record and the CNAME to stackpath, which then routes to my origin domain.

When I attempt to create or renew with stackpath enabled it doesn't create an error. It just doesn't create the certificate.

Some of my sites are going through the Stackpath DNS manager and some are going through bunny. I don't know what ACME client means. So sorry.
but thank you for trying to help me.

1 Like

Can you give an example of a domain name that is failing to renew?

It looks like Stackpath is or has a CDN. Special consideration is needed with CDN when using the HTTP Challenge to ensure the http request from the Let's Encrypt Servers pass thru to the origin server.

CDN's generally like to do things like redirect HTTP requests and sometimes validate formats or sources which disrupt the flows needed for validation.

I don't know about Stackpath specifically, but these are common issues when people start using CDN's like Cloudflare and CloudFront.

Sometimes it is easier to use a DNS Challenge behind a CDN. Although HTTP Challenges are possible (with care). Cloudflare even offers something it calls an "Origin CA Cert" which allows HTTPS comms to the origin without needing a cert from another CA (like Let's Encrypt).


Sounds like you may need to ask StachPath what they are doing with those ACME challenge requests.

Maybe they block them like Palo Alto does - LOL


Thank you, MikeMcQ. I think the issue is with Stackpath from what I'm learning. I have a ticket in with them and I hope to find out what adjustments I can make to make this work. Your tips are helpful.


rubs :crystal_ball:


It says StackPath also uses LE certs ...
and they are consuming all such ACME requests.

[the ball has been known to be both right and wrong - this is clearly one more of those two choices - LOL]


ok. Here is my update on this. Instead of having TWO SSL certificates, one for the host and one for the firewall (stackpath). I learned from Stackpath that I only need to use the Let's Encrypt certificate via Stackpath and to revoke the one on my host. Then They suggested that change this setting....
settings >origin > pull protocol > http only.
the reason for this is because the actual origin site is NOT secure but will be then using the SSL certificate from Stackpath (I'm sure cloudflare and others would function the same.)

So to the user, the domain would appear secure.

This also solves the original issue that the origin host could not auto-update the certificate.

Thank you all for your input on this.

1 Like

Thanks for sharing the confirmation that Stackpath are not competent. I am both mortified and disappointed by your comfort in not only deploying an insecure site, but also by your cavalier willingness to actively deceive your visitors by giving them the false impression that their traffic is secure while transmit it across the open internet in plaintext.

It's the twenty twenties. While there has never been a valid excuse for such behavior, it has never been easier to avoid such a malicious configuration than it is now.


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