Unable to issue ssl to website and mail server, shows success message but https still not opening and smtp not working

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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: emea-online.com

I ran this command: First I tried to issue ssl for website and mail server on cyberpanel ssl management (showed a success message but didn't work) Then I tried these two commands:

/root/.acme.sh/acme.sh --issue -d mail.emea-online.com -d www.mail.emea-online.com --cert-file /etc/letsencrypt/live/www.rmronsol.com/cert.pem --key-file /etc/letsencrypt/live/mail.emea-online.com/privkey.pem --fullchain-file /etc/letsencrypt/live/mail.emea-online.com/fullchain.pem -w /home/mail.emea-online.com/public_html --server letsencrypt --force --debug

/root/.acme.sh/acme.sh --issue -d emea-online.com -d www.emea-online.com --cert-file /etc/letsencrypt/live/www.rmronsol.com/cert.pem --key-file /etc/letsencrypt/live/emea-online.com/privkey.pem --fullchain-file /etc/letsencrypt/live/emea-online.com/fullchain.pem -w /home/emea-online.com/public_html --server letsencrypt --force --debug

It produced this output: On cyberpanel it showed the success message, in puTTy the first time it also showed the success message but the https was still now opening, the warning message was still there in all browsers and the smtp was still not working for emails, then I retried a few times (my bad!) and then of course it showed this:

Create new order error. Le_OrderFinalize not fou
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "Error creating new order :: too many certificates (5) already issuom,www.emea-online.com, retry after 2023-02-13T13:40:11Z: see https://letsencry
"status": 429
}

My web server is (include version): LiteSpeed (I think)

The operating system my web server runs on is (include version): CentOS 7 64bit with CyberPanel

My hosting provider, if applicable, is: Hostinger (I use VPS)

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Cyberpanel 2.3 Build: 2

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

Hi @JulienCKJM, and welcome to the LE community forum :slight_smile:

What shows?:
/root/.acme.sh/acme.sh --list

You need to stop doing what you're doing - it's just wasting certificates.
I see, you are forcibly renewing perfectly good certs:

That will never fix this kind of problem.
Please don't use the --force this way.

Why would you use acme.sh and have it put the certs in the folder certbot uses?:

3 Likes

Ok I guess this is when I must admit I'm totally new to this thing (commands and puTTy) so most of the time I look for tutorials on how to solve problems and I just found that command on one of those and tried to adapt it to my own domain as suggested in that article.
The thing is I just use front end stuff like cyberpanel and I that's where I usually issue the letsencrypt ssl certificate from ssl manager in the left menu. But only two weeks ago my website starte acting weird, I was unable to send emails from the wp mail smtp plugin (I can still send emails from Snappymail, the webmail to gmail addresses with no problem at all. My emails don't go to spams or any other issue). So I just want to know why the ssl certificate isn't showing up after being issued, and of course if the certificate is already there as suggested by that error massage saying there are already too many, why isn't it working then? Why https://emea-online.com isn't opening? Please help!

Can you use root level commands?
Like with: sudo or su

Do you see the "#" on the SSH prompt line?

2 Likes

Yeah I can, of course I don't know most of the commands or what they do, but yeah, I can copy past a command in puTTy after reading if it would be helpful and how to modify and use it.

What show?
certbot certificates
/root/.acme.sh/acme.sh --list

2 Likes

It show this:

certbot certificates
-bash: certbot: command not found
/root/.acme.sh/acme.sh --list

Main_Domain           KeyLength  SAN_Domains               CA               Created               Renew
emea-online.com       "ec-256"   www.emea-online.com       LetsEncrypt.org  2023-02-12T05:04:12Z  2023-04-12T05:04:12Z
mail.emea-online.com  "ec-256"   www.mail.emea-online.com  LetsEncrypt.org        

The date from the second line is missing.
I'll assume that it is up-to-date.

Not sure why you are specifying the path:
/etc/letsencrypt/live/
in your renewal request.
Is that where Litespeed expects to find the certs?

And why the three paths don't agree:

--cert-file      /etc/letsencrypt/live/www.rmronsol.com/cert.pem
--key-file       /etc/letsencrypt/live/emea-online.com/privkey.pem
--fullchain-file /etc/letsencrypt/live/emea-online.com/fullchain.pem

I see two distinct paths criss-crossed with one another.

2 Likes

Please let me know which command I should use instead, if that one I used is not correct. Btw, you can see I used two commands, the first one for the domain emea-online.com and the second command was for the mail server mail.emea-online.com. The one for emea-online worked perfectly (there was a success message in puTTy) the first time and the https started working nicely. But the one for the mail server also showed a success message but the emails were still not going and I was receiving an error message from the smtp plugin about a misconfiguration of openSSL on my server.
If only I knew what all that mean! But I'm trying. The version is OpenSSL 1.0.2k-fips 26 Jan 2017
And then what I did is to back up my website, re-installed my operating system and everything, thinking that the issue will go away and I will just proceed like I did the first time I created my website from scratch without ever touching any command lines in puTTy and did everything in cyberpanel only. But this same problem keeps showing up.

This is what you posted above:
[all I've done is to wrap and align it]

2 Likes

I guess it is. So is there a better way to do it please?

So after few days of struggling and looking up and down on the internet in search of the cause and the solution to this problem, I finally came across some description of what exactly was happening, it is called The SNI-Hole and how to "fix" it (actually you can't fix it), it goes away by its own after a few days of your website and domain being down. Why? Because as you try to issue a new letsencrypt SSL certificate, you are using up all your attemps (5 per week) you are able to issue the letsencrypt certificate. And as you are in that SNI hole as described, all your SSL certificates will be going to your domain but at different webservers, meaning the domain or subdomain in your server won't be getting it at all (that's what I understood at least! I'm sure it's way deeper than that, or maybe completely different than my explanation. I donno). So what I think happened is the previous certificates expired after some time (a couple of days) and then my latest attempt to issue a new SSL was finally successful, or because the other webservers weren't reachable before the one to which the certificate was intended to.
So the solution is: WAIT at least a week or two, or even a month so that the previously issued certificates expire on the other servers before attempting to issue a new letsencrypt SSL certificate if you are in an SNI-Hole. It sucks but I couldn't find any other solution.

Your explanation is without reason/logic and certainly not worth marking as a "solution".

You were issuing certs daily.


Because you kept using:

without knowing the consequence.

The problem is/was clearly elsewhere in the server and it had nothing to do with your ability to obtain a cert.

3 Likes

What is your solution then and why didn't you come up with it??

You didn't provide a solution.
Waiting and sheer luck didn't solve your problem.

You created a problem ["too many certificates (5) already issued"].
Then waited that one out.

But what made you try to forcibly renew the cert in the first place???
"that problem" hasn't been addressed; Nor has it been resolved.
It can return at any given moment.
Like on, or before, your next renewal.

I can't solve a problem that hasn't even been defined.
[Yes, I'm good ... but noone is that good]

3 Likes

Please read carefully: This was the solution to MY problem because guess what, that issue is gone as of now. Okay? I did elaborate on what I think the problem was. It happened because of the so-called SNI-Hole. Please go read what that means. If you are as good as you seem to be, you would have figured it out right away, but nope, you just told me the code is wrong but without saying how I should have wrote it properly. And it turns out actually the code WASN'T the problem after all, because I used that exact same code and it finally worked. So whatever you told me wasn't helpful at all!! If someone tries to issue an SSL certificate to a website and a subdomain but it doesn't work, the first thing he will do is to try it again. There is no way someone would guess that he shouldn't do that.
So I have a question for you though: When someone is creating a website for the first time, they issue letsencrypt SSL certificate to the main domain, the mail domain and the hostname. If something goes wrong and they have to redo the server (vps) and rebuild everything from scratch within that same week, when re-issuing the ssl to those three, there will obviously be an overshoot (6) of the number of allowed SSL to be issued (5), and there will be a risk to fall into that SNI-Hole as I understand it. So how can someone know that things will go wrong if it was his first time running into that situation?!

I had a similar problem yesterday. The acme.sh script updated the certificates for my domains as usual, reporting 'success' each time and creating new certificate/key files each time as well. But even with those cert and key files placed at the usual correct locations (where apache knows they should be), all web clients would strangely see the validation periods for those in-place, supposedly new, certs as still reflecting the issuance and expiration dates from the old or expired certs (ie, the certificates would not actually update). I tried multiple times and, like you, received the "(5) certs already issued" block message. And I have to tell you that's never happened to me before and this server has been running for many years through a multitude of hardware transitions. Of course I have only been using acme.sh for about 1 year - but until now it was working great through that year!

While I don't know what caused the acme.sh mechanism to suddenly fail me, I've just discovered that the certs will in fact properly update with a new validation period if I manually update them through gethttpsforfree.com instead of continuing to use acme.sh. It's a bit more work, but it seems to be a workaround. You'll of course have to wait until letencrypt's block is lifted, however.

I just thought I'd let you know in case you'd like to try the manual method if it happens again. Best of luck!

1 Like

Thank you for your input, I'll try to look into it so I'll somewhat be more prepared next time

1 Like

You're most welcome.

1 Like

Your math is way off.
One redo of a server takes one cert.
Added to the previous cert, that is:
1 + 1 = 2
Not 6!

3 Likes