The CurrCon Java Applet displays prices on this
web page converted with today’s exchange rates into your local international currency,
e.g. Euros, US dollars, Canadian dollars, British Pounds, Indian Rupees…
CurrCon requires an up-to-date browser
and Java version 1.8, preferably 1.8.0_131.
If you can’t see the prices in your local currency,
Troubleshoot. Use Firefox for best results.
aka free, phony code-signing
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
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 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
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
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
certificates. See the
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
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
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.
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 whoever 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
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.