aka free, phony code-signing certificates.
Code signed by a real
real certificate gives you strong assurance that code was
written by whom it claims to be, and that no one has tampered with it since.
Code signed with a phony certificate does not even guarantee that no one has
tampered with the software since the original, effectively anonymous, author wrote it, since someone else could
have re-signed it with a different phony certificate.
Do you have to buy a digital certificate to let Applets bypass security? Yes and no. You can create
yourself a free phony certificate with Keytool, or analogous tool for other types of
certificate. It lets you run the signed Applet. However anyone can make a phony certificate with your name
on it. It is marked as self-issued, rather than vouched for by Verisign or Thawte. Users out in the world
would/should refuse to grant your Applet special privilege, since there is no guarantee you actually wrote the
Applet and that it has not been tampered with. However, a phony certificate is useful for debugging while you
await your real certificate to arrive — which can take months of farting about.
The hassle with using phony certificates is that they must be manually pre-installed on all the client’s
machines before your signed Applets will be recognised. With real certificates,
that step is not necessary. The built-in signing authority root certificate suffices. It is pretty awkward to
pre-install certificates for the general public. Phony certificates are more feasible for strictly in-house
use.
In theory, a self-signed certificate should suffice to authenticate code on your own website. Who else could
have created the certificate? The need for validation only really comes into play verifying code floating about
the net purportedly from you. A real certificate allows that verification, even without checking in any way with
your website. In contrast, a digital signature with a phony certificate proves absolutely nothing.
Most users don’t understand even the most basic facts about certificates. They are thus overly
frightened of self-signed certificates. So you will likely end up buying a real one eventually.
See signtool or keytool for details of how to create
a phony certificate.
To create phony SMIME email authentication certificates in Windows use:
Why You Want A Real Certificate
- A phony certificate gives no more protection than an unsigned Applet would have. It gives only the illusion
of identification and security. The only time it has any security at all is when the certificate has been
imported into the cacerts. or certificate repositories of all your clients by some
secure means. It is easy to forge a phony certificate with any company’s name on it that you please.
Unfortunately, the general public is unaware of this, and treat phony certificates with too much esteem. Phony
certificates should be trusted equally to unsigned Applets. This is the reason I call them phony certificates rather that the exalted self-signed certificate.
They are logically equivalent to forged certificates. On the other paw, I sign my Applets and Java Web Start
apps with a phony certificate because I cannot afford a real one.
- You don’t have to install your real certificate on client machines. The "factory
"-installed authority root certificate suffices.
- There is no way to automatically install a phony certificate on the machines owned by the general public.
You have a catch-22. You need permission to install the certificate on local hard disk, but you need the
installed certificate to get permission.
- Phony certificates are only suitable for in-house use or for testing while you wait for your real one to
arrive.
- The public is less likely to trust a phony certificate and may refuse to run your Applet.
- Similarly customers may refuse to use your secure connection with a phony SSL (Secure Sockets Layer) certificate. If you are too
cheap to buy a cert, can you really be trusted with credit card numbers? Why don’t you want to present
your id? You are advertising yourself as fly-by-night and Mickey Mouse. I have devised a scheme for secure
transmission that does not rely on SSL certificates. See the
Transporter.
- You may accidentally give away your private key if you go around installing your certificate on many
machines. I know of no way to export a certificate from Netscape without including your private key.
Starting with Java 1.4.1 the status of phony certificates has been elevated. The user is merely warned if a copy
of your phony certificate is not in his cacerts. file. Previously you had to
find some way to get it there; now it is merely desirable to do so.
Limitation of Real Certificates
Even if you buy a real certificate, your clients will still have to OK your signed Applet to run. Why is this? Let’s say your signed Applet rummages
around the hard disk looking for thumbnail photos, and uploads them to a server. You need the client’s
explicit permission to do something invasive like that, not just
for a certificate.
Terminology: Phony or Self-Signed?
I prefer to use the openly pejorative term phony, where others prefer self-signed certificate. I do this to make people realise that a such a certificate is not really a
certificate at all, but a kludge to bypass the security mechanism for those who cannot afford a real certificate.
Casual users have almost no understanding them certificates. We need an emotion-laden term to help casual users
understand that self-signed code offers almost no degree of safety. Phony certificates are in nowhere near the
same league as real certificates.
A real certificate involves three levels of certification.
- the vendor certifies he did indeed write the software.
- the certificate vendor certifies that the vendor presented identification details to obtain the certificate
he used to sign the program.
- Sun, for Java code signing certifies (or the browser maker for SSL certificates), certifies that the
certificate vendor is a reputable company who takes sufficient care in handing out certificates to software
vendors. It indicates this certification by including the public root certificate of respected vendors in
cacerts..
In contrast, a phony certificate certifies that the holder of certificate he concocted himself did indeed write
the software. It says nothing about the identity of the vendor.
The Oxford dictionary defines certificate as an official document attesting or recording of a particular
fact or event, the level of achievement or the fulfillment of a legal achievement.
So it seems to me, there no official document involved with a phony cert. A phony cert is almost like a phony
degree hanging on the wall attesting to have completed a course of study at a non-existent university. It can be
used to deceive the unwary. A phony certificate is not actually a certificate in the Oxford sense. In contrast,
the term self-signed sounds completely legitimate, except for a faint whiff of
self-gratification. However, it is not completely valueless. For example, I post the public key of my phony
certificate on mindprod.com. People can then know whomever created mindprod.com also vouches for the signed code posted there, but they knew that anyway, without
the signing. It does, however, let people who pick up code elsewhere to know that also if they check the
posted root certificate, which is highly unlikely.
I expect, eventually, personal identification cards will be based on private keys. You will then be able
effectively to use your birth certificate/planetary ID for all manner of purposes, including purchasing goods and
signing code. Then there would be no need for unsigned code or code signed with phony certificates. I doubt the
law will continue to protect the right of criminals to harm others anonymously, even if it makes it more
difficult for people to perform legitimate deeds anonymously.