Skip to Content

403 Forbidden error in a Secured B2B (EDI XI) connection


In a B2B scenario secured connection is expected between the parties. Whenever there is a secured connection, establishing the connectivity is cumbersome to a level.  We have experienced similar issues in our project. Once all the developments are in place, our prime responsibility begins.  We get a mail from the sender, informing that they received 403 forbidden error at their end and we have to hunt for different documents and links. We have to go through all the configurations to verify the missing link. I would like to share this experience by proving a few bridges to this gap.

We are working on EDI XI scenario, hence I may use some EDI related terminology in the following content. 

First I will talk about the purpose of the various certificates involved in the communication.

SSL certificate

Secure Socket Layer (SSL) is a security protocol that enables secure TCP/IP-type connections. Transport Layer Security (TLS) is a further development of SSL and an official Internet standard.

The server certificate contains the complete domain-address of the server as information on its owner. During the setup of a TLS/SSL-connection, the server sends its server certificate to the client (only possible with asynchronous encryption); checks the certificate and disconnects, if it does not trust the server certificate.

*Receiver’s AS2 certificate. </p><p> </p><p>In order to send a confidential message to a receiver, the message is encrypted with the receiver‘s</p><p>public key. Thus, the message can only be decrypted with the receiver’s private key.</p><p> </p><p>Sender’s AS2 certificate.</p><p> </p><p>By examining message signatures, a receiver can check whether a message was sent by a certain</p><p>sender and whether the message has been modified.</p><p>In order to sign a message signature the sender encrypts the electronic finger print of the message</p><p>with his private key. The receiver decrypts the finger print with the sender’s public key and compares</p><p>the received finger print with the message’s self-created finger print.</p><p> </p><p>Figure 1 displays the handshake between the partners in a B2B communication.</p><p>!|height=497|alt=image|width=688|src=|border=0!</p><p> </p><p>Potential reasons for failure of communication and their solutions are mentioned below.</p><p>Reason 1:- when the partner sends the data to receivers XI server, partner receives a positive acknowledgement if the connection is established successfully. In case the connection is dropped, one of the reasons can be that the SSL certificate applied at the senders end is incorrect or has lost its validity. Inform the partner to check the SSL certificate at its end.</p><p>Reason 2:-  * second reason can be w.r.t. the receiver’s AS2 certificate at partners end. Partner has to verify the validity (expiry date) and authenticity of receivers AS2 certificate.

*Reason 3:- Also verify the validity (expiry date) and authenticity of the partners AS2 certificate at receivers end.</p><p>Reason 4:- In case of EDI XI connectivity, Partner has to send the data to the correct URL.</p><p>https://<host>:<port>/SeeburgerAS2/AS2Server</p><p> </p><p>There are high chances of incorrect host or port, and this may lead to 403 forbidden error at senders end.</p><p>Reason 5:- *Sender provides his AS2 Id which is to be used in the Party defined in Integration Directory.

                In case of EDI, we use Seeburger adapter in XI. Hence In your party, create an entry against Agency Seeburger with a scheme as AS2ID and give the partner AS2 ID in the name column. Please note that all the fields are case sensitive.The AS2 ID is unique and hence only one party can have partner’s AS2 ID. Hence if you have more than one interface with the same Partner make sure you use the same party. If this AS2 ID is incorrect partner will receive 403 forbidden error.


*Reason 6:- Also provide your Partner with your own AS2 ID and ensure that he applies it in a correct manner.</p><p>Reason 7:-  *In the sender agreement that is created for the party , give the Partners public key name (AS2 certificate) in the authentication certificate field as shown in *figure 3. *Also give the receiver’s Private Key in decryption key and signing key. Also ensure that there is only one sender agreement for the corresponding Sender and Receiver Party.


You must be Logged on to comment or reply to a post.