DataPower

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

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

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Tue June 22, 2021 08:00 AM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Tue June 22, 2021 08:00 AM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Tue June 22, 2021 08:00 AM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Wed June 23, 2021 05:45 AM
From: Pierce Shah
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 08:00 AM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Thu June 24, 2021 02:55 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Wed June 23, 2021 05:45 AM
From: Pierce Shah
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 08:00 AM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

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

Original Message:
Sent: Thu June 24, 2021 03:07 PM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Thu June 24, 2021 02:55 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Wed June 23, 2021 05:45 AM
From: Pierce Shah
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 08:00 AM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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

Original Message:
Sent: Tue June 22, 2021 03:29 AM
From: Hermann Stamm-Wilbrandt
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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/

Original Message:
Sent: Mon June 21, 2021 03:20 PM
From: Peter Potkay
Subject: DataPower and Root Signer Certs - Is DPWR not compliant with RFC 5264

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