This issue is having a massive impact for me.

RHEL 8.3 and 8.4 can't download php without doing a skip certificate check.  Did someone forget to include the CA? 

--2021-05-24 17:59:29--  https://www.php.net/distributions/php-8.0.6.tar.xz
Resolving www.php.net (www.php.net)... 2a02:cb40:200::1ad, 185.85.0.29
Connecting to www.php.net (www.php.net)|2a02:cb40:200::1ad|:443... connected.
ERROR: The certificate of ‘www.php.net’ is not trusted.
ERROR: The certificate of ‘www.php.net’ was signed using an insecure algorithm.

CentOS Linux release 7.9.2009 (Core)

Updating channel "doc.php.net"
Channel "doc.php.net" is not responding over http://, failed with message: Connection to `doc.php.net:80' failed: Connection refused
Trying channel "doc.php.net" over https:// instead
Cannot retrieve channel.xml for channel "doc.php.net" (Connection to `ssl://doc.php.net:443' failed: Connection refused)

CentOS Linux release 7.9.2009 (Core)

Updating channel "doc.php.net"
Channel "doc.php.net" is not responding over http://, failed with message: Connection to `doc.php.net:80' failed: Connection refused
Trying channel "doc.php.net" over https:// instead
Cannot retrieve channel.xml for channel "doc.php.net" (Connection to `ssl://doc.php.net:443' failed: Connection refused)

It seems the cert has been updated, or does anyone still have
issues accessing the site?

I can confirm that the issue with https://pear.php.net/ seems to have been resolved.

Given the other comments in this report that relate to other parts of the site I am not sure if I should close this issue or not, so I will leave that to you.

Kind regards,
Svet

Thanks for the swift reply!  I think it's best to leave this "on
feedback" for now.

This still seems to be an issue on CentOS 6/7/8,

[root]# pear list-upgrades
Connection to `ssl://pear.php.net:443' failed:

[root]# wget https://pear.php.net
--2021-05-25 12:14:45--  https://pear.php.net/
Resolving pear.php.net (pear.php.net)... 109.203.101.62
Connecting to pear.php.net (pear.php.net)|109.203.101.62|:443... connected.
ERROR: The certificate of ‘pear.php.net’ is not trusted.
ERROR: The certificate of ‘pear.php.net’ was signed using an insecure algorithm.

CentOS 6 seems to give a little more details in the problem,

[root]# wget https://pear.php.net
--2021-05-25 12:16:25--  https://pear.php.net/
Resolving pear.php.net... 109.203.101.62
Connecting to pear.php.net|109.203.101.62|:443... connected.
ERROR: cannot verify pear.php.net’s certificate, issued by “/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Domain Validation CA SHA2”:
  Self-signed certificate encountered.
To connect to pear.php.net insecurely, use ‘--no-check-certificate’.

The cert is fine - https://www.ssllabs.com/ssltest/analyze.html?d=pear.php.net
Your ancient Centos 6 likely has outdated root certs.

The problem is the self signed CA cert included on *.php.net.  It's included in your CA chain.  Can you remove it?  

Connecting to www.php.net (www.php.net)|2a02:cb40:200::1ad|:443... connected.
ERROR: The certificate of ‘www.php.net’ is not trusted.
ERROR: The certificate of ‘www.php.net’ was signed using an insecure algorithm.

Well, the root certificate is signed with the weak sha1RSA, but
that shouldn't have an impact on a root certificate.

There seem to be installations that do not have the Certrum CA root cert in their list of known root-certificates.

OhDear mentiones that in their SSL Checks as well. I do not yet know where they get their root-CA list from. Checking that currently...

Or we have to add Certum's self signed CA cert to Moizilla / RHELs CA:  

-----BEGIN CERTIFICATE-----
MIIDDDCCAfSgAwIBAgIDAQAgMA0GCSqGSIb3DQEBBQUAMD4xCzAJBgNVBAYTAlBMMRswGQYDVQQK
ExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBDQTAeFw0wMjA2MTExMDQ2Mzla
Fw0yNzA2MTExMDQ2MzlaMD4xCzAJBgNVBAYTAlBMMRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8u
by4xEjAQBgNVBAMTCUNlcnR1bSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM6x
wS7TT3zNJc4YPk/EjG+AanPIW1H4m9LcuwBcsaD8dQPugfCI7iNS6eYVM42sLQnFdvkrOYCJ5JdL
kKWoePhzQ3ukYbDYWMzhbGZ+nPMJXlVjhNWo7/OxLjBos8Q82KxujZlakE403Daaj4GIULdtlkIJ
89eVgw1BS7Bqa/j8D35in2fE7SZfECYPCE/wpFcozo+47UX2bu4lXapuOb7kky/ZR6By6/qmW6/K
Uz/iDsaWVhFu9+lmqSbYf5VT7QqFiLpPKaVCjF62/IUgAKpoC6EahQGcxEZjgoi2IrHu/qpGWX7P
NSzVttpd90gzFFS269lvzs2I1qsb2pY7HVkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkq
hkiG9w0BAQUFAAOCAQEAuI3O7+cUus/usESSbLQ5PqKEbq24IXfS1HeCh+YgQYHu4vgRt2PRFze+
GXYkHAQaTOs9qmdvLdTN/mUxcMUbpgIKumB7bVjCmkn+YzILa+M6wKyrO7Do0wlRjBCDxjTgxSvg
GrZgFCdsMneMvLJymM/NzD+5yCRCFNZX/OYmQ6kd5YCQzgNUKD73P9P4Te1qCjqTE5s7FCMTY5w/
0YcneeVMUeMBrYVdGjux1XMQpNPyvG5k9VpWkKjHDkx0Dy5xO/fIR/RpbxXyEV6DHpx8Uq79AtoS
qFlnGNu8cN2bsWntgM6JQEhqDjXKKWYVIZQs6GAqm4VKQPNriiTsBhYscw==
-----END CERTIFICATE-----

https://www.ssllabs.com/ssltest/analyze.html?d=www.php.net&s=185.85.0.29 Shows the multiple CA paths, and Certum's CA is in RHELs CA, just not the self signed one.  Adding the self signed CA, makes everything work.  Clicking the tabs in ssllabs certification paths, you'll see that in Mozilla's and Android, the self signed cert is not in the trust store.  I'm not sure why two sets of CAs are being sent down for *.php.net.  The one with the self signed cert is causing the issues.

Hmm, might be a CDN issue.

From what I see in the trust paths is that the path using the third and fourth certificate sent by the server is the one causing issues. Would just sending the first two certificates in the server-response possibly resolve the issue as that will always resolve to a trusted root-ca?

this is also a problem on Fedora 33

besides "Grade B" on https://www.ssllabs.com/ssltest/analyze.html?d=www.php.net&s=185.85.0.29&hideResults=on you clearly see 

Certificates provided 	4 (5114 bytes)
Chain issues 	Contains anchor

#4
Subject 	Certum CA   Not in trust store
Fingerprint SHA256: d8e0febc1db2e38d00940f37d27d41344d993e734b99d5656d9778d4d8143624
Pin SHA256: lzasOyXRbEWkVBipZFeBVkgKjMQ0VB3cXdWSMyKYaN4=
Valid until 	Fri, 11 Jun 2027 10:46:39 UTC (expires in 5 years and 9 months)
Key 	RSA 2048 bits (e 65537)
Issuer 	Certum CA   Self-signed
Signature algorithm 	SHA1withRSA   Weak, but no impact on root certificate

Is this still unresolved?

Still a problem on RHEL 8.4

curl -O --insecure https://pear.php.net/go-pear.phar

Still a problem, using Ubuntu 20.04

Same issue for me on Ubuntu 20.04.3 LTS.

When I run the command pear update-channels 
I receive the error:

Channel "pear.php.net" is not responding over http://, failed with message: Connection to `ssl://pear.php.net:443' failed:


I am attempting to install Image_Barcode2 and when I run the command:
pear install Image_Barcode2-0.2.3

I get Error:
 No releases available for package "pear.php.net/Image_Barcode2"
install failed

Which prompted me to run pear update-channels.

I can run other updates fine, and connect to other https sites fine. Does appear to be an issue with the certificate.

Updating channel "pear.php.net"
Channel "pear.php.net" is not responding over http://, failed with message: Connection to `ssl://pear.php.net:443' failed:
Trying channel "pear.php.net" over https:// instead
Cannot retrieve channel.xml for channel "pear.php.net" (Connection to `ssl://pear.php.net:443' failed: )

Hi,

Certificate expiry is set to yesterday. I'm thinking about all docker build pipelines currently failing all over the world <3

I could fix it in a CI pipeline by replacing the contents in /etc/ssl with the updated files. In my case, the application is stuck in php 7.0 and this was the only way to get the image building again:

```Dockerfile
FROM php:alpine AS cacert

FROM php:7.0-fpm-alpine

COPY --from=cacert /etc/ssl /root/ssl

RUN mv /etc/ssl/openssl.cnf* /root/ssl && rm -rf /etc/ssl && mv /root/ssl /etc/ssl \
  && pear update-channels \
  && pear upgrade
```

It's expired again!

It's expired again!

Well at least, the other *.php.net ones like bugs.php.net and pecl.php.net