2

Whenver I use simple commands (install/update) for a Composer-based projects or the "diagnose" command composer diagnose -vvv, I get the error:

"curl error 60 while downloading https://repo.packagist.org/packages.json: SSL certificate problem: unable to get local issuer certificate"

I already tried to:

  • Update to the latest Ubuntu (22.04) and specifically used:
sudo apt install ca-certificates --reinstall
sudo update-ca-certificates -f
sudo mkdir -p /etc/pki/tls/certs
sudo ln -s /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/ca-certificates.crt

And in facts the diagnose says, as expected:

Checked CA file /etc/pki/tls/certs/ca-bundle.crt: valid

  • Rerun the Composer installer

Some more information that could be useful:

Composer version: 2.2.6
PHP version: 8.1.2
PHP binary path: /usr/bin/php8.1
OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
cURL version: 7.81.0 libz 1.2.11 ssl OpenSSL/3.0.2
CharlesM
  • 521
  • 1
  • 7
  • 16

2 Answers2

0

Finally managed to solve it by manually replacing the ca-bundle.crt file, after realizing that even a simple curl/wget CLI command (outside of PHP/Composer) returned the same error (this the reason of the --no-check-certificate below):

sudo mv /etc/ssl/certs/ca-bundle.crt /etc/ssl/certs/ca-bundle.crt.backup
sudo wget -O /etc/ssl/ca-bundle.crt https://curl.se/ca/cacert.pem --no-check-certificate

I got the link from: https://curl.se/docs/caextract.html

CharlesM
  • 521
  • 1
  • 7
  • 16
  • You should try once more at least but with certificate checks and then compare if the .pem files are identical. Technically with this update procedure you have robbed yourself to properly check if the .pem store is legit. This affects all applications that make use of the store. – hakre Jun 14 '22 at 21:27
  • That's the issue: truth is, it was not limited to Composer. I updated the answer. – CharlesM Jun 15 '22 at 20:33
  • Sure (or better: at least this is how I previously read your answer), that is the "reason" for `--no-check-certificate` (`wget(1)` as well was affected), but given the certificate store on the system was damaged, how to resolve? Replacing it without verification (and no secondary check even (!) in the answer [as solution proposal]) looks a bit short circuited for the matter (to me). This is why I suggested to at least (quickly) double-check the new file is legit (and the problem remains and legibility _can't_ be established any longer on the same system - technically). At least use sha256sum. – hakre Jun 15 '22 at 23:17
  • suggesting to backup first is good IMHO as this allows to do such checks retro-actively. so the answer (also earlier) is well thought through. (comment limit, hence a second one). – hakre Jun 15 '22 at 23:20
0

Re-run the composer installer. IIRC it ships with its own certificate store or at least has some fallback package.

For your operating system, use the standard update procedure.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • Actually, I had already tried to rerun the installer. I updated the question. – CharlesM Jun 15 '22 at 20:29
  • Okay, composers store is perhaps only if there is no system store (or PHP not configured correctly). I'm a bit wondering why this happened on your system and how the system update procedure couldn't cope with it. Have you tried to re-install via apt/apt-get/dpkg (or similar in regards of package management of the OS)? -- regarding compsers store, it also is related to MDNs'/Curls' one. So this should be all the same sort-of for the actual certificates - just saying. – hakre Jun 15 '22 at 23:22