DataPower

  • 1.  DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    IBM Select
    Posted Mon June 21, 2021 03:20 PM
    In an SSL Client Profile, in its Val Cred, if you select  "Full certificate chain checking (PKIX)", in the Help you fill find this statement: "The complete certificate chain is checked from subject to root when using the validation credentials for certificate validation. Validation succeeds only if the chain ends with a root certificate in the validation credentials". So, DataPower expects the SSL Partner, the SSL Server, to include the Root in the chain.

    In RFC 5264 The Transport Layer Security (TLS) Protocol Version 1.2
    https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2
    certificate_list
    This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

    RFC 5264 says SSL Servers have the option to send the root or not.
    DataPower appears to require it.
    Is DataPower not compliant with RFC 5264 if it requires SSL Servers to send something RFC 5264 says is optional to send?

    Follow on question:
    What if another DataPower Service is the SSL Server. Going to that SSL Server Profile, to that Crypto Identification Credential we find:
    a field for Crypto key
    a field for Certificate
    a field for your Intermediate Cert(s)

    There is no field for the root cert. Make sense to me - RFC 5264 says SSL Servers do not have to send the root, so why should DataPower offer a field for it.  But back to my original question!  If DataPower as a Client requires SSL Servers to send the root when doing full chain checking, and DataPower can be a SSL Server to a DataPower SSL Client, where does IBM expect us to place the Root cert in that ID Cred?

    ------------------------------
    Peter Potkay
    ------------------------------


  • 2.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    Posted Tue June 22, 2021 03:29 AM
    Peter,
    what you state sounds valid, but I am not firm enough with SSL specs.
    Please create a support ticket for getting an answer/explanation/fix.

    ------------------------------
    Hermann Stamm-Wilbrandt
    Compiler Level 3 support & Fixpack team lead
    IBM DataPower Gateways (⬚ᵈᵃᵗᵃ / ⣏⠆⡮⡆⢹⠁⡮⡆⡯⠂⢎⠆⡧⡇⣟⡃⡿⡃)
    https://stamm-wilbrandt.de/en/blog/
    ------------------------------



  • 3.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    IBM Select
    Posted Tue June 22, 2021 08:00 AM
    Hermann,
    I do have a Case and we are going back and forth.  I posted here to get other experts' perspective.

    The initial response in the Case for DataPower requiring the SSL Server to send the Root was that the wording in the RFC spec (saying you MAY omit the Root in the chain) means DataPower is in its rights to require it. I don't see it that way. Requiring something that is officially optional seems to me DataPower is setting itself up for interoperability issue. Now as it so happens most systems do seem to send the optional root in the cert and so this hasn't been an issue. Yet.

    This came to my attention when I was reviewing someone's Crypto Identification Credential and noticed they jammed a Root cert into the Intermediate Certs box. I said that was wrong. They explained that was the only way they could get it to work. Why this one needed this and most others don't I asked?  Because in this case, the SSL Client to this MPG was another DataPower MPG that was requiring the Root in the chain. All our other SSL Client systems abide by the RFC and don't require DataPower to include the Root - only DataPower requires the Root. And then doesn't even offer us a clean way to provide it!  We have to jam the Root into a field clearly marked Intermediate Certs.

    DataPower requiring the Root in the chain - Defect? IBM will argue that its documented that it needs it, so working as (incorrectly?) designed. RFE to offer an option to not require the Root in the chain?
    DataPower not offering an obvious place to provide the Root in the ID Cred - Defect? Or RFE to add a field for the Root, or change the label for the existing field to say "Intermediate and Root Certificates" while adding verbiage to Help to explain?

    ------------------------------
    Peter Potkay
    ------------------------------



  • 4.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    Posted Wed June 23, 2021 08:22 AM
    Peter,

    Have you tried the following?
    • On the server side send everything but the root
    • On the receiver side make sure the root cert is in the trust store

    This way on the receiver side everything should be able to get checked. I would say on the receiver side add all the intermediaries and the root... but I am no expert on what the RFC says...

    ------------------------------
    Francois Brandelik
    ------------------------------



  • 5.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    Posted Wed June 23, 2021 01:44 PM
    Hi Peter,

    there either seems to be a slight misunderstanding regarding the documentation or we really have an issue i.e. a bug to be fixed.
    The server itself does not have to send the complete chain but the Crypto Validation Credentials object needs to have the complete chain.

    I completely agree with you that it doesn't make sense to provide the root CA certificate in the Crypto Identification Credentials object even though I have seen this out in the field. For cases where public CAs are involved it might be useful or even needed to add a "unknown" intermediate CA certificate. For internal use cases with a private PKI I usually never populate the "Intermediate CA Certificate" list. I rather add those intermediate CA certificates to the Crypto Validation Credentials object.

    Just to make sure that I got it right. You're saying that DataPower as a client expects the server to send the complete chain including the root CA?

    Furthermore, I just made a little test with a TLS Proxy Service connecting to an other DataPower appliance that uses a Crypto Identification Credentials object without sending the CA certificates (neither intermediate nor root). And the TLS Proxy Service itself uses a TLS Client Profile doing PKIX validation just using the intermediate and the root CA.
    That case worked fine with firmware 10.0.1.3!?

    ------------------------------
    Pierce Shah
    Senior IT Specialist
    IBM Schweiz AG
    Zurich
    ------------------------------



  • 6.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    Posted Wed June 23, 2021 01:44 PM
    Hi Peter,

    it shouldn't be needed to add the root CA certificate to the Crypto Identification Credentials object even though it would be possible and I have seen that out in the field.

    Furthermore, I made a test with a TLS Proxy Service connecting one DataPower with an other one, both running firmware 10.0.1.3, and this test was successful.
    The Crypto Identification Credentials object of the server didn't send any CA certificates and the Crypto Validation Credentials object of the client made PKIX validation using the intermediate and the root CA.

    ------------------------------
    Pierce | Switzerland
    ------------------------------



  • 7.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    IBM Select
    Posted Thu June 24, 2021 02:55 PM
    Thanks all. I expected it to work like this:
    Option A
    • SSL Server's ID Cred only has the Leaf and Intermediate Cert(s)
    • SSL Client's Val Cred only has the Root Cert.
    -or-
    Option B
    • SSL Server's ID Cred only has the Leaf Cert (this is NOT compliant with RFC 5264)
    • SSL Client's Val Cred only has the Intermediate Cert(s) and the Root Cert.

    So when I saw an ID Cred with a Root Cert, I questioned it. The developers I spoke with insisted it had to be that way. I opened a Case. I posted here. With you all seeming to agree with me, I went back to the developers. Now they say it works as Option A in the Lab when I asked them to try with a new implementation. OK, so next step is to go to the original implementation I spotted and starting in the DEV environment, delete the Root Cert from the ID Cred.  I will report back.

    After deleting the Root Cert from the ID Cred and saving the configuration what if anything needs to be restarted to ensure we are testing with that configuration and not some cached values from before our change?

    ------------------------------
    Peter Potkay
    ------------------------------



  • 8.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    Posted Thu June 24, 2021 03:07 PM
    To be sure changes are effective, I would restart the domain.

    ------------------------------
    Hermann Stamm-Wilbrandt
    Compiler Level 3 support & Fixpack team lead
    IBM DataPower Gateways (⬚ᵈᵃᵗᵃ / ⣏⠆⡮⡆⢹⠁⡮⡆⡯⠂⢎⠆⡧⡇⣟⡃⡿⡃)
    https://stamm-wilbrandt.de/en/blog/
    ------------------------------



  • 9.  RE: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

    IBM Select
    Posted Thu July 01, 2021 12:47 PM
    Hi Peter
                 ID Credential should have only Intermediate certificate. Root certificate is not required.​ We had do this setup in my previous company.Initially we used to only pin the leaf certificate in the ID credential. But later on we started added intermediate certificate. We can even add one or more intermediate certificate if necessary.
     
    Thanks a lot.
    Sasmita

    ------------------------------
    Sasmita Satpathy
    ------------------------------