SiteGround is having issues with renewing tickets, and don’t seem to know what’s wrong. It would be great if someone could get this fixed with them, as it’s a major pain and waste of time to have to manually renew 150+ tickets.
Any help or suggestions would be appreciated, and please let me know if more information is needed.
Do you mean TLS Session Resumption Session Tickets ? If so, they are handled by you server, and are independent of your certificate (so, not linked to let's encrypt)
Or do you mean ssl CERTIFICATES?
I'll assume you meant the latter. Can you provide more information about how you generate/renew them ? Are they wildcard certificates (containing a domain starting by * , such as "*.example.com"?
I did mean certs, and we’re not using wildcard. They’re suppose to renew automatically, but it hasn’t been working. I’ve contacted them a few times about this and they’ve kinda just shrugged their shoulders about the issue. Thank you for your time though, I just wanted to see if anyone else has had this sort of problem with SiteGround as well on here.
I’m having the same problem, except, they keep telling me it’s not the server, that it’s the Let’s Encrypt itself. Now since 2 of our sites on that server failed to install Let’s Encrypt, I went to another SiteGround account that I own. I successfully installed a Let’s Encrypt SSL on a site. Below is the same thing they’ve been telling me for 2 weeks now. My question is: If I can install Let’s Encrypt on my other SG server, wouldn’t it make sense that all servers are making the call to Let’s Encrypt in the cloud or wherever. So logically, since it is a call with the keys being passed to the Let’s Encrypt processor, wouldn’t that be a server problem, not a Let’s Encrypt problem?
"_emphasized text_The issue with thesecondomain.com is the same as the first one. Please note that this is not related to the server but the actual Let’s Encrypt tool. Unfortunately, there is not much we can do at this point. As already advised, our Developers are working on a permanent fix as we speak. I am afraid, though, that we cannot provide you with an ETA as to when this will be resolved.
This indicates that it's an issue with whatever client they happen to be using, presumably one they developed themselves given the statement that their developers are working on it. Sounds like something broke in their client.
This is what they get when they call the program – then the challenges to the domain name begin failing one after another untilt it fails. Below is the error.
Why then can I get one to install on another SG account with no problem. So is this a server problem?? I would think so.
/usr/local/letsencrypt/venv/lib/python3.6/site-packages/josepy/jwa.py:107: CryptographyDeprecationWarning: signer and verifier have been deprecated. Please use sign and verify instead
Could someone please get a SiteGround representative to participate in the forum to help debug? Lots of people from Let’s Encrypt and the community will be happy to resolve this but it would be better if it didn’t have to go back and forth through individual SiteGround customers.
I will check in with the SiteGround team as well. We have been working closely with their team to resolve any Let’s Encrypt related issues and if they have not yet already been addressed and fixed, should be shortly.
Specifically for renewals, I know you can message their support team and they can do a manual renewal on your domain while any underlying issues for autorenewal are ironed out!
I am having same issue. Siteground is telling everytime that certificate is installed. They refer to sslshopper. But in Siteground account it is not installed.
I am now 3 days busy with them but they dont want to listen. They only do quick scan to have less work. I am using multisite magento 2 so i cant put the second domain on different account.
Hi Anushka27! Were you able to get it resolved via their support channel? I know they have been very helpful with any domains still having issues.
I spoke with the Siteground team, it seems like the majority of new and renewal certificates are back up and running and they are working through any individual domains with issues to get them back to normal! Their support team is well prepped on this issue and should be able to help.
I’m still having the same issues with SiteGround. EVERY ONE OF MY CLIENTS’ let’s encrypt certs have FAILED to auto-renew. I just had to manually renew two of them yesterday and today. VERY frustrating. I’m sure the blame lies with SiteGround, but I wish it would get solved sooner rather than later…
I’m having the exact same thing with SiteGround, yesterday one of the sites I managed was down for some time during peack hours and all they said was that the certificate details were entered wrong. I literally just hit renew.
This was after they guaranteed it would auto renew. Now they’re saying that it doesn’t and I just need to do it manually each time.
As far as I know, they are still trying to streamline their certificate process. I will follow up with them and see how it’s going. Thanks so much for using Let’s Encrypt and for letting us know!
I followed up with SiteGround and they are still working on streamlining the process. This takes time but it is going well and the Let’s Encrypt implementation is up and running. Their support team should be able to help you with the renewal process as well.
Having the same problem here.
No autorenewels.
Very frustrating indeed. This has been going on for more then 3 months now. And still no solution in sight.
Whenever a certificate is going to be autorenewed. I better stay at home and monitor because more often then not it wil fail.
Thankfully Siteground support is helpfull in solving the issue quickly.
Still not amused that this keeps happening with most of my sites hosted on Siteground.
Just a quick reply to keep this thread open. We have a cloud server and have been having this issue as well and, as far as we can tell, the issue is not resolved. Certificates continue to fail on an almost daily basis. We find that the certificates that fail the most are those that use parked domains and those that use subdomains. For parked domains it’s not clear why they fail. For subdomains we believe it is because the SG solution requires both a bare domain and a www version, even if it is for a subdomain (which we don’t understand as www is a subdomain).
Indeed, manual intervention is the only solution at present. It is annoying and causes sometimes extended downtime.