SSL certificate has expired

[danepowell]

Across multiple CI services that depend on asset-packagist, we are getting this curl error as of an hour or so ago: curl error 60 while downloading https://asset-packagist.org/packages.json: SSL certificate problem: certificate has expired

[danepowell]

I think this is on individual clients to fix: https://github.com/composer/composer/issues/10121

For instance, Xenial users likely still have OpenSSL 1.0.2 which has the expired root certificate. Upgrading to Bionic brings OpenSSL 1.1.1, which should work.

[danepowell]

I'm going to reopen this since it seems to be specific to asset-packagist. Regular packagist.org works fine. The root CA looks the same for both, so I'm not sure why packagist.org works but asset-packagist.org does not.

[fen1xpv]

I have the same issue on one of my machines. First I checked certificates for asset-packagist from Chrome and saw the correct chain: ISRG Root X1 -> Let's Encrypt R3 -> asset-packagist.org Then I tried checking certificate-chain from my machine using openssl. That's what I got for packagist.org:

$ openssl s_client -showcerts -verify 5 -connect packagist.org:443 < /dev/null
Certificate chain
 0 s:/CN=packagist.org
   i:/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

And here's what I got for asset-packagist.org:

$ openssl s_client -showcerts -verify 5 -connect asset-packagist.org:443 < /dev/null
Certificate chain
 0 s:/CN=letsencrypt-nginx-proxy-companion
   i:/CN=letsencrypt-nginx-proxy-companion
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

I saved the certificate above into asset_packagist.pem and checked expire date:

$ openssl x509 -enddate -noout -in asset_packagist.pem
notAfter=Sep 29 09:53:57 2021 GMT

[johnstevenson]

This is the current certificate chain prodived by the server:

openssl s_client -connect asset-packagist.org:443
---
Certificate chain
 0 s:CN = asset-packagist.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

It needs changing to:

---
Certificate chain
 0 s:CN = asset-packagist.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---

by requesting the alternate chain from Let's Encrypt, using --preferred-chain "ISRG Root X1" (or whatever is needed by your acme client).

Of course a quick (non-permanent) fix on the server is to remove the last certificate from the chain file.

[danepowell]

Indeed, that seems to be how packagist.org prevented this issue: https://github.com/composer/composer/issues/10121#issuecomment-932031852

Now that the root cert has already expired, I don't know if it's too late to fix from the server side.

[johnstevenson]

Now that the root cert has already expired, I don't know if it's too late to fix from the server side.

But this is the fix from the server side: by not supplying the expired cert as part of the chain, older OpenSSL versions look for the self-signed ISRG Root X1 (which hasn't expired).

That's why Composer changed it's chain to the alternate, shorter one.

Until asset-packagist changes its own chain, you can fix it for yourself by using the latest ca-bundle from: https://curl.se/docs/caextract.html

This doesn't have DST Root CA X3 in it, so older OpenSSL will work. Set the path to the bundle in either SSL_CERT_FILE or openssl.cafile in php ini

[rondog]

I am stuck not able to update an application because a module requires this repo. Any workarounds for this? I am on composer 1, but I tried it with 2, but still fails.

[rondog]

against my better judgement, turning SSL off in the repo option allows my modules to update

"assets": {
  "type": "composer",
  "url": "https://asset-packagist.org",
  "options": {
    "ssl": {
      "verify_peer": false
    }
  }
}

anyway, is this possibly related? https://medium.com/@BraunDoug/lets-encrypt-ssl-security-errors-starting-on-sep-30-2021-your-connection-is-not-private-417ca007fe07 The timeframe seems about right

[johnstevenson]

@rondog why don't you try using ca-bundle as I suggested in my response above?

[rondog]

@johnstevenson I was not sure how to do that

[johnstevenson]

Download https://curl.se/docs/caextract.html some where, then set the location to the bundle in either the SSL_CERT_FILE environment variable or openssl.cafile in php ini

Aternatively, you can remove the DST Root CA X3 certificate from your trusted certificates.

[develJawad]

Try this command: composer self-update

[danepowell]

There may still be work for asset packagist to do on the server side here, but hopefully after 6 months everyone has updated their clients to handle it. I'm going to close this issue since I originally opened it, but if it's still an issue for anyone else feel free to reopen or start a new issue.

[glenshewchuck]

: After upgrading openssl no problems sudo yum update openssl