Issue Certificate verification failed

[se2e-dev]

Server operating system version

Debian 12.11

Plesk version and microupdate number

18.0.69 Update 3

This morning (May 23, 2025), we observed that all our Plesk servers reported an error during the automatic update of system packages and third-party components. The following message was logged and also sent via email:

There was a problem updating the system packages and third-party components on the example.com server. Please wait for the next automatic update or start the update manually: https://example.com/admin/pum

Reason:
2025-05-23 06:25:52 INFO: pum is called with arguments: [’–update’, ‘–json’]
2025-05-23 06:26:00 ERROR: Apt cache fetch failed. Try to run the apt-get update command.
2025-05-23 06:26:00 ERROR:
2025-05-23 06:26:00 ERROR: Exited with return code 1.

Additionally, the following warning is displayed in the Plesk interface:

“Warning: The information about some packages may not be up to date: Inconsistencies were found in the system package manager’s database. Please resolve this issue manually.”

Following the update errors that occurred on the morning of May 23, I performed a manual system check. The system showed no irregularities. During a manual update and upgrade process, no package changes were required, indicating that the system is up to date.

However, during the update, there was a warning related to one of the Plesk repositories. Specifically, the system was unable to access the package information from the RUBY_1.5.0 repository. The error pointed to a certificate verification issue, stating that the certificate is not trusted and the OCSP status response was invalid. As a result, the system could not complete a proper handshake with the server.

This suggests a temporary issue with the SSL certificate or its OCSP response on the Plesk side. All other repositories were contacted successfully, and the system appears fully updated despite the warning.

I would be interested to know if others are seeing the same behavior and whether Plesk has acknowledged the issue or provided any official guidance.

Ign:12 https://autoinstall.plesk.com/RUBY_1.5.0 bookworm InRelease
Ign:12 https://autoinstall.plesk.com/RUBY_1.5.0 bookworm InRelease
Err:12 https://autoinstall.plesk.com/RUBY_1.5.0 bookworm InRelease
  Certificate verification failed: The certificate is NOT trusted. The received OCSP status response is invalid.  Could not handshake: Error in the certificate verification. [IP: xxxx:xxxx:xxxx::xxx 443]
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch https://autoinstall.plesk.com/RUBY_1.5.0/dists/bookworm/InRelease  Certificate verification failed: The certificate is NOT trusted. The received OCSP status response is invalid.  Could not handshake: Error in the certificate verification. [IP: xxxx:xxxx:xxxx::xxx 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  linux-image-6.1.0-28-amd64
Use 'apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

 

[FloLa]

I also received this error today while installing a completely new server.

 

[FloLa]

I also received this error today while installing a completely new server.

View attachment 28324

Solved for me by now.

 

[se2e-dev]

Did the problem resolve itself?

 

[Bitpalast]

I think the problem is caused by missing OCSP server validation as described here: Issue - Potential issue with OCSP stapling

 

[trialotto]

I think the problem is caused by missing OCSP server validation as described here: Issue - Potential issue with OCSP stapling

@Bitpalast

There is no certainty of the presence of causality.

These error messages seem to pop up in the same period that error notifications are received due to failing OCSP Stapling, but that does not necessarily mean that there is a relation between these two issues.

In fact, the PUM related error messages are quite common and - more importantly - they are rather random.

As an example, server A and B are identical in every sense, but only server A has a PUM related error message.

As another example, server A and C are identical in every sense and both have error messages, but the PUM related error messages disappear on server C.

These were the results of a simple test with 3 test servers ............. and a similar situation occurs on production servers.


In essence, the PUM related error messages often disappear and can have a multitude of causes.


All of the above is more or less a general approach to PUM related errors and does not necessarily address the issue of @se2e-dev.

The issue of @se2e-dev can be related to "standard" PUM errors (which will disappear) and can be related to OCSP related issues on the repository side.

However, it is (almost) certain that the @se2e-dev is confronted with issues on the repository side - Plesk Panel only responds and acts to those issues.


The issues of @FloLa are of a different nature, since they involve keyring related issues.


In summary, it is probably best to wait and see what happens - the PUM related issues of @se2e-dev probably will disappear.

Nevertheless, for whom it may concern - why is a repository associated with certificates that cause trust issues?!???


Kind regards........


PS I am not sure whether Plesk uses Let's Encrypt services for the repository side. One might expect the usage of Google Trust Services, but that would not have caused any certificate related issue at all. And if Let's Encrypt services are used for the repositories, that would be (very) bad practice. Anyone of Plesk Team wanting to provide more information about the certificates on the repository side?

 

[Sebahat.hadzhi]

Hello, everyone. Our team recently reviewed a similar issue and according to them The certificate is NOT trusted and OCSP status response is invalid indicate that the system cannot verify the validity of the certificate when connecting to the repository server, autoinstall.plesk.com/RUBY_1.5.0 in this particular case, which could be caused by various reasons, such as lack of up-to-date list of trusted certificates (CA certificates on the system, lack of a valid response or inability to process correctly the OCSP check, an issue with the network connection or a transparent proxy. What was suggested:

apt update
apt install --reinstall ca-certificates

PS I am not sure whether Plesk uses Let's Encrypt services for the repository side. One might expect the usage of Google Trust Services, but that would not have caused any certificate related issue at all. And if Let's Encrypt services are used for the repositories, that would be (very) bad practice. Anyone of Plesk Team wanting to provide more information about the certificates on the repository side?

I cannot confirm what certificate service is sued, but I will double-check with our team and follow up with confirmation.