Issue [ PI-729] Plesk Updater uses wrong certificate chain

[drudge]

I currently have trouble to secure the Plesk updater which opens at port 8447 when I click "Updates" on the tools and settings page in the Plesk admin panel.

I migrated my server from Ubuntu 18.04 to 20.04 using the Plesk Migrator tonight and I'm now on Plesk Obsidian 18.0.39 Update 1.
Temporarily, I also migrated the 'archive' and 'live' folder of Letsencrypt to the new server using rsync.
After the migration, I regenerated all the Letsencrypt certificates and they are using the correct, new LE Certificate Chain.
In tools and settings, SSL/TLS settings, I chose the wildcard certificate of my domain to protect Plesk and the E-Mail System as well.

However, I have trouble to provide a proper certificate for the Updater.
All websites, the mail system, the Plesk admin panel at port 8443, etc. are using the correct LE chain:
ISGR Root > R3 > mydomain.tld



The Updater on port 8447, however, uses the following certificate and certificate chain and therefore, an SSL error occurs:
DST Root CA X3 (deprecated) > R3 (valid until 29. Sept. 2021) > mydomain.tld



(URL is redacted in both screenshots)

With respect to the leaf certificate, the expiration date and time is the same and hence, I think its the correct certificate with the wrong chain.

How am I able to establish a secure connection to the updater again?

What I have tried yet:

• Regenerate all Letsencrypt certificates
• Chose another and re-chose the certificate for Plesk in tools and settings > SSL/TLS settings
• Verified, the old root certificate is not present anymore in /etc/ssl/certs
• Verified, the entry for the old root certificate is not present anymore in /etc/ca-certificates.conf (it's not commented out since it's not there at all)
• Ran 'update-ca-certificates'
• Added the following to the panel.ini
  [ext-letsencrypt]
  use-alternate-root = true
• Started and Stopped the PSA Service
• Ran 'plesk repair installation'

However, none of these actions was successful. Is there anything I missed to make the updater available via SSL?

 

[Nik G]

hello @drudge ,

unfortunately we were not able to reproduce this problem.
Plesk LE extension requests certificates with new chain approximately since the spring '21.
Also, autoinstaller uses the same certificate files that secure panel on 8443 port, so this is very strange issue.

1. we'd recommend you to remove from panel.ini options you mentioned above:

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

Default chain: End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3
Alternate chain: End-entity certificate ← R3 ← ISRG Root X1
also please have in view that alternate chain won't work for old androids

2. could you please clarify, are you use the same browser for opening Plesk control panel interface8443) and Plesk Installer UI 8447) ?

after you renewed certificate for the panel it might not be applied to AI right after that because AI web server may already be running.
In this case installer will connect to the existing session (with old certificate).

 

[Nik G]

@drudge ,
also, please review thread at I can't open certain websites on my MacBo… - Apple Community
it looks similar to your problem.

based on your screenshots I suggest y're using Safari at Mac. I'm right ?

 

[speedbird]

I'm seeing exactly the same problem. 8443 and the cert is valid, 8447 and the very same cert is flagged as invalid although it's as valid as can be.

Google Chrome btw. Plesk, Browser and OS are up to date.

 

[drudge]

Hello Nic G,

thanks for your ideas. I removed the lines from the panel.ini but this changed not the behaviour.
Regarding your question 2, yes, I indeed use the same browser. This happens on both Chrome and Safari.

• Logged in on mydomain.tld:8443 (certificate valid) on my MacBook (MacOS Big Sur 11.6/latest OS patch level) with Safari (latest patch level), went to Tools and Settings > Updates, a new tab opens with mydomain.tld:8447 and the certificate is invalid. I did not switched the browser between browsing on port 8443 and 8447
• Same behavior on my MacBook with Google Chrome (latest patch level)
• Same behavior on my iPhone (latest OS patch level) with Safari Mobile (latest patch level)

I'm currently not able to check the certificate with a non-Apple device and SSLLabs does allow checking the certificate with a custom port. Any ideas for an alternative SSL checker?
However, if this is really a problem with an Apple device, I don't understand why it's working on port 8443 or my websites at port 443. I also removed all certificates associated to mydomain.tld from the Apple keychain, but had no luck.

I also diffed the certificates which I guess is used for my websites (and probably Plesk at port 8443) located at
/usr/local/psa/var/modules/letsencrypt/etc/live/mydomain.tld/fullchain.pem
and the certificate which I guess is used for the updater
/opt/psa/admin/conf/httpsd.pem
(as shown in 'ps aux|grep autoinstall' when the updater at port 8447 is up)
They are indeed the same with the difference that the httpsd.pem additionally includes the CSR and private key, but in my opinion, this should not affect the chain, should it?

Both certificates also return the same output when running
openssl crl2pkcs7 -nocrl -certfile /path/to/certificate.pem|openssl pkcs7 -print_certs -noout

subject=CN = mydomain.tld
issuer=C = US, O = Let's Encrypt, CN = R3
subject=C = US, O = Let's Encrypt, CN = R3
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3

Are the assumed paths to the certificate correct or are there any hints how I can identify which certificated is returned by the server exactly?

 

[drudge]

To minimize chances it's a matter of my end device, I used the tools of Geocerts which allows to scan the SSL certificate on a custom port.

On mydomain.tld:8443, everything looks fine:



However, the tool also complains on mydomain.tld:8447 when the autoupdater is up, running, and scanned:


So I guess it's not a matter with my device, is it?
Does it mean that the updater does not provide the full chain and instead, only the leaf certificate?

 

[learning_curve]

To minimize chances it's a matter of my end device, I used the tools of Geocerts which allows to scan the SSL certificate on a custom port.
~~~
So I guess it's not a matter with my device, is it?
Does it mean that the updater does not provide the full chain and instead, only the leaf certificate?

There IS definitely an issue related to Plesk and port 8447 and it definitely does not appear to be related to your device(s) @drudge

Some Notes:

Usually, we never use the GUI Plesk Update Upgrade process that utilises Port 8447 (there have been previous issues in the past with this).
Usually, we run everything (Plesk / OS / etc) manually via CLI, which works perfectly and Port 8447 etc is irrelevant in this case.
Usually, we renew SSL Certificate updates that are above and beyond a single domain e.g Wildcard SSL Certificates via acme.sh as it's much easier (for us).
Having read this thread, we thought we'd check everything - just in case -

The issue that's been posted, does produce the effect on all the latest releases of Chrome and Safari but NOT Firefox, which retains it's own Cert Records Set and soo there's no issue with the SSL Certificate / Chain / Validity etc with Plesk on Port 8447, well not in our case anyway.

It's NOT the SSL Certificates / Chains / Validity etc themselves. They all work perfectly, on all of those browsers, unless... it's Plesk GUI on Port 8447.

It's NOT anything to do with Apple / Safari / Mac as has been posted. We usually only use Apple, but we tried it with a Windows 10 machine too.

For us, it's NOT a current issue of concern, (as we use CLI not Plesk Plesk on Port 8447) but it will be an issue, for those that don't use CLI until fixed.

FWIW You can see the error on all SSL check / tests that allow port sepcification, say geocerts the one already posted or namecheap and many others.

 

[drudge]

Hi @learning_curve, thanks for your update on this. As far as I understood the problem, I cannot change anything to make it work, right?
What is the way to go here? As far as I got it, I could temporarily install and use Firefox because it uses it own cert record set. I typically use the GUI, rather than the CLI for updates.
Is it a problem qualified for a bug report?

 

[mow]

So it has to be the version and/or configuration of the separate nginx Plesk fires up on 8447 for maintaining Plesk itself?

 

[Bitpalast]

Have you tried to restart remove the DST Root CA X3 certificate from your server that expired on September 27th and then restarted the psa service and sw-engine (# service sw-engine restart && service sw-cp-server restart)?

 

[learning_curve]

Have you tried to restart remove the DST Root CA X3 certificate from your server that expired on September 27th and then restarted the psa service and sw-engine (# service sw-engine restart && service sw-cp-server restart)?

There was no need to do this (in our case anyway) @Peter Debik as one of the Ubuntu 20.04.* LTS updates made this change by default, so only the ISRG_Root_X1.pem link remains in /etc/ssl/certs (DST Root CA X3 no longer exists) plus, the /etc/ca-certificates.conf file contains the 2 lines needed:

!mozilla/DST_Root_CA_X3.crt
mozilla/ISRG_Root_X1.crt

We've had a number of server re-boots since those Ubuntu updates, which takes care of the PSA Service & SW Engine Re-Starts you mentioned.

The complete update-ca-certificates [options] process is covered on THIS reference page for Ubuntu 20.04.* LTS just for clarity but perhaps for reference, one of the clearest articles that covers all the aspects of the X3 / X1 Let's Encrypt Changes, c/w links where needed, is THIS ONE by Scott Helme

 

[learning_curve]

As far as I understood the problem, I cannot change anything to make it work, right?
What is the way to go here? As far as I got it, I could temporarily install and use Firefox because it uses it own cert record set. I typically use the GUI, rather than the CLI for updates. Is it a problem qualified for a bug report?

Other than carrying out any of the checks / double checks posted on here (that you've not done already) then probably no. At this stage, a Plesk 'fix' looks like it's needed, which means, waiting until it is confirmed as an issue by Plesk and not (for whatever reason) any of our own local setup 'differences' that are causing the issue. That's something that @Nik G might start off here, before anybody raises an unecessary bug report?

 

[Nik G]

Restart of Plesk services won't help because at the server's side everything looks mostly correct (from the cert point of view).
The problem is that the certificate cannot be validated on client side (at your Mac, laptop, cell phone and so on - on device where you try to open Plesk Installer web interface)

there was a though that web installer uses not full certificate chain and provided leaf instead.
due to internal architecture it sounds reasonable, but requires additional investigation from our side.

any way, we've created an issue PI-729 to address this problem.
Unfortunately I can't provide any ETA, but I hope it should be fixed in 18.0.40 or even probably some nearest hotfixes for 18.0.39

 

[pick3pro]

Running Plesk 18.0.39 (Update 1) on my VPS server on Ubuntu 18.0.4 LTS
I currently have the same issue on Mac Mini running Mac OS 11.6. (Latest Big Sur). I tried both Chrome & Safari.

I saw the same issue on Windows 10 until I installed new cert into certificate store. Using Chrome browser.
I have not seen the issue on a Mac Mini running Mac OS 10.15.7 (Latest for Catalina) Using Chrome/Safari browser.

 

[learning_curve]

As mentioned, we use CLI for all updates, so not a big issue for us, but FWIW assuming that you have the latest release of Firefox, (desktop) installed, you can export both the ISRGRootX1.crt and the R3.crt files from there, import those, then use them on other browsers. Worked fine** when we tested today on the latest releases of Windows 10 / Edge and MacOS / Safari & Chrome (which usse the Certs in Keychain Access on your MacOS just like Safari does).

** Meaning: Host Domain / Plesk GUI / Port 8447 - as per previous posts