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

[Baijnath_Kumar1 (Baijnath Kumar)]

Introduction

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

Contrary to SSL certificates, 2-way SSL certificates are used to validate the identity of the partner. 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?^[1]

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.

Case 1: Inbound flow

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

1. Create the partners between which the documents have to be exchanged ^[2]
   In this case, SwAG (Enterprise) and Acme (Partner) are created with Identity Types DUNS and EDIINT AS2.
   

2. Create partner user^[3] and associate^[4] it with the partners
   In this example a partner user with name ‘acme_user’ is created and associated with the partner.
   

3. Create an inbound channel of type HTTP-IN for receiving the Document from partner Acme and associate with it^[5]
   

4. Generate or upload 2-way-SSL certificate for the partner Acme^[6]
   

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

Case 1: Outbound flow

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

1. Create the partners between which the document needs to be exchanged^[2:1]
   In this case, Acme (Enterprise) and SwAG (Partner) are created with Identity Types DUNS and EDIINT AS2.
   

2. Create Partner users^[3:1] and associate^[4:1] it with the partners ^[3:2]
   Partner user with name ‘swag_user’ is created and associated with the partners.
   

3. Create HTTP-OUT outbound channel^[5:1] for sending the Document from partner SwAG and associate^[7] 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.

   

4. 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~
   '
   

5. Configure the SSL certificate in Enterprise Acme with the 2-way-SSL certificates generated in SwAG tenant preparation (in step 4)^[8].
   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.
   

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

  

• 403 Forbidden

  If you are passing incorrect certificate, like which are not known to server you will get this error.
  

  

• 401 Invalid credentials

  For 2-way-SSL to work, you must provide 2-way-SSL certificate configured/generated along with the valid user credentials correctly.
  

  

• 401 Invalid or expired session identifier

  Your session expired. Send the document again to create the session.
  

  

References

---

1. Client Certificate ↩︎

2. Adding a Partner Profile ↩︎ ↩︎

3. Adding a Partner User ↩︎ ↩︎ ↩︎

4. Associating or Mapping a User with a Partner ↩︎ ↩︎

5. Creating a Channel ↩︎ ↩︎

6. Adding a 2-Way SSL/TLS Certificate for a Partner ↩︎

7. Associating or Mapping an Outbound Channel with a Partner ↩︎

8. Adding a Certificate Set for a Partner ↩︎