Support for 2-way-SSL (Client Certificate) in webMethods.io B2B

#b2b #ssl #client #tutorial

2-way SSL certificate (client certificate) can be defined as a digital certificate used to authenticate the identity of the partner user. A 2-way SSL certificate ensures the B2B server that it is communicating with a legitimate partner user.

Contrary to SSL certificates, 2-way SSL certificates are used to validate the identity of the partner user. Simply put, it works as a password, but without any intervention/input from the user. This way, the B2B server makes sure that it’s connecting to the permitted user and that party is safe to communicate with.

Now you might be wondering ‘Don’t passwords do the same thing?’ Well, sometimes passwords are not good enough. We often fall prey to password cracking techniques such as brute-force attacks and keyloggers. That’s why passwords are no longer sufficient when you have some really highly sensitive B2B document.

So, there might be some documents or files that you want only designated people to access. But as passwords are not secure enough, you’ll have to explore your options. That’s where 2-way SSL certificates come in. Instead of validating people via only passwords, 2-way SSL certificates authenticate people by the systems they use. If the user doesn’t have the granted permissions, he/she won’t be granted access resources. To make it even more secure, B2B enforce you to combine the use of 2-way SSL certificates with passwords. In technical terms, this is called ‘Two-factor Authentication.’ It is an absolute must for organizations dealing with sensitive data –both internal as well as external. And you know what happens when you don’t employ two-factor authentication?

Now that we know about 2-way-SSL , let us explore how we can configure and setup 2-way-SSL in webMethods.io B2B. Let’s assume two tenants namely swag and acme, behaving like a sender-receiver pair.

Create these assets on tenant SwAG to configure inbound 2-way-SSL capability:

NOTE: Inbound 2-way-SSL is only supported for channel type AS2-IN, HTTP-IN and RNIF-IN.

Design-time assets created on tenant SwAG:

Enterprise → SwAG(Sender) with ID types DUNS(123456789) and EDIINT AS2(SwAGAS2)
Partner → Acme(Receiver) with ID types DUNS(987654321) and EDIINT AS2(AcmeAS2)
Channel → Acme_http_in

Create the partners between which the documents have to be exchanged In this case, SwAG (Enterprise) and Acme (Partner) are created with Identity Types DUNS and EDIINT AS2.
Create partner user and associate it with the partners In this example a partner user with name ‘acme_user’ is created and associated with the partner.
Create an inbound channel of type HTTP-IN for receiving the Document from partner Acme and associate with it
Generate or upload 2-way-SSL certificate for the partner Acme
Prepare a test client like (Postman, Insomnia) to post the data to endpoint. Here in this example, i will use Insomnia. Now test the configuration without 2-way-ssl to ensure everything is working as expected. Since everything is working without 2-way-SSL, let us try with 2-way-SSL. > NOTE: For 2-way-SSL to work, you will need to add port 8443 in the endpoint generated (as part of result of the inbound channel configuration).

Without 2-way-SSL certificates configured
With 2-way-SSL certificates configured

Create these assets on tenant Acme to configure outbound 2-way-SSL capability:

NOTE: Outbound 2-way-SSL is only achievable through channel type AS2-OUT and HTTP-OUT.

Design-time assets created on tenant Acme:

Enterprise → Acme(Sender) with ID types DUNS(987654321) and EDIINT AS2(AcmeAS2)
Partner → SwAG(Receiver) with ID types DUNS(123456789) and EDIINT AS2(SwAGAS2)
Channel → SwAG_http_in, SwAG_http_out

Create the partners between which the document needs to be exchanged In this case, Acme (Enterprise) and SwAG (Partner) are created with Identity Types DUNS and EDIINT AS2.
Create Partner users and associate it with the partners Partner user with name ‘swag_user’ is created and associated with the partners.
Create HTTP-OUT outbound channel for sending the Document from partner SwAG and associate with the enterprise. Here we will use the HTTP-IN channel endpoint and partner user of partner Acme from tenant SwAG. > NOTE: Ensure SSL in config(only for HTTP-OUT) is enabled so that B2B can set SSL certificate configured while posting data to outbound endpoint.
Submit a payload to emulate the document exchange between the sender-receiver pair Post an EDI 850 payload over the HTTP Inbound channel Endpoint URL, with following request information.

curl --request POST \
--url https://{subdomain}.int-aws-us.webmethods.io/b2b/routes/channel/{channelId}\
--header 'Authorization: Basic {base64 encodedString}' \
--header 'Content-Type: application/edi' \
--data 'ISA*00* *00* *01*222222222 *01*777777777 *020226*1534*U*00401*000000009*0*T*>~
GS*PO*SENDERGS*007326879*20020226*1534*1*X*004010~
ST*850*000000009~
BEG*00*SA*A99999-01**19970214~
REF*VR*54321~
ITD*01*3*1 **15** 16~
DTM*002*19971219~
DTM*002*19971219~
N1*BT*BUYSNACKS INC.*9*1223334444~
N3*P.O. BOX 0000~
N4*TEMPLE*TX*76503~
N1*ST*BUYSNACKS PORT*9*1223334445~
N3*1000 N. SAMPLE HIGHWAY~
N4*ATHENS*GA*30603~
PO1 **16*CA*12.34** CB*000111111*UA*002840022222~
PID*F **** CRUNCHY CHIPS LSS~
PO4*48*7.89*LB~
PO1 **13*CA*12.34** CB*000555555*UA*002840033333~
PID*F **** NACHO CHIPS LSS~
PO4*48*8.9*LB~
PO1 **32*CA*12.34** CB*000666666*UA*002840044444~
PID*F **** POTATO CHIPS~
PO4*72*6.78*LB~
PO1 **51*CA*12.34** CB*000874917*UA*002840055555~
PID*F **** CORN CHIPS~
PO4*48*8.9*LB~
PO1 **9*CA*12.34** CB*000874958*UA*002840066666~
PID*F **** BBQ CHIPS~
PO4*48*4.5*LB~
PO1 **85*CA*12.34** CB*000874990*UA*002840077777~
PID*F **** GREAT BIG CHIPS LSS~
PO4*48*4.56*LB~
PO1 **1*CA*12.34** CB*000875088*UA*002840088888~
PID*F **** MINI CHIPS LSS~
PO4*48*4.56*LB~
CTT*7~
SE*35*000000009~
GE*1*1~
IEA*1*000000009~
'

Configure the SSL certificate in Enterprise Acme with the 2-way-SSL certificates generated in SwAG tenant preparation (in step 4). To convert the download certificate in desired format, run following steps on terminal. > NOTE: The default password for download cert is changeit.

openssl pkcs12 -in {partnerName}.pfx -nocerts -nodes -out key.pem
openssl rsa -in key.pem -out server.key
openssl pkcs12 -in {partnerName}.pfx -out mycerts.cer -nokeys -clcerts

Also, change the outbound channel port which we created from 443 to 8443.

Now post the data, (follow the same steps mentioned in step 4 of this section).

Troubleshooting

400 Bad Request

If certificate is not passed as part of requests, you will get the error 400 Bad request as shown in image below. This error can also appear if you are sending certificate’s not known to software AG infrastructures.