As digital certificates are wont to do, mine was set to expire. The content for this article stems from a recent renewal experience...
As it ought to be, acquiring a code-signing certificate from a CA (Certificate Authority) is a non-trivial exercise. For individuals like myself, part of the process includes proving my identity. This entails producing multiple forms of government-sanctioned ID in front of a notary. The signed and notarized document is then sent to the CA where they go though additional steps to verify both my and the Notary's identity. Only after the process is complete, will a certificate be generated and released.
For the past few years, I've used Comodo, one of many reputable CAs, for my certificate needs. When receiving a certificate, to effectively use it, you'll not only need the code-signing certificate and private key, but also the certificate chain, and certificate alias. We leave cursory pointers to most of these components for your edification. The intent of this article is to focus on the certificate alias.
A certificate alias provides a means to identify certificates in a human-readable fashion. With respect to the Java ecosystem, it enables developers to take advantage of certificate related utilities like keytool(1) and jarsigner(1) which, in many instances, require furnishing the alias name as part of their command-line invocation. At issue here was the fact that Comodo's recent renewal made a slight change to the alias which had widespread ramifications.
As it arrived from Comodo, my original code signing certificate had a Comodo-generated alias associated with it, that looked like this:
jim connors's comodo ca limited id
Not the most elegant of names, but it works just fine. And besides, you could change it (e.g. with keytool) if you'd like. Fast forward to the summer of 2018, the most recent renewal included what appeared to be an insignificant modification to the original alias. It now reads:
jim connors?s comodo ca limited id
The culprit here is the ? character. It's not actually a question mark, but rather an alternative 16-bit character representation of the apostrophe (') character. In the Windows CMD.EXE shell, because this is a non-ASCII character, we see this question mark thingy. In reality the character in question has a hex value of 0x2019. This latest alias renders it difficult, if not impossible, to use within a Windows CMD shell.
So why not just change the alias then?
Great question. And as it turns out, keytool has an option to do just this. Unfortunately you need to specify the alias on keytool's command-line in order to so. And as it's difficult to represent this non-ASCII string in a CMD shell, what can you do? It's quite possible that non-windows environments (Linux, MacOS ...) may be more amenable to non-ASCII characters, but that fix would be way too easy. My solution: create a dopey application that can aid in modifying certificate aliases with these weird characters. The Java project can be found here:
The project includes a sample keystore (my.jks) with a certificate. Furthermore the certificate is assigned an alias with a non-ASCII character (jim?s self-signed cert). In the sample run that follows, the alias in question is selected and modified, eliminating the non-ASCII character from the original alias.
>java -jar ChangeCertAlias.jar
Keystore file: my.jks
Enter keystore password: changeit
Aliases in my.jks
1: jim?s self-signed cert
Select an alias number: 1
Enter the new certificate alias: jims self-signed cert
Name of new keystore file: new.jks
Enter key password: changeit
New keystore: new.jks created with updated alias: "jims self-signed cert"
The default keystore and key passwords are "changeit" for this example. Using this program on a real keystore will require that you know those passwords, which should almost certainly be different.