Let's Encrypt 2.0.1: Unable to set certificate name

[Vega80]

TITLE:

Let's Encrypt 2.0.1: Unable to set certificate name​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk 17.0.17 U21, Debian 8.7, 64 Bit​

PROBLEM DESCRIPTION:

When trying to request a new certificate or recreate a certificate the LE extension throws an error:
"Error: Let's Encrypt SSL certificate installation failed: Install certificate failure: Unable to set certificate name :"​

STEPS TO REPRODUCE:

Unknown. I made my first tests with Let's Encrypt and installed and removed some certificates on my testdomain and corresponding subdomains. After some successfull operations the error showed up.
Maybe it is important to mention that I installed the extension and the first certificate already under Plesk 12.5 U62. A day later i upgraded to Onyx and continued the tests, which led to the error.​

ACTUAL RESULT:

It is not possible to request certificates​

EXPECTED RESULT:

No error and successfully installed certificate​

ANY ADDITIONAL INFORMATION:

It seems that there are more people affected. Maybe this is more helpful:
Issue - Unable to set certificate name​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[IgorG]

It seems that there are more people affected. Maybe this is more helpful:
Issue - Unable to set certificate name

As far as I see in this thread this issue was solved? Do you still think that it may be Plesk extension bug?

 

[Vega80]

Yes I think so. Respectively I can't tell you whether the root cause is the LE extension or a corresponding part of Plesk. But obviously it is possible to get a permanent error state, that can only be solved with some undocumented manual actions.

The user in the linked thread found a good workaround, but why was it neccessary to rename and recreate the certificate at all? I didn't had the idea just to test renaming the existing certificates and deleted the LE certificate entries in the plesk database, to get the extension working again. (And because I deleted one entry to many, I messed up with other things, but that is solved and is not important here)

And more threads with this error message:
Resolved - Error with SSL certificates
Issue - LetsEncrypt failed

 

[trialotto]

@Vega80

I already posted a reaction to one of your other posts and referred you to Resolved - Solutions for recent Let´s Encrypt issues

However, I see here that you did some digging, did some testing and also made some (minor) mistakes.

You can use the before mentioned thread to simply restore the Let´s Encrypt related database entries, which should be recommended in your case.

The problems you were facing are not directly related to the Plesk Let´s Encrypt extension, but are very likely to be caused by something else.

Finally, note that it is highly recommended to upgrade the Plesk Let´s Encrypt extension to the latest version: just upgrade it via the Extensions Catalog.

Regards.....

 

[trialotto]

As far as I see in this thread this issue was solved? Do you still think that it may be Plesk extension bug?

@IgorG

To be honest, it is very (very) unlikely that it is a bug in the Let´s Encrypt extension, which extension did not change drastically in the area of database related processes.

In some test cases, we found out that migration and/or similar sources of database related problems are the root cause of the problem.

For example, migration of Plesk 12.5.30 to Plesk Onyx 17.0.17 can be problematic for subdomains that have been assigned letsencrypt certificates by older versions of the Let´s Encrypt Plesk extension.

I can safely state that database corruption is the root cause of the problem AND that it is not a bug in the most recent version(s) of the Let´s Encrypt Plesk extensions.

Regards.......

 

[Vega80]

@trialotto

Thank you for the clarification and the detailed solution.
So it is very likely that the root cause was a migration issue. I think this is something that should be improved, but from my point of view my request is solved.

 

[trialotto]

@Vega80 (and @IgorG)

Just to be clear, it is not the migration process itself that triggers something.

When an Let's Encrypt issue occurs after migration, it is mostly due to some erroneous setup in the source server.

I can confirm that to a large degree of certainty, since your remark made me question how the migration processes are interacting with Let´s Encrypt.

We did a test, in which we messed up certificates on the source server: we assigned an identical Let´s Encrypt certificate to both <domain>.<tld> and <sub>.<domain>.<tld>.

In essence, this results in having the main domain having the same id as the id on the subdomain.

The main domain will be migrated properly, as one would expect, since the main domain is the first line in the table with id <x>.

The subdomain would not migrate properly, as could also be expected, since the id <x> already existed.

In conclusion, both the migration process and the Let´s Encrypt related processes on the destination server (with the latest Let´s Encrypt version) work properly.

In essence, a troublesome Let´s Encrypt setup on the source server is not being migrated, which is "good practice".

So, your statement

I think this is something that should be improved, but from my point of view my request is solved.

is partly valid, given that

a) it is (partially) not valid, in the sense that it is fine that problematic certificates are not being migrated properly, (AND)

b) it is (partially) valid, in the sense that improvement is desirable and required, given that

- there is some inflexibility with respect to troublesome Let's Encrypt certificates: they seem to persist, (and)
- in migration processes, the destination server should not be "bothered" by certificate related issues on the source server, (and)
- in migration processes, both the source server and the destination server are faced with nearly but not exactly identical issues.


In summary and simply stated, there is space for improvement: self-healing mechanism(s) in the Plesk Let´s Encrypt extension.

After all, a "health check" at renewal time would be an optimal moment to remove any erroneous discrepancies in the Let´s Encrypt certificates.

@IgorG and @EugeneKazakov, I hope that you can have a look at all of the above and/or the option of an automatic "health check".

Regards.......