4/06/2014

DataPower: How to configure SSL mutual authentication?

That should be a mandatory question when interviewing a DataPower candidate if you want to give him/her a hard time. I can say that most of them will fail to answer it correctly based on my experience in the field.

It is not entirely their fault though. The way that DataPower presents the objects responsible for configuring mutual authentication can be tricky if you are trying to learn it by yourself.

The main reason that could lead us, DataPower professionals, to a confusion is the fact that the SSL Proxy Profile object has a parameter called “Direction” that can be set as “Forward”, “Reverse” and “two-way”. 

Is “two-way” and mutual authentication the same thing?


The first impression is that the “two-way” option could be a representation of mutual authentication, it is because the definition of mutual authentication suggests that both client and server authenticate to each other, or in other words, they perform two-way authentication.

Although it could make sense, setting the direction to “two-way” has nothing to do with the set up of mutual authentication. SSL mutual authentication is independent of the SSL Proxy Profile direction parameter. You can perfectly have mutual authentication using Forward or Reverse as the direction, there is nothing wrong with that.

The “two-way” direction simply enables DataPower to act as a client or server using a single SSL Proxy Profile. And that is all, no mutual authentication here!

But then how to configure mutual authentication in the box, device, appliance (or whatever you may call it)? The answer is, as usual: it depends…

DataPower acting as Server


If DataPower is acting as the server and you want it to authenticate the client certificate, you can set the direction parameter of the SSL Proxy Profile to “Reverse”, and then on the Reverse Crypto Profile, you have to set up a Validation Credential that will contain a copy of the client certificate (or root CA) to be validated against.

Ah, now it starts to make sense on why the Validation Credential is not a required parameter on the Reverse Crypto Profile, and it is just because mutual authentication is not always required for SSL traffic.

08/25/2015 UPDATE: This is actually the most basic way to configure the Reverse Crypto Profile to authenticate its clients. There are many variations to this configuration and depending on your requirement, you can make your mutual authentication scenario mandatory or optional.

See below some variations of all the possible configurations and an explanation of each scenario:

Scenario 1:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.


Scenario 2:

Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.


Scenario 3:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.


Scenario 4:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.


Scenario 5:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.


Scenario 6:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.


Scenario 7:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.


Scenario 8:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:Client certificate will be asked because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL connection will be established as the option Client Authentication is Optional is set to ON, however the authentication may fail during the Processing Policy.
Mutual Authentication is optional.


DataPower acting as Client


Now, when DataPower is acting as Client, it is a different story… For this case, you are going to choose the direction “Forward” on the SSL Proxy Profile and then on the Forward Crypto Profile you will have to set an Identification Credential object to force DataPower to identify itself to the backend it is calling. Simple like that!

At this point, you might also have noticed that in the Forward Crypto Profile, the Identification Credential parameter is not required, once again because mutual authentication is not always required to SSL traffic.

Why then SSL Proxy Profile “two-way”?


So, you could be asking yourself now, why in earth do we have the option of “two-way” direction in the SSL Proxy Profile, is it just to confuse us?

Well, there is actually a plausible reason for that… Some of us fight everyday to keep our DataPower configuration as simple as we can, having this “two-way” option allow us to have a single SSL Proxy Profile referring to one Reverse Crypto Profile and one Forward Crypto Profile at the same time. It basically means less objects to be configured, yay!

Once all of them are configured correctly, you will never have to worry about which crypto object to select in order to allow a front or backside connection to be established properly, as the “two-way” object will automatically select the correct Crypto Profile (Forward or Reverse) to use according to the direction of the transaction.

So now, if you had a chance to give a different name for the “two-way” direction of the SSL Proxy Profile, what would that be?

06/23/2015 UPDATE: As of firmware version 7.2, DataPower is deprecating the Proxy Profile object. This object must be replaced by the SSL Server Profile or the SSL Client Profile, depending on whether DataPower is acting as a server or as a client. In addition to these two objects, there is a new object called SSL SNI Server Profile, which enables the SNI (Server Name Indication) feature. In short, the SNI feature on the SSL Client Profile will send the intended host name as part of the SSL handshake process with the server, so that the SNI-enabled server can select which certificate it should return to the client, given that the server is hosting multiple domains in the same IP and port combination.

For more information on the SNI feature, go to https://en.wikipedia.org/wiki/Server_Name_Indication.
For more information on the new SSL Client Profile, go to https://www.youtube.com/watch?v=nMud8cnd56w.
For more information on the new SSL Server Profile and the new SSL SNI Server Profile, go to https://www.youtube.com/watch?v=14DPPjl4u5w.

33 comments:

  1. I'm extremely impressed with this article and it really helped me to understand the direction in dataPower much clearly rather then mixing it up with 1 way SSL or mutual auth SSL.
    Thanks again ...
    I would like to read more about how to establish mutual auth SSL using Datapower

    ReplyDelete
    Replies
    1. We are glad it helped you, Ashish. Do you have any further questions on mutual authentication using DataPower? We may be able to assist you...

      Have a great week!

      Delete
  2. could you please elaborate on "mutual authentication is not always required to SSL traffic". this now really confuses me .

    ReplyDelete
    Replies
    1. Hey Swapnil, most websites that use https do not required mutual authentication (eg Gmail, Facebook, etc), even though the traffic is totally encrypted (SSL traffic). Mutual authentication takes place only when the server requires the client certificate to establish the connection. Makes sense?

      Delete
  3. Hi Bruno,
    This is the simplest and the best explanation I have found on SSL in datapower; absolutely to the point and makes perfect sense. Thanks!

    ReplyDelete
  4. Hi Bruno,
    I have a situation, I am trying to connect Datapower with Message Broker(IIB 10.0) with 2 way ssl connection, DataPower is client, so I have configured Forward Crypto profile with Validation Cred and Id Cred.
    My issue is how to verify that configuration in IIB has done correctlly with datapower cert.
    The issue am facing is if am putting different datapower cert/key pair in ID Cred then what is installed in IIB, still it is creating a connection.
    Kindly Help me out with the same.

    ReplyDelete
    Replies
    1. Hey Rana, sounds like IIB is not configured to require the client certificate, as regardless the certificate you use in DataPower, it will accept the connection anyway...

      The easiest way I find to test this scenario is by referring to the Broker URL in your browser (if it has connectivity to it), if the browser pops up a window asking to enter your certificate, then the Broker is configured correctly, otherwise, if it accepts the connection without any pop up, it is incorrect.

      If you want to verify how it is set in the Broker configuration, you can issue the following command:
      $ mqsireportproperties -e -o HTTPSConnector -n clientAuth
      false
      BIP8071I: Successful command completion.

      If it shows "false", as above, your HTTPSConnector is not configured to require client certificates.

      To change this you can issue the command:
      $ mqsichangeproperties -e -o HTTPSConnector -n clientAuth -v true
      BIP8071I: Successful command completion.

      You may have to restart your Integration Server for the change to take effect.

      If you need help configuring the keystores/truststores on the Broker side, you can refer to this InfoCenter page "Configuring SOAPInput and SOAPReply nodes to use SSL (HTTPS)" (http://www-01.ibm.com/support/knowledgecenter/#!/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ap34021_.htm).

      I hope it helps!

      Delete
  5. Hey Bruno,
    Thanks a lot for understanding the issue and giving the solution for the same. I will let you know over the outcome.
    Please let me know if you can help me out in DataPower Admin related issue.
    Thanks,
    Gautam.

    ReplyDelete
    Replies
    1. Hey Rana, I really hope that works. Yes, please keep me posted.
      What's up with your DataPower?

      Delete
    2. Hi Bruno,
      I am facing isuue with the transcation list in datapower Box.
      I am not able to see any transaction list when I am enabling the Probe. even the services is working Fine its not visible in the probe.
      In "View Log" tab I am able to see all the exection but it is not showing up in the Probe window .

      This issue am facing with all the services, I even tried looking the the Probe in the services in the other domain in the same datapower box , but still not able to see the probes.

      The probe were visible some time back but now its not.

      Because of this issue I am not able to do the debugging of my services.

      Please help me out in fixing this.
      Thanks,
      Rana

      Delete
    3. Hey Rana, it might be a bug with DataPower I suppose, as you mentioned that even when the service works fine, you are still not seeing it. In this case I would open a PMR with IBM for further investigation.
      I have seen the Probe not showing up any information when failures happen before the request reaches the processing policies, for example when it fails the SSL handshake. This is per design.
      What about the exceptions you see in the logs? Don't they explain why the transactions are failing?

      Delete
    4. Hey Bruno, I have got a solution , I changed my Probe setting to "Unbound" , so now am able to see the probes, but this is the temp solution as it may have a performance issue.
      I am planning to open the PMR in case i am not able to get the permanent solution.
      Please let me know if u have any solution for the same.
      Thanks,
      Gautam.

      Delete
    5. Hey Gautam (I'm sorry, do you prefer I call you Rana or Gautam? I have seen you signing with both so I am confused now...), great idea on setting it to "Unbounded", and it is crazy that now you can see the probes again, I am glad you can though! How about if instead of "Unbounded" you set it to "On", and then you change the "Transaction History" from the default "25" to "26"? Does that make any difference? Either way, opening up a PMR with IBM sounds like the best approach here.

      Delete
    6. Hey Bruno,
      Feel free to call me by any name ..:). I prefer people call me Gautam.
      I have change the transaction history but then transaction list is not visible.
      Going forward I am planning to open a PMR for the same.
      Thanks for you valuable input. Will touch base with you with my other DataPower questions.
      Thanks,
      Gautam.

      Delete
  6. Hi Bruno -

    Once the Validation credentials are set up in DataPower, would that mean that mutual authentication is now mandatory for all services that use that SSL Proxy Profile ?

    ReplyDelete
    Replies
    1. Hi!

      As long as DataPower is acting as a server and the Validation Credentials are established in a Reverse Crypto Profile, then yes.

      Have a good day!

      Delete
  7. Hi Bruno -

    DataPower acts a server, yes. There is a HTTPS FSH listening on 443. Validation Credentials are set up to contain a list of certificates of each of the trusted partners . However the following two options on the SSL Proxy are confusing , a bit :

    Client Authentication is Optional : On
    Always Request Client Authentication: Off
    Would this still mean that any communication coming in on 443 , mutual auth is mandatory ?

    ReplyDelete
    Replies
    1. This is a very good question and I should have mentioned something about it in my original post (I will edit it later).

      I totally agree that these two options add even more confusion to the equation, and part of it is because of some fine adjustments you can make in order to support some specific scenarios, for example...

      Client Authentication is Optional should be turned on when you want to make the Mutual Authentication something optional for your clients. It should be turned off when you want to enforce Mutual Authentication.

      Now, as for Always Request Client Authentication, you may want to turn it on when you don't have a ValCred configured in the Reverse Crypto Profile, but you still want the client certificate to be validated further down on the processing flow, meaning instead of performing the validation of the client certificate using the ValCred, you will validate it in a AAA action in your Processing Policy.

      There are a few combinations to make the SSL Mutual Authentication mandatory, optional, or not required. I could imagine 8 total possible scenarios, yours being #3 (optional, and not mandatory as I assumed earlier this week):

      Scenario 1:
      Reverse Crypto Profile WITH ValCreds
      Client Authentication is Optional OFF
      Always Request Client Authentication OFF
      Results:
      Client certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
      Mutual Authentication is mandatory.

      Scenario 2:
      Reverse Crypto Profile WITH ValCreds
      Client Authentication is Optional OFF
      Always Request Client Authentication ON
      Results:
      Client Certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
      Mutual Authentication is mandatory.

      Scenario 3:
      Reverse Crypto Profile WITH ValCreds
      Client Authentication is Optional ON
      Always Request Client Authentication OFF
      Results:
      Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
      Mutual Authentication is optional.

      Scenario 4:
      Reverse Crypto Profile WITH ValCreds
      Client Authentication is Optional ON
      Always Request Client Authentication ON
      Results:
      Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
      Mutual Authentication is optional.

      Scenario 5:
      Reverse Crypto Profile WITHOUT ValCreds
      Client Authentication is Optional OFF
      Always Request Client Authentication OFF
      Results:
      Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
      Mutual Authentication is not enabled.

      Scenario 6:
      Reverse Crypto Profile WITHOUT ValCreds
      Client Authentication is Optional OFF
      Always Request Client Authentication ON
      Results:
      Client Certificate is required because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
      Mutual Authentication is mandatory.

      Delete
    2. Scenario 7:
      Reverse Crypto Profile WITHOUT ValCreds
      Client Authentication is Optional ON
      Always Request Client Authentication OFF
      Results:
      Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
      Mutual Authentication is not enabled.

      Scenario 8:
      Reverse Crypto Profile WITHOUT ValCreds
      Client Authentication is Optional ON
      Always Request Client Authentication ON
      Results:
      Client certificate will be asked because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL connection will be established as the option Client Authentication is Optional is set to ON, however the authentication may fail during the Processing Policy.
      Mutual Authentication is optional.

      Delete
  8. Hi Bruno,

    Need some help reagrding SSL proxy profile (forward) in dataPower. When i am creating a ssl proxy profile direction - Forward , i am able to create it without validation credential i configured only "identification credential "and the object status also 'up' it's not giving any error also. But as i understand while creating a ssl proxy profile with direction (datapower acts as client) validation credential should be mandatory.
    Can you please help me to understand this.

    ReplyDelete
    Replies
    1. Hey Rakesh, this is a very good question! The only reason why the Validation Credentials is not a required parameter in this scenario, is because the SSL/TLS standard does not require authentication of the server certificate. It is rare, but there are cases out there that the client is not required to validate the certificate sent by the server, like when the agreed-upon key exchange method is anonymous. See more details at https://www.ietf.org/rfc/rfc2246.txt.

      Delete
  9. Hi Bruno , thanks for your clarification. So we can create SSL Proxy profile with (Forward (Client) Crypto Profile) which is having no validation and identification credential. Even in real time i have seen that Forward (Client) Crypto Profile has been created without validation and identification credential. So particulary in that scenario what is the use of creating such ssl proxy profiles ? is that ssl proxy profile be ussl handshake . Can you please let me know.

    ReplyDelete
    Replies
    1. Rakesh, I might be mistaken, but other than the rare case I mentioned above, I don't see any other situation which doing this would help with something, as an empty validation credential basically means that DataPower is not validating any certificate at all.

      Delete
  10. Thanks Bruno,

    So to understand this . Whenever Data power is having empty validation(Certificate of calling server) credential in Forward crypto profile we are not checking the server at all. But still the SSL/TLS encryption will happen between DataPower and the calling server . Is my understanding correct?
    And one more point i want to understand like. When ever Datapower is having the certificate in validation credential in forward crypto profile , is that certificate contains servers public key as well? i have checked many public certificate i have seen there is field call "public key" is that is so whenever the ssl handshake use to happen between client and server Server sends the public key along with the server Hello message.
    Can you please help me out to understand those points.
    Thanks for your help.

    ReplyDelete
    Replies
    1. You wrote: So to understand this . Whenever Data power is having empty validation(Certificate of calling server) credential in Forward crypto profile we are not checking the server at all. But still the SSL/TLS encryption will happen between DataPower and the calling server . Is my understanding correct?
      My response: Just in a few rare case that I explained above it will be true. In most of the cases the connection should fail saying that the backend server is not trusted by DataPower.

      Whenever you try to access a TLS/SSL server, yes it will reply with its public key. You then try to validate whether this public key matches to the public you have stored in your ValCred.

      For more information on the SSL handshake I would recommend you to read this excellent article: http://blogs.msdn.com/b/kaushal/archive/2013/08/03/ssl-handshake-and-https-bindings-on-iis.aspx

      And just to be clear, all certificates contain a public key. The difference between a certificate and a public key is that the certificate not only contains the cryptographic material, but also some extra information regarding who the issuer is, the CA that signed the certificate itself, addresses, names, and of course, the public key. During the TLS/SSL handshake, the server always send its certificate (including the public key in it) as part of the Server Hello message.

      Delete
  11. Hi Bruno

    I am developing a web service in DataPower which is trying to connect the salesforce endpoint. The Salesforce endpoint is https secured with mutual authentication implemented.

    In order to make connection to SalesForce from DataPower service i would need to create SSL Forward profile with both ID Cred and Val cred. The ID cred would have data power cert private key as crypto key and data power cert as crypto cert. These key and certs can be extracted from P12 cert. The Val cred would have cert installed at salesforce end for mutual auth . Please advice if this SSL setting will work to establish the connectivity.

    ReplyDelete
    Replies
    1. Hey, I hope you are doing alright!

      Okay, here it is what you are doing:

      - Have a SSL Forward Crypto Profile - Check
      - IDCreds and ValCreds are configured in the Forward Crypto Profile - Check
      - IDCreds contain DataPower certificate pair (private and public) - Check
      - (I am assuming that you extracted the DataPower certificate pair (private and public) from the P12 file and converted them into 2 .pem files, as that is the format DataPower accepts. I am just not sure why you have a P12 to start with as DataPower generates .pem files in the Crypto Tools, unless you generated the certificate pair out of the DataPower box, then it would be okay)
      - Salesforce need to add a copy of your public DataPower certificate into their trust store - Not sure if it is done
      - You need to add Salesforce public cert or Root CA certificate into your ValCred - Not sure if it is done

      If you have done all the above, your SSL configuration should be alright. If even so you are still getting errors, make sure that there is connectivity to the server and port you are trying to connect to and that there is match in Ciphers used by both client and server.

      You can get other ideas by reading what Dan Zrobok wrote on Debugging DataPower TLS / SSL Errors at http://www.orangespecs.com/datapower-tls-ssl-errors/

      Your last resort would be a Packet Capture, then you would be able to tell for sure what is really going on.

      Good luck to you, debugging these issues are not always fun, specially if you don't have access to all tiers to make sure that everything is setup the way they should have been.

      Delete
  12. I have some confusion regarding ssl profile setup.
    We just got the below setup from third party vendor.

    When Data Power is accepting the Client requests We have configured the reverse proxy and in this case we have set up both identification credentials and Validation credentials.Identification credential has the DP key as well as the signed certificate. Validation credentials has the client certificate whom ever trying to access the service from Data Power.Do we really need to share the Data Power certificate with the Clients in case of reverse proxy?

    ReplyDelete
    Replies
    1. Your configuration seems to be okay, but yes, sharing the DataPower certificate with your clients is still required, because they will use that to encrypt the data before they send it to DataPower. If they have access to your DataPower endpoint they can grab this certificate themselves, without requiring you to manually send them by email, etc... They can use a browser to hit your DataPower endpoint and they could use the export certificate function from the browser.

      To validate whether DataPower is enforcing the client certificate (it can require it and still be optional if it is not configured well) or not, from your browser hit the DataPower endpoint and see if there is a pop up asking you to select your personal certificate. Cancel that pop up without specifying any certificate, and then see if the connection fails. If it does fail you should be good. Then try again selecting a certificate that matches a certificate in the Validation Credentials (you may have to restart your browser to see that pop up again). The connection should succeed this time.

      Good luck, let us know if you have any further questions!

      Delete
  13. Hi Bruno,
    Great article.


    Quick question, is it possible to have two FSH for the same Message Policy that both listen to the same IP and Port?

    I'm guessing they must at least have a different one of either!

    Obrigado
    Daniel

    ReplyDelete
    Replies
    1. Thanks, Daniel!

      I am afraid it is not possible to have two (or more) FSHs listening on the same IP/Port combination. This combination has always to be unique across the box. It is possible though to have multiple FSHs listening to the same Port, but with different IP addresses. We did that for a client a few years ago when their requirement was to host multiple lower environments in the same box.

      Have a good day!
      Bruno

      Delete
    2. Thanks for you feedback and insight Bruno. We're considering the use of different Ports on the same IP for both of the FSHs.

      Have a great day too.

      Delete