1

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

  • 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.) – StackzOfZtuff Jul 28 '18 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 Jul 29 '18 at 7:03
3

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.

  • 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? – StackzOfZtuff Jul 28 '18 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) – Mike Ounsworth Jul 28 '18 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? – StackzOfZtuff Aug 5 '18 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? – Mike Ounsworth Aug 5 '18 at 14:10
0

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 Aug 4 '18 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. – StackzOfZtuff Aug 5 '18 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 – StackzOfZtuff Aug 5 '18 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? – StackzOfZtuff Aug 5 '18 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.