But the personal certificate has other uses, too - mainly in conjunction with email. You can use it to sign emails, using the S/MIME protocol. Mail clients like Thunderbird automatically append your certificate to signed emails, making it easy to verify the signature - just calculate a hash over the email message, decrypt the signature using the public key in the attached certificate, and if the two match, the message wasn't modified and it was sent by whoever has the private key that matches the certificate. Very easy, even for completely non-technical users.
And once you've received someone's certificate, the email client automatically places a copy in your certificate store. Since the certificate contains their public key, you can now encrypt emails that you send to them (assuming that you also have a private key and certificate. It's almost foolproof.
But now comes the $64,000 question: how does the recipient of a signed email know that they can trust the public key in the attached certificate? Of course, that's the whole point of a PKI (Public Key Infrastructure): you can trust the certificate to identify an entity because the certificate is itself signed by a Certification Authority. Of course, for an inexpensive certificate like the Class 1 Persona Not Validated ones, all it really means is that the person who bought the certificate was able to collect it via a link in an email sent to them by the CA, proving that they can access the email postbox.
But to check the validity of the certificate signature itself, we need the public key of the CA. No problem - browsers and email clients have those public keys built in, in the form of self-signed root certificates. We explicitly trust the root certificate, and given that, we know we can trust any certificates signed by it (actually, signed by the private key that corresponds to the root, but the terminology gets pretty lax, as we'll see).
And so that is how it has been, since time immemorial. Each year, I have renewed my certificate and dutifully backed it up from Firefox, then imported a copy into Thunderbird and used the new one.
Last year, I even taught the details of this as part of a university class on Cryptography and Information Security, and I set the students an exercise - get yourself a free Class 1 personal certificate from Comodo, send me a signed email, exchange signed emails with other students, start sending each other encrypted emails, then obtain my certificate from the VeriSign Digital ID directory (or directly import it from a file) and send me an encrypted email. It all went swimmingly well, with no problems.
This year, lots of problems - albeit a good opportunity for learning, for my students. First of all, I forgot to upload my new certificate, and the old one had obviously expired. But even when I exported and uploaded the new, current, certificate, they still couldn't import it into Thunderbird. Typically, they would get an alert dialog:
This is not cool. Now, I knew the certificate was perfectly valid. I even opened it using the Windows Crypto Shell Exensions on my desktop machine, and here's what it looked like:
Looks fine to me. Clicking on the "Certification Path" tab reveals that the certificate isn't directly signed by a VeriSign root certificate - rather, it's signed by an intermediate CA certificate and that one is signed by the root:
But here's how it looks on my Windows 7 machine:
What's this? "... not enough information to verify this certificate"? Let's have a look at the "Certification Path" tab:
The issuer of the certificate could not be found. Hmm. Remember, I'm looking at the Windows certificate store, here, not the Firefox or Thunderbird one - they were fine because I'd been using that cert with Thunderbird on that machine for the best part of a year with no problems. But it looked as though the Windows certificate store was missing one or other, or both, of the Verisign CA certificates. So I went into the Firefox Certificate Manager and exported both the required certificates, noticing as I did so that the VeriSign Class 1 Public Primary Certification Authority - G3 certificate was a Builtin Object Token (distributed as part of the browser) while the VeriSign Class 1 Individual Subscriber CA - G3 certificate was stored in the Software Security Device - i.e. it had been imported separately.
Now, it was over to the Windows 7 machine, and the Certificates MMC snap-in. To run this, use Start -> Run, type in "mmc.exe" to start MMC, then use File -> Add/Remove Snap-in, Select "Certificates" and add to "Selected snap-ins", select "My user account" and click OK. A quick inspection revealed that the VeriSign Class 1 certificates weren't there, but right-clicking almost anywhere and choosing "All Tasks" -> "Import..." allowed them to be imported successfully.
Once this is done, my personal certificate shows up correctly on the Windows 7 desktop:
Now, the students were experiencing problems importing my certificate into Thunderbird, but I bet it was the same problem - missing Verisign root and intermediate signing certificates. I've sent a couple of them the certificates as described above, and I've also sent others my certificate exported from Thunderbird using the "X.509 Certificate with chain (PEM)" format, which puts all three required certificates into a single .crt file. I'm waiting to hear back from them, but I'm expecting success.
All this is complicated by some terminological inexactitudes in the industry and the software used. One has to be careful to distinguish between Firefox/Thunderbird's "Backup...", which exports both the certificate and the corresponding private key in PKCS #12 (.p12) format, which displays in a Windows folder as a certificate with a key in front of it. You don't want to give anyone else this file, as it contains your private key (albeit password protected). It's mainly useful for exporting your key and certificate from Firefox and importing it into Thunderbird or other applications. So, a "certificate file" may not contain just a certificate! (This is almost as egregious an error as the old man page for OpenSSH, which used the word "certificate" to mean "private key"!)
On the other hand, if you want to give someone else your public key, in the form of a certificate, you have to "View..." the certificate, click on the "Details" tab and then choose "Export...". At this point, one can choose PEM (.crt - appears as a certificate) or PKCS #7 (.p7c - appears as a rolodex card) format, with or without the certification chain.
But the real problem is that VeriSign - now part of Symantec - appears to be backing, slowly, and without notifying their customers, out of the personal certificate or Digital ID business. They are no longer distributing their Class 1 root and intermediate certificates with Firefox or Thunderbird, or with Windows. What's worse, my students have not been able to download my certificate from the Verisign Digital ID directory. It's there (as are records for my previous certs going all the way back to May 1997!) but there are no links or buttons to do anything with it. No-one can download it, and it looks as though I'm not going to be able to renew it - although without distribution of the CA certificates in email clients, it's of dubious value anyway.
By contrast, Comodo not only offers free Class 1 personal certificates, but also operates the SecureZIP Global Directory where you can place your certificate for use with the PKWare SecureZIP utility. And their Class 1 CA certificates are more widely distributed than Verisign's, making them less prone to problems.
So, if you've been experiencing problems with your VeriSign Class 1 certificate, perhaps you now know why. And if, like me, you've been paying for your certificate for the best part of 20 years, you'll join me in saying:
Thanks for nothing, VeriSign.
No comments:
Post a Comment