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.

    -----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

  • Your link for "R" seems to be wrong. The downloaded cert has a different serial number. Could you fix this? (I first thought I broke the link when I edited your question. -- But it was already broken in your old revision.) Commented Jul 28, 2018 at 17:22
  • @StackzOfZtuff - I have updated the link for "R" and also added Crt.sh link for "R" certificate. Also, thank you for the edit.
    – abhishek
    Commented Jul 29, 2018 at 7:03

2 Answers 2


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

 X509v3 Subject Key Identifier:
 X509v3 Authority Key Identifier:

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.

  • I’m confused. Are you saying that in this case it’s the client’s fault for enforcing the path length constraint for that particular chain construction? If yes, per what spec? Commented Jul 28, 2018 at 6:31
  • @StackzOfZtuff For enforcing the path length constraint incorrectly: pathLen is the number of allowed intermediates before you hit a root, and I2 is a root. Come to think of it though, I'm not sure if Entrust-style link certs are in an RFC, or something that only Entrust clients understand. I'll need to get back to you on that one (I usually deal with closed infrastructures of our own products) Commented Jul 28, 2018 at 13:17
  • What’s a “link cert”? Is that the same as a “cross cert”? In that case I’d say: “nope, i3 is not a cross cert and the chain is just wrong because it contains two roots.” Wrong train of thought here? Commented Aug 5, 2018 at 9:39
  • @StackzOfZtuff I don't know the exact specs of link and cross certs off the top of my head, no I can't get into an argument about it. I thought it was the same as a cross cert where the Subject and Issuer DN were the same. What if I'm presented a regular cross-cert chain EE <- I1 <- R1 <- cross <- R2 where R1 is already in my trust store? Commented Aug 5, 2018 at 14:10

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. 
  • Could you please explain why is trusting an intermediate cert incorrect? The tool we use validates the chain being sent from the server and also validates if the intermediate certs are trusted (present in the local trust store). 2. You are correct about i2. It does appear to be a valid root cert (as mentioned in my original post), but since the server is sending an i3 after i2, hence my tool is not recognizing it as a root cert (this is what I meant by i2 not being treated as a root). As you said, either the chain is invalid or as Mike explained, maybe my tool does not understand link certs?
    – abhishek
    Commented Aug 4, 2018 at 23:01
  • Well you’ve abandoned a usual aspect of the PKI concept here. You usually declare some certificates as “trust anchors” and set explicit trust for them. Then later in actual use you will encounter a subordinate certificate of some kind that you will need to make a trust decision on. Because you don’t know if you should trust it or not yet. And then you try to build a chain (or verify a given chain) that starts in the new cert and should end in one od your explicitly trusted trust anchors. And never touch anything explicitly distrusted along the way. You’re DONE when you reach a trust anchor. Commented Aug 5, 2018 at 9:24
  • Now the non trusted (not the same thing as “distrusted” mind you) intermediates that you might need as additional pieces of the puzzle (if and only if you need to construct the chain yourself and not if you want to verify a given one) you’d keep in a seperate set. So you’d have these seperate sets: explicitly-trusted (“trust anchors”), explicitly-distrusted, untrusted-intermediates. And what you’ve done is that you have placed intermediates that should have gone in the untrusted set in the trusted set instead. — When you construct a chain to a trusted cert you’re DONE. “Link”crt? PleaseRecheck Commented Aug 5, 2018 at 9:35
  • @abhishek: 1. see above re. intermediates. 2. Also: what does SSL-Labs say about the chain? 3. And the guy on the server side. What’s his explanation for having two roots in that chain? Commented Aug 5, 2018 at 9:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .