Let's Encrypt extension

[mr-wolf]

BTW....

Similar, but not the same, as Peter Debik's request, I am interested in the possibility to hide the "Assign the certificate to mail domain"
The reason for this is that I have my own Maul autodiscovery and I am using a fixed and bought wildcard certificate on Postfix & Dovecot.
That way I'm not dependent on Letsencrypt nor on SNI which are not supported by some older mail clients.

 

[Mariuolo]

In January 2020, Let's Encrypt will start serving certificates that leads to a new root certificate which is not supported by Android <7.1 and other old operating systems. This is the official announcement on their blog.

This will pose a problem for many users. There's a temporary workaround using an alternate link relation. Will the Let's Encrypt plugin allow using this alternate certificate?

 

[LTUser]

In January 2020, Let's Encrypt will start serving certificates that leads to a new root certificate which is not supported by Android <7.1 and other old operating systems. This is the official announcement on their blog.

This will pose a problem for many users. There's a temporary workaround using an alternate link relation. Will the Let's Encrypt plugin allow using this alternate certificate?

+1
This is a very urgent question.

 

[Bitpalast]

+1
Yeah, probably Plesk should take care of this.

 

[ybabaeva]

In January 2020, Let's Encrypt will start serving certificates that leads to a new root certificate which is not supported by Android <7.1 and other old operating systems. This is the official announcement on their blog.

This will pose a problem for many users. There's a temporary workaround using an alternate link relation. Will the Let's Encrypt plugin allow using this alternate certificate?

Hi. The support of alternative root chain was implemented in Let's Encrypt extension 2.12.0 (17 September 2020). Please check the release notes for more details - Let's Encrypt - Plesk Extensions!
But please be careful not to enable it in advance - because ISRG Root is alternative now, and it's planned to be switched by Let's Encrypt on January 11, 2021.

 

[AYamshanov]

The link Change Log for Plesk Obsidian points exactly to the changes:

[+] The extension now supports a new chain of trust based on ISRG Root. Before January 11, 2021, the old IdenTrust root remains the default one, while the new ISRG Root is an alternative one. After January 11, 2021, the extension will issue SSL/TLS certificates based on the new ISRG Root, while the old IdenTrust root will become an alternative one.

To have the extension issue SSL/TLS certificates based on the alternative root (which is ISRG Root before January 11, 2021, and IdenTrust after this date), add the following lines to panel.ini:

[ext-letsencrypt]
use-alternate-root = true

 

[Martin.B]

The current changelog for the extension hows the following entry:

The extension can now automatically issue SSL/TLS certificates only for those domains that Plesk verified to be resolvable. Users will no longer see an error from Let’s Encrypt occurred when the extension failed to secure non-resolvable domains.


This improvement will be gradually turned on by default for all Plesk Obsidian installations.

We often have the problem, that we can't force the issue of LE by service plan, because in most cases the domains aren't registered yet or still point to a different provider and as a result we get errors and notification mails, so this seems like a thing we may need.
However we tested the new version and it didn't show a different behaviour to the one before.

The question is, how should I understand the last scentence? Is there an option (panel.ini?) that needs to be set for this new behaviour?

 

[AYamshanov]

Hi Martin.B

The question is, how should I understand the last scentence? Is there an option (panel.ini?) that needs to be set for this new behaviour?

Yes, to enable this feature you need to put the next three lines into panel.ini

[dns]
enableResolveChecking = true
showDnsHelper = true

It will work on Plesk Obsidian since the 18.0.32 version.

 

[Bitpalast]

The link Change Log for Plesk Obsidian points exactly to the changes:

[ext-letsencrypt]
use-alternate-root = true

@AYamshanov I am asking for clarification. I understand this update in a way that actually we don't have to do anything, because from January 11 the default chain will automatically be changed in Plesk. Is that correct? Only if we do not want the change but instead use the "old" chain (which was the default before January 11) we'll need to add these lines to panel.ini?

 

[AYamshanov]

@AYamshanov I am asking for clarification. I understand this update in a way that actually we don't have to do anything, because from January 11 the default chain will automatically be changed in Plesk. Is that correct? Only if we do not want the change but instead use the "old" chain (which was the default before January 11) we'll need to add these lines to panel.ini?

In general, yes, that is correct.
Except for one small note: it will be changed in Let's Encrypt API that Plesk uses (not in Plesk and/or extension directly).

 

[pleskuser67553]

Happy days... Extending Android Device Compatibility for Let's Encrypt Certificates - Let's Encrypt - Free SSL/TLS Certificates

 

[Achim Drees]

Hi,
is that already fixed?

Plesk Help Center

support.plesk.com

 

[Elias Soares]

Hi,

I would like to question why it's impossible to auto-renew Let's Encrypt certificates when using Route53 Extension (or any DNS extension).
Looks like a very simple thing to do, just add a TXT entry, wait for renew, remove the TXT entry. This issue is very annoying.

 

[r0mbus]

Hello,

i have a problem with this extension - when im reissuing a new certificate, it still contais the old "DST Root CA X3"-Certificate. Ive already patched all my server and the problem exist on every of them. There are different OS installed - Ubunto 16.04, Ubuntu 20.04, Centos7, but it happens everywhere, on every server. What im doing wrong?

 

[Bitpalast]

Hello,

i have a problem with this extension - when im reissuing a new certificate, it still contais the old "DST Root CA X3"-Certificate. Ive already patched all my server and the problem exist on every of them. There are different OS installed - Ubunto 16.04, Ubuntu 20.04, Centos7, but it happens everywhere, on every server. What im doing wrong?

The certificate should not at all "contain" the old root certificate. The requesting browser or machine uses the root certificate. Maybe your requestor has not updated its certificates?

 

[r0mbus]

The certificate should not at all "contain" the old root certificate. The requesting browser or machine uses the root certificate. Maybe your requestor has not updated its certificates?

Hello Peter and thx for the fast reply. I can see this old root certificate if i open it in plesk. This is the "*-ca.crt" from one customer after reissuing the cert:

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----

I think, the bottom part is the old root cert and i have no idea why it is still there.

Ive found some patchnotes for "lets encrypt"-extension (from last year):

• [+] The extension now supports a new chain of trust based on ISRG Root. Before January 11, 2021, the old IdenTrust root remains the default one, while the new ISRG Root is an alternative one. After January 11, 2021, the extension will issue SSL/TLS certificates based on the new ISRG Root, while the old IdenTrust root will become an alternative one.
  To have the extension issue SSL/TLS certificates based on the alternative root (which is ISRG Root before January 11, 2021, and IdenTrust after this date), add the following lines to panel.ini:
  [ext-letsencrypt]
  use-alternate-root = true

Ive added those lines to panel.ini and now the new certs are being reissued different. The "*-ca.crt"-file is containing only one cert:

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----

Everything works fine now, the client machine can connect to me via API without any problems. Its a Win10-machines with custom software, using openssl 1.1.1k. Suddenly, i cant update/modify this custom software.
Im not sure, if that what ive just did is correct. I mean, wow, its working, but i dont really understand if there is any consequences

 

[mvduin]

Hello,

i have a problem with this extension - when im reissuing a new certificate, it still contais the old "DST Root CA X3"-Certificate. Ive already patched all my server and the problem exist on every of them. There are different OS installed - Ubunto 16.04, Ubuntu 20.04, Centos7, but it happens everywhere, on every server. What im doing wrong?

The default certificate chain provided by Let's Encrypt currently still includes a cross-certificate from the expired "DST Root CA X3" to "ISRG Root X1" (the Let's Encrypt root) because:

1. Android did not trust ISRG Root X1 prior to version 7.1.1
2. Android intentionally ignores expiration of root certificates
3. The cross-certificate is valid for three more years, until 2024-09-30

Keeping this cross-certificate in the chain will thus maintain support for Android clients older than 7.1.1.

There is however an unfortunate side-effect: the presence of this cross-certificate from a trusted but expired root causes older versions of various SSL libraries to reject the entire chain even when ISRG Root X1 itself is trusted by the system. This bug is known to affect:

• OpenSSL prior to 1.1.0 (released 2016-08-25)
• LibreSSL prior to 3.2.0 (released 2020-05-31)
• GnuTLS prior to 3.6.14 (released 2020-06-03)

Note that all of the affected versions are obsolete and have known security vulnerabilities.

Let's Encrypt deemed that maintaining support for older Android clients was more important than maintaining support for applications that use these old TLS libraries. However, your priorities may differ, hence you can select the "alternative root" which will give you a certificate chain that omits this cross-cert.

The problem can also be fixed by removing the expired DST Root CA X3 from the system certificate store, for example on Debian/Ubuntu:

sudo sed -i 's/^mozilla\/DST_Root_CA_X3.crt/!mozilla\/DST_Root_CA_X3.crt/g' /etc/ca-certificates.conf
sudo update-ca-certificates

For more information see:

• Extending Android Device Compatibility for Let's Encrypt Certificates
• OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates

The certificate should not at all "contain" the old root certificate. The requesting browser or machine uses the root certificate. Maybe your requestor has not updated its certificates?

He doesn't mean the literal root certificate itself, but rather an intermediate certificate signed by the old root.

Its a Win10-machines with custom software, using openssl 1.1.1k. Suddenly, i cant update/modify this custom software.

This sounds like you must be doing something weird in your custom software? OpenSSL 1.1.x itself normally has no problem with the presence of this cross-certificate, it will simply ignore it.

Im not sure, if that what ive just did is correct. I mean, wow, its working, but i dont really understand if there is any consequences

The consequence is that Android clients older than 7.1.1 will no longer be able to connect to your server.


Matthijs van Duin

 

[SteveITS]

Per Change Log for Plesk Obsidian this extension is now part of SSL It, is that correct? Should a separate thread be pinned for that?

Does anyone know a way to lengthen the timeout for an LE cert validation beyond the current roughly 10 minutes? See Issue - SSL It! - LE Cert fails: The operation takes too long. Please try later.

 

[hilly]

why doesnt this plugin allow letscrypt verification via files rather than dns? my dns is hosted with cloudflare so when the certificate expires, the whole website goes down until i bypass cloudflare dns, wait for dns to prop, and then do the letscrypt verification again and then change it back

 

[Kaspar@Plesk]

why doesnt this plugin allow letscrypt verification via files rather than dns? my dns is hosted with cloudflare so when the certificate expires, the whole website goes down until i bypass cloudflare dns, wait for dns to prop, and then do the letscrypt verification again and then change it back

Validation for Let's Encrypt certificates is done via file verification, unless you're using a wildcard certificate for your domain. Wildcard certificates are validated via both file verification and DNS verification. If the re-issuing of certificates causes issue because of DNS problems you might can try to solve this by:
a) disable the wildcard certificate on your domain (DNS verification would no longer be needed)
b) or, since you mentioned you're using CloudFlare DNS, try the Cloudflare DNS extension to automatically sync the DNS zones of a domain with CloudFlare.