Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Console Archive] CURL: SSL certificate problem with expired certificate #18089

Closed
DevDavido opened this issue Oct 1, 2021 · 8 comments
Closed

[Console Archive] CURL: SSL certificate problem with expired certificate #18089

DevDavido opened this issue Oct 1, 2021 · 8 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc. not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.

Comments

@DevDavido
Copy link
Contributor

Since the DST Root CA X3 certificate expired yesterday, I'm getting tons of errors from Matomos console archive process.
The command that is executed via shell is console core:archive --url=https://matomo.domain.com/

Expected Behavior

No errors.

Current Behavior

ERROR [2021-10-01 15:58:52] 28630 Error unserializing the following response from ?module=API&method=CoreAdminHome.archiveReports&idSite=3&period=week&date=2021-09-27&format=json&trigger=archivephp: 'Got invalid response from API request: https://matomo.domain.com/?module=API&method=CoreAdminHome.archiveReports&idSite=3&period=week&date=2021-09-27&format=json&trigger=archivephp&. Response was 'curl_exec: SSL certificate problem: certificate has expired. Hostname requested was: matomo.domain.com''

Context

Running curl like curl -v https://matomo.domain.com/?module=API&method=CoreAdminHome.archiveReports&idSite=3&period=week&date=2021-09-27&format=json&trigger=archivephp& doesn't produce any errors nor does executing such a test script:

error_reporting(E_ALL);

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://matomo.domain.com/?module=API&method=CoreAdminHome.archiveReports&idSite=3&period=week&date=2021-09-27&format=json&trigger=archivephp&");
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($ch);
curl_close($ch);

Your Environment

  • Matomo Version: 4.4.1
  • PHP Version: 7.2.18
  • Server Operating System: Ubuntu 14.04 LTS
@DevDavido DevDavido added the Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. label Oct 1, 2021
@Findus23
Copy link
Member

Findus23 commented Oct 1, 2021

Hi,

Matomo overwrites the ca bundle like this:

matomo/core/Http.php

Lines 973 to 986 in 482cf02

/**
* Will configure CURL handle $ch
* to use local list of Certificate Authorities,
*/
public static function configCurlCertificate(&$ch)
{
$general = Config::getInstance()->General;
if (!empty($general['custom_cacert_pem'])) {
$cacertPath = $general['custom_cacert_pem'];
} else {
$cacertPath = CaBundle::getBundledCaBundlePath();
}
@curl_setopt($ch, CURLOPT_CAINFO, $cacertPath);
}

So if you added custom_cacert_pem to your General section of the config.ini.php, then it uses that file.

Otherwise it uses the file that Composer\CaBundle\CaBundle::getBundledCaBundlePath() returns which is most likely vendor/composer/ca-bundle/res/cacert.pem.

Originally we shipped https://curl.haxx.se/ca/cacert.pem with Matomo and updated it every few releases. But to automate this, we switched over to this composer package:
https://github.com/composer/ca-bundle

It seems like the latest Matomo version ships with 1.2.8 of that bundle with certificates from Wed Jul 22 03:12:14 2020 GMT.

It might be that updating the bundle fixes this issue.

@Findus23
Copy link
Member

Findus23 commented Oct 1, 2021

Reading https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ I now understand the issue:

For most nearly all users the DST Root CA X3 certificate expiration should not matter as long as one trusts the ISRG Root X1 certificate (which both Matomo and all major distributions already do for a long time).

But OpenSSL 1.0.2 has a bug that means that if the DST Root CA X3 is in the ca-bundle (even if the other one is also available), the connection fails.
So you can fix this by either removing the certificate from the bundle (on Matomo's end we can do this by updating the composer package to 1.2.11) or (maybe even better) updating to a more modern version of OpenSSL.

I strongly recommend you to do the latter in the long term. I assume you know that Ubuntu 14.04 LTS doesn't receive any security updates since April 2019 unless you are paying Canonical for an extended support contract (in which case you should probably contact them to help you fix the system ca bundle and point Matomo to it via the custom_cacert_pem option)

@Findus23 Findus23 added Bug For errors / faults / flaws / inconsistencies etc. and removed Potential Bug Something that might be a bug, but needs validation and confirmation it can be reproduced. labels Oct 1, 2021
@DevDavido
Copy link
Contributor Author

Thank you @Findus23 for your detailed feedback. As mentioned by you, updating the config/config.ini.php file by adding an updated cacert.pem as custom_cacert_pem directive solved the issue.

@tsteur tsteur mentioned this issue Oct 3, 2021
Closed
This was referenced Oct 3, 2021
Merged
Closed
@dev-101
Copy link

dev-101 commented Oct 8, 2021 •
edited

This looks related, although it happened during Matomo automated update to 4.5.0.
My server is not exactly up-to-date (will soon switch to new hosting), but still this is weird.
OpenSSL version 1.1.1 11 Sep 2018 (Library: OpenSSL 1.1.1k 25 Mar 2021)

matomo-update-ssl-issue

I had to use HTTP in the end to perform update.

@Findus23
Copy link
Member

Findus23 commented Oct 8, 2021

@dev-101 Honestly I can't help much as I know that the TLS setup on builds.matomo.org is correct (see ssllabs) and apart from the openssl 1.0.2 issue, I am not aware of any issue.
So I'd recommend you to debug this by first trying to make http requests using the command line curl and if that works a simple PHP script using curl.

@tsteur
Copy link
Member

tsteur commented Oct 10, 2021

@Findus23 I reckon we can actually close this issue since we merged the CA bundle update and it's in the 4.5 release? People may have issues though when they try to upgrade to 4.5 (nothing we can do about it now) but afterwards it should be fine I reckon.

@tsteur tsteur added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Oct 11, 2021
@nicobayati
Copy link

Hello, is planned to fix this bug for Matomo 3.14.1?

We want to update to the latest version 4.x, unfortunately we can't do it that fast and would be happy to get a fix for the old version.

Thanks

@tsteur
Copy link
Member

tsteur commented Oct 20, 2021

@sgiehl @Findus23 I'm assuming to make this work for 3.X we would simply need to update our cacert.pem with the content of vendor/composer/ca-bundle/res/cacert.pem?

@nicobayati I think you could replace the content of the file $matomoDir/core/DataFiles/cacert.pem manually with the content from this file https://raw.githubusercontent.com/composer/ca-bundle/main/res/cacert.pem and then it might work maybe. This way you might get it to work right away.

@justinvelluppillai justinvelluppillai mentioned this issue Jan 5, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug For errors / faults / flaws / inconsistencies etc. not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@tsteur @DevDavido @dev-101 @Findus23 @nicobayati