In my last blog post, “SSL: What is “two-way” authentication?” I gave an overview of the types of authentication involved in an SSL communication. Now I’d like to talk about a recent customer implementation that required SSL two-way authentication, an authentication issue that we encountered along the way and the troubleshooting that went into getting this issue resolved.
In this implementation project, our customer was going to be setting up EXTOL’s EBI application to communicate with a third-party electronic invoicing vendor. One of the requirements was that the communication with the vendor would be done over SSL using two-way authentication. Because EXTOL was doing the initial communications/connectivity implementation and setup on behalf of our customer, the vendor sent an electronic form for us to fill out. One of the main pieces of information that the vendor required was the IP address from which we would be communicating. This was important because the vendor specifically only allowed incoming communications through their firewall from approved/authorized IP addresses. Once that was set up, the vendor supplied us with a certificate that identified their server. EBI was then configured to trust their server certificate, and that part of the setup was completed.
Next, I needed a certificate to provide to the vendor. This would be considered the client certificate. I generated a self-signed certificate, provided it to the vendor, and they configured their server to trust that client certificate. At that point, everything was taken care of in terms of the SSL and the necessary certificates. I completed the implementation and setup, tested that everything was working well between my testing instance of EBI and the vendor’s server, and was confident that everything was in working order.
At that point, I transferred the completed pieces and components of the project to our customer. At the time of this transfer, the vendor had our customer fill out the same form that specified our customer’s information including their IP address. The vendor also required a client certificate from our customer. Our customer then provided the vendor with a self-signed client certificate of their own, and the vendor reconfigured their firewall and server to accept connections from the customer’s IP address and no longer EXTOL’s.
It was at this point that the project ran into a bit of a snag. The SSL communication was not working. I went over our customer’s setup with a fine-tooth comb, making sure that everything was configured properly. It was. The customer and I spoke with our contact at the vendor to confirm that everything was configured properly on their end, and it was. So, if it’s configured right on our customer’s side, and configured right on the vendor’s side, why isn’t it working?
It was now time to break out the debugging tools to start to get to the bottom of this issue. The tools included Wireshark, which is a network protocol/traffic analyzer, and the SSL command-line debugging options that are available on the Sun Java 1.6 JVM. These tools proved their worth, but another critical part of troubleshooting this issue is the investigative process. By this I mean breaking out the detective cap, asking questions, looking for clues, basically searching for any kind of “lead” that might get us on the trail of solving this problem.
The first place we started was asking both sides, the customer and the vendor, what are you seeing when the communication is attempted? Our customer was getting a “bad_certificate” error, and the vendor said that they were getting an error about the certificate not being able to be validated. So, is the certificate data corrupt? We confirmed that the certificate was fine, so we needed to keep looking. As we continued tracking this issue down, we discovered that during the attempted SSL communication, the vendor was not receiving a client certificate at all from our customer. This was a big clue, but the thing about some clues is that you need to know how they fit into the puzzle. For that, let me take a step back and talk about how a server requests a client certificate during an SSL communication.
The initial part of the SSL communication session (identity authentication, encrypted communications session setup, etc.) is referred to as the “SSL handshake”. During the handshake, if the server is configured to require client authentication, it will issue a request to the client to provide a certificate. As part of that request, the server provides to the client a list of all of the Certificate Authorities and other entities that the server trusts. When the client receives this list, it can utilize it to determine whether the client has an appropriate certificate that the server will trust. If the client finds that it possess a certificate that the server trusts, it can provide that certificate to the server for authenticating the client. However, in the case where the client scans through the list and finds that it doesn’t possess any certificate that the server would trust, the client could either give up or attempt to continue the SSL handshake without providing a certificate. In this latter case, it is then for the server to decide whether or not to cancel the communication when the client has not provided a trusted certificate.
Thankfully, the SSL debugging command-line option that I mentioned allows you to see some of the details of the SSL handshake. Most importantly, it allowed us to see the list of trusted entities that the server provided to the client. When looking through that list, we noticed that our customer’s client certificate was not trusted. Another thing we noticed was that EXTOL’s testing certificate was still in the list. We surmised that back when I transferred things over to our customer and the vendor reconfigured their server and firewall to accept communication from our customer, somehow the client certificate had not gotten properly reconfigured. So the vendor corrected the misconfigured certificate and the SSL communication was able to work properly, just as expected.
By utilizing the available debugging tools, by asking questions and by doing some investigation, we were able to get this SSL authentication issue resolved to our customer’s satisfaction. I hope that in reading this you have gained a better understanding of how client authentication works in SSL and how to troubleshoot it if a problem ever arises.
Visit extol.com/webservices to learn more about two-way SSL authentication using EXTOL Business Integrator.