Error in SSL handshake with a web service - chain violates basic constraints limit

Question

I am writing a program where we invoke a third-party SOAP web-service over HTTPS. I am currently receiving an error at the SSL Handshake stage and it fails with the following error - chain violates basic constraints limit.

The web-server is sending a certificate chain as follows:
LEAF - I1 - I2 - I3

My code is able to validate the chain as follows, as I have trusted all the certificates including root:
LEAF - I1 - I2 - I3 - R

However, the issue is that the Intermediate Certificate I3 has a pathLen of 1, but it has 2 intermediate certificates between Leaf (End-Entity) certificate and I3 itself, which is causing the issue.

How could this be resolved?

1. Do we need to ask the SOAP web-service host/provider to change the certificate configuration on their end?
2. Also, how is the server even sending a chain that violates the constraints?

More Information:

1. I1 (i.e. Intermediate CA 1) has DN Entrust Certification Authority - L1K

   Certificate can be downloaded from here: Download I1 ("entrust_l1k.cer") from Entrust Site

2. I2 (i.e. Intermediate CA 2) has DN CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

   Certificate serial number is 4a538c28 and Certificate can be downloaded from here: Download I2 ("entrust_g2_ca.cer") from Entrust Site

   Interestingly, this certificate has same DN and Issuer, but it is not being treated as a root certificate probably because it does not have Authority Key Identifier = Subject Key Identifier.

3. I3 (i.e. Intermediate CA 3) has DN CN=Entrust Root Certification Authority - G2, OU="(c) 2009 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

   I3 certificate has the same DN as I2 and is the issuer of I2, but I3 itself is issued by a different authority i.e. root CA, and has a serial number 51d34044. This certificate also has pathLen of 1.

   I cannot find this certificate on the entrust site, so I am pasting the contents here.

   -----BEGIN CERTIFICATE-----
   MIIE/zCCA+egAwIBAgIEUdNARDANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMC
   VVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0
   Lm5ldC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMW
   KGMpIDIwMDYgRW50cnVzdCwgSW5jLjEtMCsGA1UEAxMkRW50cnVzdCBSb290IENl
   cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE0MDkyMjE3MTQ1N1oXDTI0MDkyMzAx
   MzE1M1owgb4xCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgw
   JgYDVQQLEx9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQL
   EzAoYykgMjAwOSBFbnRydXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9u
   bHkxMjAwBgNVBAMTKUVudHJ1c3QgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
   eSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuoS2ctueDGvi
   mekwAad26jK4lUEaydphTlhyz/72gnm/c2EGCqUn2LNf00VOHHLWTjLycooP94MZ
   0GqAgABFHrDH55q/ElcnHKNoLwqHvWprDl5l8xx31dSFjXAhtLMy54ui1YY5ArG4
   0kfO5MlJxDun3vtUfVe+8OhuwnmyOgtV4lCYFjITXC94VsHClLPyWuQnmp8k18bs
   0JslguPMwsRFxYyXegZrKhGfqQpuSDtv29QRGUL3jwe/9VNfnD70FyzmaaxOMkxi
   d+q36OW7NLwZi66cUee3frVTsTMi5W3PcDwa+uKbZ7aD9I2lr2JMTeBYrGQ0EgP4
   to2UYySkcQIDAQABo4IBDzCCAQswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI
   MAYBAf8CAQEwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz
   cC5lbnRydXN0Lm5ldDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmVudHJ1
   c3QubmV0L3Jvb3RjYTEuY3JsMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF
   BwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L0NQUzAdBgNVHQ4EFgQUanImetAe
   733nO2lR1GyNn5ASZqswHwYDVR0jBBgwFoAUaJDkZ6SmU4DHhmak8fdLQ/uEvW0w
   DQYJKoZIhvcNAQELBQADggEBAGkzg/woem99751V68U+ep11s8zDODbZNKIoaBjq
   HmnTvefQd9q4AINOSs9v0fHBIj905PeYSZ6btp7h25h3LVY0sag82f3Azce/BQPU
   AsXx5cbaCKUTx2IjEdFhMB1ghEXveajGJpOkt800uGnFE/aRs8lFc3a2kvZ2Clvh
   A0e36SlMkTIjN0qcNdh4/R0f5IOJJICtt/nP5F2l1HHEhVtwH9s/HAHrGkUmMRTM
   Zb9n3srMM2XlQZHXN75BGpad5oqXnafOrE6aPb0BoGrZTyIAi0TVaWJ7LuvMuueS
   fWlnPfy4fN5Bh9Bp6roKGHoalUOzeXEodm2h+1dK7E3IDhA=
   -----END CERTIFICATE-----
   

4. R (i.e. Root Certificate) has DN CN=Entrust Root Certification Authority, OU="(c) 2006 Entrust, Inc.", OU=www.entrust.net/CPS is incorporated by reference, O="Entrust, Inc.", C=US.

   This certificate has serial number ‎45 6b 50 54 and can be downloaded from here: Download R ("entrust_ev_ca.cer") from Entrust site

Further info

• i1

  $ openssl x509 -noout -fingerprint -in entrust_l1k.cer
  SHA1 Fingerprint=F2:1C:12:F4:6C:DB:6B:2E:16:F0:9F:94:19:CD:FF:32:84:37:B2:D7
  

  Crt.sh link

• i2

  $ openssl x509 -noout -fingerprint -in entrust_g2_ca.cer
  SHA1 Fingerprint=8C:F4:27:FD:79:0C:3A:D1:66:06:8D:E8:1E:57:EF:BB:93:22:72:D4
  

  Crt.sh link

• i3

  $ openssl x509 -noout -fingerprint -in i3.cer
  SHA1 Fingerprint=9E:1A:0C:35:E7:14:B6:97:92:D0:90:B2:CC:4B:BA:45:83:3C:30:15
  

  Crt.sh link

• R

  $ openssl x509 -noout -fingerprint -in R.cer
  SHA1 Fingerprint=B3:1E:B1:B7:40:E3:6C:84:02:DA:DC:37:D4:4D:F5:D4:67:49:52:F9
  

  Crt.sh link

Answer 1

I3 is "link cert", meant to bridge across a Root CA rollover. Evidence:

 X509v3 Subject Key Identifier:
     6A:72:26:7A:D0:1E:EF:7D:E7:3B:69:51:D4:6C:8D:9F:90:12:66:AB
 X509v3 Authority Key Identifier:
     keyid:68:90:E4:67:A4:A6:53:80:C7:86:66:A4:F1:F7:4B:43:FB:84:BD:6

Those match up with the Subject Key Identifiers of your I2 and R respectively. For clients that are aware of link certs, it says "Hi, I am root cert 68:90:E4:.. and I will become root cert 6A:72:26:..". Pictorially:

LEAF <-- I1 <-- Rnew <-- link_Rold_to_Rnew <-- Rold 

As you point out, I2 is a valid root cert, so the pathLen basic constraints are fine here. Clearly, whatever client you are using to validate the certificate chain doesn't understand link certs.

I think there are two options:

1. Figure out why your client doesn't understand link certs and fix it.
2. Ask the SOAP web service maintainer to stop serving all 5 certs and only serve. LEAF <-- I1 <-- Rnew.

Though I suspect they have done that because some other client only has Rold in their trust store and needs the link cert to be there.

Answer 2

Trust for intermediates?

You wrote:

as I have trusted all the certificates including root

That sounds wrong. You don't usually explicitly trust intermediates. (You might however explicitly DISTRUST them if they get compromised.) Why do any chain building/verification at all then if you can just finish at the first intermediate up the chain?

Mixup with intermediate? Just wrong chain sent?

I've added some links to crt.sh to your question. And it seems that what you call "i2" is not an intermediate cert at all, but a root cert. Is this a mistake? => See crt.sh

You wrote that it's not "treated as a root certificate". How can you tell? -- I think the chain that is being sent is just wrong/not up to spec.

=> Try checking with https://www.ssllabs.com/ssltest/ -- This will alert on chain irregularities.

Also: I looked this up: According to RFC 5280 not having an Authority Key identifier is allowed for roots:

The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction.  There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted.