/n software E-Business Integrator Credit Card Processing FAQ


Q: What are EDI and AS2? What do all of these funny acronyms stand for and what do they mean?

  • EDI - Electronic Data Interchange. It is a general term for the transfer of documents between trading partners, and the standards that are adhered to. It is also represented as EDIINT (EDI over the Internet).
  • AS2 - Applicability Statement 2. A specific secure transportation standard for EDI, namely EDI over HTTP.
  • S/MIME - Secure Multi-Purpose Internet Mail Extensions. It is the set of standards used for encryption and signing of a message/document. This governs not only the functions of signing and encryption, but also provides standards for the formatting of the final message so that a compliant reader will be able to easily identify the structure of the message.
  • HTTP - HyperText Transfer Protocol. It is a very flexible client-server protocol that is the backbone of the world wide web.
  • SMTP - Simple Mail Transfer Protocol. It is used to send email messages from one party to another.
  • FTP - File Transfer Protocol. It is a protocol governing file transfer and file management.

Q: What about AS1 and AS3?

Both are similar to AS2 in the three principles they adhere to, but the communication protocol is different in each. AS1 is EDI over SMTP, while AS3 is EDI over FTP. Both AS1 and AS3 are also supported in the IPWorks EDI, but are not discussed specifically in this FAQ.

Q: Why do we even need to use AS2? Isn't SSL supposed to be securing the data?

There are three primary purposes for the AS2 protocol

  1. Confidentiality - By encrypting a message, you are guaranteeing that only the intended recipient of the message will be able to decrypt it. This is also provided by an SSL communication, but only during the actual internet transfer. With AS2, the document itself is encrypted rather than just the transfer.

  2. Authentication - By signing a message, you are guaranteeing that only you could have sent this message to the recipient. This can also be provided in SSL by requiring client authentication.

  3. Non-Repudiation -By signing a receipt for the transaction, both parties have irrefutable evidence that the transaction has occurred. This functionality is not provided by SSL. In short, AS2 can allow two parties to communicate with each other without needing to vouch for the integrity of the other party (or their AS2 configuration).

Q: What is eBusinessReady (Drummond Group / DGI) Certification, and why is it so important?

The Drummond Group is an independent organization that provides e-BusinessReady certification for applications that claim to support AS2 standards. Rather than hold compliant applications to a public standard, Drummond Group goes one step further and certifies that every application in its certification program has undergone compliance testing with every other application in that same program. You can be certain that any two applications that are e-BusinessReady certified have already successfully communicated with one another in compliance testing. Moreover, many companies are requiring that their trading partners adopt a solution that is certified by the Drummond Group.

Q: What happens during this transaction anyway?

Technically speaking, you can use any X.509 certificate containing a private key, even a self-signed one . You will need to negotiate with your trading partner what kind of certificate that you can use. If your trading partner requires that your certificate be signed by a trusted authority, then you should obtain one from a Certificate Authority. Otherwise, you can use the CertMgr component in our IPWorks EDI toolkit to generate your own self-signed certificate. A demo application provided in the package can do this for you.

Q: What kind of certificate will I need? Should I purchase one from a CA (VeriSign, Thawte, etc.)?

Your trading partner should be providing you with a few details. Most importantly, you'll need the public key of your trading partners certificate, which will be provided to you in CER or PEM format. Your trading partner will also provide you with an AS2 Identifier (a name, really) to be used in you communication.

Q: What do I need to get from my trading partner?

    If you are an AS2 Sender:
  • The SigningCert properties are used to set your private key certificate.
  • The RecipientCert property is used to set the public key of your trading partner's encryption certificate.
  • The ReceiptSignerCert is used to set the public key of your trading partners' signing certificate. Quite often, this is the same certificate as the encryption certificate - check with your trading partner to be sure.
    If you are an AS2 Receiver:
  • The Cert properties are used to set your private key certificate.
  • The SignerCert property should be set to the public key for your trading partner.

Q: When one of these properties calls for a certificate, what do I use?

    If you are an AS2 Sender:
  • The SigningCert properties are used to set your private key certificate.
  • The RecipientCert property is used to set the public key of your trading partner's encryption certificate.
  • The ReceiptSignerCert is used to set the public key of your trading partners' signing certificate. Quite often, this is the same certificate as the encryption certificate - check with your trading partner to be sure.
    If you are an AS2 Receiver:
  • The Cert properties are used to set your private key certificate.
  • The SignerCert property should be set to the public key for your trading partner.

Q: When I'm asked to use a private key, how do I set it? What are my choices?

    You're given 4 choices to use for your private key:

  1. PFX File

    Using this choice allows you to specify a PFX file (may also be a p12 extension) for the certificate. The advantage to this approach is that it is not necessary to install the certificate. You will need to specify the following properties:

    1. CertStoreType
      Set to "sstPFXFile"
    2. CertStore
      Set to the path and name of your PFX file
    3. CertStorePassword
      Set to the password for your certificate (leave blank if you do not have a password)
    4. CertSubject
      Set to the subject of the certificate. The special value "*" can be used as well to pick a random certificate from the file. Most pfx's will only have one private key certificate (although you can have multiple), so "*" is a good value if you are certain there is just one certificate.
  2. PFX blob

    Using this option allows you to use a certificate directly from memory. This is a valuable option for those who do not intend to store the certificate at all on the machine. You will need to set the following properties:

    1. CertStoreType
      Set to "sstPFXBlob"
    2. CertStore
      Set to the string representing the certificate. If this string is not Base 64 encoded, you will want to use the CertStoreB property in .NET to hold a binary value.
  3. User/Machine certificates (.NET only)

    Windows allows you to install certificates on your machine, in your registry. User certificates are certificates that have been installed for the given user account, while machine certificates are installed for use in any account. You will need to set the following properties:

    1. CertStoreType
      Set to "sstUser" or "sstMachine"
    2. CertStore
      Set to the name of the certificate store. Most commonly, private keys are kept in the "My" store, but you can configure it otherwise.
    3. CertSubject
      Set to the subject of the certificate. The special value "*" can be used as well to pick a random certificate from the store. Unless you know you have only one certificate installed in that store, you'll want to set the subject explicitly.
  4. JKS Store (Java only)

    In Java, your certificates are always kept on file. You will need to set the following properties:

    1. CertStoreType
      Set to "sstUser"
    2. CertStore
      Set to the path and name of your certificate store
    3. CertStorePassword
      Set to the password for your certificate (leave blank if you do not have a password)
    4. CertSubject
      Set to the subject of the certificate. The special value "*" can be used as well to pick a random certificate from the store, but again, unless you know you have only one certificate installed in that store, you'll want to set the subject explicitly.

Q: When I'm asked to use a public key, how do I set it?

These are going to be sent to you as .CER files or .PEM's. You can simply read the contents out of the file and assign it to the object. Public key certificates are either DER (binary) or Base64 encoded. It doesn't matter how your certificate is encoded - the object will recognize both types, but if you are using a DER encoded certificate in .NET, you will want to assign the value to the byte array property (RecipientCertB, SignerCertB, etc.) to account for all the bytes.

Q: What should I be setting for AS2 Identifier?

Your AS2 Identifier can be negotiated with your trading partner, but there's no standard for this. Common practices include your name, your company's name, or some other unique name. The only thing you really need to worry about here is to keep it consistent - your trading partner is going to look as this and be able to tell that it refers to you.

Q: Should I do a synchronous or asynchronous MDN?

This is something that you can negotiate with your trading partner, but it is generally left up to the sender to specify (A receiver that implements the AS2 protocol must be prepared to do whatever the sender indicates here). The difference between the two is notable:

A synchronous transaction is one in which the receipt that confirms the arrival of a document is sent over the same connection that was established to send the document. This is generally the easier of the two to configure, and is best to use when the expected response is going to be near immediate.

An asynchronous transaction is one in which confirmation of the arrival of a document is sent over a separate connection, one that is determined by the sender. This is going to be useful when the document transferred is larger or may take more time to process, because the same connection does not need to be left alive while processing continues. This requires a bit more work from the sender, at least during set up, because a means of receiving these receipts must be set up (a web server or mail server), and the retrieval of the receipts needs to be coordinated with the sending program.

Copyright © 2024 /n software, Inc.
Contact
Terms of Use
Privacy Statement