Continuous 'Unable to set certificate name" on Plesk / Centos server

We have a Plesk 12.5 dedicated OVH server running Centos 7. (

The cron is trying to renew the certificates and getting an error.

[2017-06-05 00:00:05] ERR [extension/letsencrypt] Cannot renew certificate on domain with error: Install certificate failure: Unable to set certificate name :

That is all the error says. And NOTHING has been changed in 18 months - suddenly, we start seeing errors.

I see hundreds of messages on the boards about renewal errors, which MUST be affecting the Let’s Encrypt service. There is a definite need I see for someone to simplify and bullet proof (a bit) the renewal process - and explain how the “limits” actually work better. I am sure we would all appreciate that. :slight_smile:

Sid B.

Hi @mydragonsoftware,

The main thing that changed on the Let’s Encrypt side recently that’s been causing errors with Plesk installations is that we now use IPv6 by default when verifying challenges. Most failures have involved people who have (and are advertising in DNS) an IPv6 address yet don’t have their web servers responding correctly for that IPv6 address.

If that’s not the case, I’m afraid you should try the Plesk forums, because no Plesk developers have been participating in this forum, and we don’t really have the ability to debug problems with their plugin.

Our site does NOT use an IPV6 address. Plesk does not provide the DNS.
Plesk is how we setup the certificates to begin with, without any errors or
issues. There hve been NO changes to our Pleak or server configuration. I
don’t think you can blame this on Plesk.

All our traffic is routed through the Cloudflare CDN - as are over a
million other sites/servers. Cloudflare IS our DNS service as well, and
does not advertise an IPV6 for that site, so I do not know what is
happening on the Let’s Encrypt side, but things are not working.

Sid B.

Hi @mydragonsoftware,

The error “Install certificate failure: Unable to set certificate name” was generated by Plesk and nobody here is prepared to support Plesk, as nobody connected with the Plesk developers has been participating in this forum. I suggest asking on one of

Also, it appears that two certificates were successfully issued for and earlier today, but they are not visible on your site (which appears to be using a Comodo certificate instead), so Plesk may not have managed to install them.

But this confirms that Let's Encrypt is still willing and able to issue certificates for your site, and in fact has done so just today.

Also, your site does have two IPv6 addresses, which are 2400:cb00:2048:1::681b:605d and 2400:cb00:2048:1::681b:615d.

$ dig aaaa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49483
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags:; udp: 512

;; ANSWER SECTION: 30 IN AAAA 2400:cb00:2048:1::681b:605d 30 IN AAAA 2400:cb00:2048:1::681b:615d

Plesk did not generate the error - it simply reported the error generated
by Let’s Encrypt and the renew.php script.

Evey time someone reports an error on a system running Plesk you guys blame
Plesk. WE DID SSK the Plesk forum - the error was not generated by Plesk,
just reported.

Sid B.

Hi @mydragonsoftware,

I doubt that, the error is produced by the letsencrypt-plugin made by and for Plesk. They called it letsencrypt-plugin but that is the only coincidence with Let's Encrypt.

I've performed a quick search and the problem is related to how this plugin manages and installs the certificates. Did you take a look to this post?

Seems a bug in Plesk version 12.5 that should be fixed in update 25, I think it is worth to take a look to the above link just in case is the same issue you are having.

Maybe because Let's Encrypt, the only thing it does, is issue a certificate, the Plesk plugin should manage where the challenges are put, where the certs should be installed and how to configure the Plesk environment.

Good luck,

The comodo certificate and the IPV6 address you are seeing are not actually
on our server. They are on the Cloudflare CDN side. ALL our traffic that is
routed via DNS (as opposed to physical IP) is routed through CloudFlare,
who is also providing our DNS service. The Let’s Envrypt servers / tools
would appear to be having a problem with them or that configuration. We do
plan to mention all this to Cloudflare support, just to ensure their
network is not producing the issue.

And yes, the certificate renewal was repeated by Plesk, and appears to be
successful - all the more reason to suspect that Plesk is Not ‘causing’ the
issue. I also suspect, that until the entire net is using only IPV6
addressing, problems like this will plague us all.

Sid B.

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