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
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.