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…
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
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?
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.
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.
ReplyDeleteThanks again ...
I would like to read more about how to establish mutual auth SSL using Datapower
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...
DeleteHave a great week!
could you please elaborate on "mutual authentication is not always required to SSL traffic". this now really confuses me .
ReplyDeleteHey 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?
DeleteHi Bruno,
ReplyDeleteThis is the simplest and the best explanation I have found on SSL in datapower; absolutely to the point and makes perfect sense. Thanks!
We are glad it helped you! :-)
DeleteHi Bruno,
ReplyDeleteI 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.
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...
DeleteThe 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!
Hey Bruno,
ReplyDeleteThanks 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.
Hey Rana, I really hope that works. Yes, please keep me posted.
DeleteWhat's up with your DataPower?
Hi Bruno,
DeleteI 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
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.
DeleteI 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?
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.
DeleteI 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.
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.
DeleteHey Bruno,
DeleteFeel 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.
Hi Bruno -
ReplyDeleteOnce 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 ?
Hi!
DeleteAs 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!
Hi Bruno -
ReplyDeleteDataPower 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 ?
This is a very good question and I should have mentioned something about it in my original post (I will edit it later).
DeleteI 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.
Scenario 7:
DeleteReverse 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.
Hi Bruno,
ReplyDeleteNeed 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.
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.
DeleteHi 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.
ReplyDeleteRakesh, 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.
DeleteThanks Bruno,
ReplyDeleteSo 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.
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?
DeleteMy 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.
Hi Bruno
ReplyDeleteI 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.
Hey, I hope you are doing alright!
DeleteOkay, 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.
I have some confusion regarding ssl profile setup.
ReplyDeleteWe 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?
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.
DeleteTo 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!
Hi Bruno,
ReplyDeleteGreat 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
Thanks, Daniel!
DeleteI 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
Thanks for you feedback and insight Bruno. We're considering the use of different Ports on the same IP for both of the FSHs.
DeleteHave a great day too.
Hi Bruno,
ReplyDeleteI've a scenario to make a URL running on https needs to be proxy at datapower. For this I've created Frontside HTTPS handler and an SSL proxy profile in two way direction, Created Forward crypto profile with Validation and Reverse crypto profile with Identification (Both with Client Authentication is Optional OFF,Always Request Client Authentication OFF). All the configrations are up and running. When I tried to open the datapower provided URL it is an fault error saying "env:Client Internal Error". In the datapower logs it saying "Failed to establish a backside connection , Cannot establish SSL credentials (credential is NULL)". Please gide me how to overcome this issue.
Thanks in advance.
Ajay.
Hi Ajay, there could be many reasons for both of those errors to show up. Assuming you are talking about a Web Service Proxy service, an "Internal Error (from client)" error usually means that the payload you are sending to DataPower is not passing the schema validation, again, usually, there could be other reasons. How are you sending data to DataPower? Now as for the "Failed to establish a backside connection", that is another error happening during the handshake from DataPower and the backend server. Are you able to retrieve the certificate from the backend server when you hit its URL from your browser?
DeleteHi Bruno, Thanks for your reply. Instead of saying web service proxy I'm trying to make a site proxy(running on HTTPS). Since it is a site i'm not sending any data to Datapower and yes I'm able to get the certificate from the backend server.
DeleteSorry it took a little longer to get back to you this time, crazy days here! Can you clarify which DataPower service are you using for this then, is it a Multi-Protocol Gateway, a Web Service Proxy, an XML Firewall? DataPower here is positioned between your client and the website, correct? What is the use case, why are you using DataPower to proxy the website?
DeleteHi Bruno, I'm using Multi-protocol Gateway for this. The use case is like my datapower is in DMZ and I want to expose the site which is running in our local domain. So just to expose that site to out side world I'm doing this.
DeleteOkay, there could be multiple reasons for your page not showing up when you configure a MPGW to act as a proxy, if you enable debug log level you could find some hints there. A few things I can remember at the top of my head though... Make sure your HTTP Handler has the GET method enabled, that your MPGW is set to Pass-through on both Request and Response directions, and if you internal site has SSL certificates configured, that you configure at least an SSL Client Profile to handle the connection handshake for you.
DeleteAlso, maybe a better service for you to use here instead of the MPGW, would be the Web Application Firewall. Have you considered using that?
Thanks for the update Bruno, I've enabled GET method,Pass-through and added the certificate for handshake as well. I don't have any idea on WebApplication Firewall I'll check that once.
DeleteDid those changes help you? For more information on the WAF service, please visit https://www.ibm.com/support/knowledgecenter/SS9H2Y_6.0.0/com.ibm.dp.xs.doc/waf_introduction.html
DeleteThank you Bruno, found the process to implement in WAF service.
DeleteHi Bruno,
ReplyDeleteI am having an issue with Datapower being a client and traffic is over SSL. I have configured SSL proxy profile, and the direction is forward, with val cred configured. The handshake fails and the team of the server that I am connecting is claiming that the server SSL certificate is not in Intermediate or root CA. can you pleas let me know how to over come this issue.
Blogs and articles contribute to building an online presence and establishing authority in a particular field. Things To View While Using Free Internet They can help individuals or businesses gain recognition and credibility within their respective industries.
ReplyDeleteHi bruno
ReplyDeleteDoes the above explanation is also for the new server profile. If not then how to implement mutual authentication using server profile