Encryption and decryption

The sender and receiver send data exclusively through the HTTPS protocol. Nobody in between is able to view these data.

We’ve added hashing and hash encryption (RSA) guidelines to ensure the sender is actually the person that created the message. In order for that to work sender and receiver act as follows.

The sender creates a certificate that belongs to a public domain and uses an RSA algorithm to do so. The private key is stored inside a pem file that is only accessable to the sender. The sender passes the public URL with the certificate to be used once to the recipient. He tells the receiver what url uses that certificate. The receiver can then load the public key from that public domain certificate.

This certificate can be used several times, until it is no longer valid. Just before this certificate expires, a new one will be created.

If the sender uses the API from edi4steel this whole setup is automatic and the public certificate that will be used is https://edi4steel.eu

In other words:

• If supplier Y uses the API to send messages to customer X, only customer X has to enter https://edi4steel.eu. The API will take care of hashing and encryption. Decryption and hash checking still has to be done on customer X side. See example code.

• If customer X send back messages through the API to the supplier Y then supplier Y can use the key from https://edi4steel.eu. The API will take care of hashing and encryption. Decryption and hash checking still has to be done on supplier Y side. See example code.

• If supplier Z does not use the API to send messages to customer X, supplier Z has to implement the setup process themselves.