Just as I was continuing to test my current server application, I bumped into another problem. This time it’s a little tricky, as it is something that only happens to Windows, while the other operating systems I tested (i.e Linux and Mac OS) worked perfectly fined. The problem this time concerns renewed certificates. In such cases, the server application only sends back a renewed PEM certificate, since the corresponding private key would have been bundled into a PKCS#12 for first time subscriptions and be imported into the relevant certificate store.
Since I was already developing in a Linux environment, we tested the renewal procedure there first. For Firefox, if the corresponding private key is already in their key store, then it could immediately be imported into their certificate store as the finished download is clicked on within the Firefox itself. On the other hand, Chrome only redirects to the “Manage certificates” page if the finished download is clicked on in the browser, it still had to be manually imported. It’s not too bad since the users do not always have to navigate through the settings and to that certificates page every time.
When I have Mac OS to test with, I could able to test out the renewal procedure there as well. MacOS have a certificate and keys management tool built-in to the system, it’s called KeyChain access. When a PKCS#12 file is clicked, the import wizard will be prompted, guiding users on the import procedure. The same is also done for PEM certificates. For renewals, it would even show the same private key that was imported along with the old certificate. When attempting to connect to the server application, both the old certificate (if not expired yet, happens for early renewals) and the new certificate will be prompted for the user to choose which certificate to authenticate with.
Now, the Windows problem is when the renewed PEM certificate does not get shown in the certificate prompt when attempting to connect to the server application. Usually, certmgr (Window’s own certificate management tool) would state that there is a corresponding private key to a particular certificate, if any. However, even with the old certificate and private key already in the store, the new certificate does not have such a message. For some reason, it’s unable to bind that same private key to the new certificate. If the new certificate was bundled as a PKCS#12 instead, then there would be no issues.
As of this time of writing, myself and Dr Shawn included still have not figured out what is the issue. It just so happens that Windows is widely used by people today as well, so this is quite an issue. For now, I have to lay down this project for awhile and move on to a previous project of mine, CRS. The Euroasia competition registration is starting soon, and there’s a few changes I need to make, so I need to set up example products again in the store that incorporates those changes, as well as having modifying the codebase to handle those changes.
0 Comments