From fully managed EDI solutions to supply chain consulting.

SHA-1 vs. SHA-2 Digital Certificates – What’s All the Fuss About?

Topics: AS2, Data Security, EDI considerations, EDI Software
Photo appears courtesy of F Delventhal.

Many of you probably know about the new requirements coming regarding SHA2 digital certificates.  Before we discuss that, let’s first look at SHA-1.  What is SHA-1?  According to Wikipedia, in cryptography, SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function designed by the United States National Security Agency and is a U.S. Federal Information Processing Standard published by the United States NIST. SHA-1 produces a 160-bit (20-byte) hash value known as a message digest.  A SHA-1 hash value is typically rendered as a hexadecimal number, 40 digits long.

SHA-1 is no longer considered secure against well-funded opponents.  In 2005, cryptanalysts found attacks on SHA-1 suggesting that the algorithm might not be secure enough for ongoing use, and since 2010 many organizations have recommended its replacement by SHA-2 or SHA-3.  MicrosoftGoogle and Mozilla have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017.

What is SHA-2?  According to Wikipedia, SHA-2 (Secure Hash Algorithm 2) is a set of cryptographic hash functions designed by the National Security Agency.  SHA stands for Secure Hash Algorithm. Cryptographic hash functions are mathematical operations run on digital data; by comparing the computed “hash” (the output from execution of the algorithm) to a known and expected hash value, a person can determine the data’s integrity.  For example, computing the hash of a downloaded file and comparing the result to a previously published hash result can show whether the download has been modified or tampered with.  A key aspect of cryptographic hash functions is their collision resistance: nobody should be able to find two different input values that result in the same hash output.

We are seeing a number of trading partners in the EDI world (i.e. Walmart, Kohl’s, VAN, etc.) taking a stance in the industry to convert their AS2 and SSL certificates from the SHA-1 to SHA-2 as their standard (seen as SHA256 in some applications) to protect their customer’s data.  Some are even requiring that their suppliers convert their own existing certificates to SHA-2 with stringent guidelines as to the expiration of such certificates.

What does this mean for all of us?  If you communicate via SSL and AS2 communications utilizing SHA-1 digital certificates, it is in your best interest to make sure your communications applications can accommodate your organization to not only load and use SHA-2 certificates for your connections, but also allow to you create your own SHA-2 certificates and use them as well. It is always best to check with your application vendors to ensure that your software applications support this transition, or there is a chance that your EDI communications will experience some downtime related to this if you do not upgrade or implement SHA-2 certificates going forward. You are going to start to see e-mail notifications from some of your customers notifying you to make this change relatively soon if you have not already.

Some software applications may require that you upgrade to the latest versions/builds to be ready to accommodate for this change.  Other software applications may require that you simply apply a patch to your current version of software.

This has major implications for the EDI world.  Make sure you are compliant or there could potentially be an interruption in communications for you with some of your most important trading partners.  Note that this may end up being a several-step process for you to be ready to accommodate them.  First, you may have to get your software applications current (builds/upgrades/patches).  Second, create your own SHA-2 certificates.  Third, install a customer’s SHA-2 certificates.  Fourth, perform some additional configuration to reference the new SHA-2 certificates in your environment.  Fifth, coordinate with other trading partners that may be affected with your certificate change as well.  Last but not least, test your connections both inbound and outbound.  This all involves proper planning and coordination so that you minimize your downtime, and you address any other affected trading partners as well. As we so often hear, change is really the only constant.  How we adapt to that change is what ultimately determines our success.

Do you still have questions about the wide world of EDI? Find the answers in our free eBook: EDI Implementation Made Simple

Documenting Your EDI Processes
Why Your EDI Processes Should Be Automated

This article was written by:

Related Posts

Contact GraceBlood—we’re here to help.