TLS Certificate chain not accepted when registering

### Description

When joining an iSHARE Test Network (which is based on HLF Fabric), the provided certificate chain for TLS certificates that will be used by the peer nodes is being rejected. This is caused by the start/end date of one of the intermediates being wider than the start/end date of its issuer.
The certificate has been bought from a commercial vendor (Sectigo), so we can expect that they deliver a valid certificate + validation chain.
Running `openssl verify ...` against the certificate + ca chain shows `OK` responses for each certificate.

Is it correct and expected that Hyperledger considers this chain invalid, or should Hyperledger work in line with the way browsers and openssl verify works, and accept this certificate chain as valid for TLS connections?

Details of the certificate + chain (DNS names redacted):

```
../scripts/summarizePem.sh fullChain.pem
Inspecting fullChain.pem

cert_0.pem contains:
subject=CN=
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
notBefore=Apr 4 00:00:00 2024 GMT
notAfter=Apr 5 23:59:59 2025 GMT

cert_1.pem contains:
subject=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
issuer=C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust ECC Certification Authority
notBefore=Nov 2 00:00:00 2018 GMT
notAfter=Dec 31 23:59:59 2030 GMT

cert_2.pem contains:
subject=C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust ECC Certification Authority
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
notBefore=Mar 12 00:00:00 2019 GMT
notAfter=Dec 31 23:59:59 2028 GMT

cert_3.pem contains:
subject=C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
notBefore=Jan 1 00:00:00 2004 GMT
notAfter=Dec 31 23:59:59 2028 GMT
```

### Steps to reproduce

_No response_