Java Glossary : certificate

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : C words : certificate.

certificate

How Certificates Work

A certificate is just a file, digitally signed by a signing authority. The certificate is like a cross between a

digital ID Smart-Card
a Notary Public's stamp
an electronic ID card issued by a private company who attests you are who you say your are and that certain facts you allege are true.
a signet ring used by kings in days of old to seal letters with wax.
a cheque-signing machine.
a tool to make documents very difficult to forge like the filigrees on currency and bonds.
A high tech Buck Rogers secret decoder ring.

It contains two parts, a private part only you know and a public part the world knows. You use it to stamp your work proving you authored it and that it has not been tampered with.

To verify a signature, you need only a certificate from the root signing authority installed in your certificate repository. These root certificates are typically pre-installed at the factory in browsers. You don't need to install a copy of the signer's certificate.

The signature consists of a digest of the material signed, an encryption of the digest using the signer's private key, the signer's name and public key, and the signing authority's name. You could not trust a signing authority's public key embedded in the signature. You must get that separately.

Certificates are primarily concerned with digital signatures, though they can be used for encryption. Certificates contain your public keys so that other people can encrypt the mail they send you so that if anyone intercepts it, they cannot make any sense of it. You can safely hand out your public keys to others since they do not contain your private keys. Unfortunately, Netscape includes your private key whenever it exports a certificate. You must be very careful not to let others discover it. The certificate-issuing authority at no time is privy to your private key. Your browser generates your random private key when you purchase your certificate, and sends only the public key to the certificate authority. The process of purchasing a certificate may require installing the certificate authority's public key in your browser, three visits to the certificate authority's website, and some email. Depending on the cost/class of the certificate, the certificate authority may need a substantial amount of time to check you out before issuing the certificate.

You need passphrases for your browser and for each certificate. If you forget a passphrase, you are totally hosed. You will never be able to use the certificate again. Thankfully, some certificates offer a hint (which you compose) in case you forget the passphrase.

For a technical overview of how the public and private keys work, see my essay on digital signatures 2004-06-28.

Where to Buy Digital Certificates

The prices here were updated 2004-04-20. Not all the prices were rechecked. Use these just for a ballpark. Check the websites.

Company	Types of Certificate Sold
Baltimore	SSL $349.00 USD per year, $249.00 USD to renew, PKI unicert
BelSign (Belgium)	personal email certificates(free), Netscape jar signing( $325.00 USD /year), Microsoft Authenticode( $325.00 USD /year), SSL or TLS Server( $185.00 USD /year)
BT TrustServices (British Telecom)	Verisign SSL server certificates 259.00 GBP , email and British Government services 53.00 GBP , PKI, Verisign Go Secure for Lotus Notes and Microsoft Exchange, Identrus PKI.
Certum	A Polish company offering over a dozen different types of certificate including code signing certificates. Code signing certificates are free for anyone involved in an open-source project. They also offer a free timestamping service to provide undeniable proof that digital data were not modified or backdated. Prices are higher than previously, e.g. €122.00 EUR for a code-signing certificate. See the pricelist.
Cren	Institutional Certificates, e.g. entire universities. Cost is per institution based on size.
CyberTrust (USA)	out of business.
Entrust (USA)	personal email certificates(free), Netscape jar signing(free), Microsoft Authenticode(free), SSL Server(free), VPN [Virutal Private Network] (free), SET (free). Free certs are 60-days for testing only. To use them you must first load the Entrust root authority cert into your browser.
Equifax/GlobalTrust.	SSL Server ( $159.00 USD /year)
GlobalSign	personal email certificates(free), Netscape jar signing( $325.00 USD /year), Microsoft Authenticode( $325.00 USD /year), SSL or TLS Server( $185.00 USD /year). These people use proprietary names for their certificates which makes it difficult to figure out which one you need.
Keywitness (Canada)	bankrupt
QualitySSL, neé InstantSSL	128-bit SSL certificate $129.00 USD per year.
netborge née KMD-CA. (Denmark in Danish).	The Opera browser supports this company. The site is in Danish. They produce four types of certificates: Server certificate: to say the web site really belongs to who it says it belongs to. It also enables encryption. The price for this is 5000.00 DKK for two years. . Company/business certificate: to be used to send for example automatic email reply from a company and this certificates that the email really came from that company or for the user to see it was the correct company who received the mail. I could not find a price for this. Employee certificate: Can be used to send 'secure' email. Also to be used for the company to assign 'roles' to employees. This is then a signature that the company certifies this employee is employed by the company and has this position in the company. It can also to used instead of user names and passwords in internal systems in the company. Personal certificate: To certify you are the person you say you are. I guess this is only for Danish citizens (because of validation reasons). free.
PGP Pretty Good Privacy/McAfee (USA)	Certificate server software you install issues PGP certificates.
SuperCert Hosting	SSL ( $85.00 USD /year) sell Thawte-based certs.
TC Trust Center (Germany in German).	personal email certificates, Netscape jar signing, Microsoft Authenticode, SSL Server, PKCS #11: Cryptographic Token Interface Standard, root trusted authority certs for your browser.
Thawte Certification (South Africa).	I like Thawte. They are friendly and co-operative. Personal email certificates(free), combined Netscape jar signing, Microsoft Authenticode and Java Plug-in versions 1.1, 1.2, 1.3, 1.4+,( $199.00 USD /year, $159.00 USD to renew), Read the overview of: Thawte Developer Certificates. There it states: Thanks to some wizardry in our development team a single Thawte Developer Certificate can now be used for software signing on different platforms and in different applications. This is salesmen's hyperbole. The truth is more complicated. For Developer Certificates, make sure you use Internet Explorer and request an Authenticode certificate. It can later be converted to the others. If you accidentally bought a Netscape certificate instead, all it not lost. It can be converted to an Authenticode one. Just export to PKCS #12 *.p12 format and import into Internet Explorer, or vice versa. If you bought one of the other types, you are out of luck. there are four types of code signing certificates: JavaSoft Developer Certificate: JavaSoft's JDK 1.3+ to sign Applets and Java Web Start. This is probably what you want. The others are obsolete. Netscape Code-Signing Certificate: These certificates are used to sign Java Applets, browser plug-ins and other active content on the Netscape Communicator platform, i.e. in the old days of Java 1.1 and 1.2. Microsoft Authenticode: (Multi-Purpose) Certificate These certificates are used with the Microsoft InetSDK developer tools to sign ActiveX controls, .CAB, .EXE and .DLL files. VBA Developer Certificate: These certificates are identical to Microsoft Authenticode certificates, and are used by developers to sign macros in Office 2000 and other VBA 6.0 environments. You can't interconvert Sun keytool certs to PKCS #12 because keytool refuses to either export or import a private key. It uses the same format for public certs. You can get around this restriction with tools from third parties e.g. BouncyCastle.org. Download one of the providers. You want to do this so you can import your full certs into other signing tools, like Netscape jarsigner. See Mitch Gallant's notes on exactly what to do. Basically you configure a little java program called BCMain to export the certificate in PKCS12 format using the BouncyCastle JCE. That exported file contains both private and public key. From there, you can import it elsewhere e.g. with keytool.exe. You can use a Netscape signing certificate for The Java plug-in 1.1 and 1.2, if you use the old Netscape RSA jar signing tool. For Java 1.3+, you need a separate RSA certificate. They no longer make Sun DSA-style certificates. This means another $199.00 USD ! The Thawte website is ambiguous about this, saying it requires a different type of certificate, but not that it requires a totally separate application process and fee. The fault lies not with Thawte, but with Sun, since Sun's keytool refuses to import or export private keys from the .keystore file. SSL Server( $199.00 USD /year), free email S/MIME and SSL test certificates. PGP certificates are no longer supported. Sadly, Verisign bought them out in 2000 February. Thawte is a much nicer company to deal with than Verisign.
VeriSign (USA).	Dealing Verisign is like dealing with IRS bureaucrats, very cold and businesslike. They are more set up to deal with large corporations than individual developers. Their website is well organised so you can quickly find the certificates you need and the prices. They offer personal email certificates( $15.00 USD /year), Netscape jar signing ( $400.00 USD /year), Microsoft Authenticode( $400.00 USD /year), Java Plug-in versions 1.1( $400.00 USD /year), 1.2(not available) and 1.3+ $400.00 USD /year), Visa SET. Verisign offers 6+ types of code signing certificates. They cannot be converted into each other. You have to buy multiple certificates if you need more than one type. JavaSoft Developer Certificate: JavaSoft's JDK 1.3+ to sign Applets and Java Web Start. This is probably what you want. The others are obsolete. Netscape Code-Signing Certificate: These certificates are used to sign Java Applets, browser plug-ins and other active content on the Netscape Communicator platform, i.e. in the old days of Java 1.1 and 1.2. Microsoft Authenticode: (Multi-Purpose) Certificate These certificates are used with the Microsoft InetSDK developer tools to sign ActiveX controls, .CAB, .EXE and .DLL files. Microsoft Office and VBA Signing Digital ID: Allows software publishers to digitally sign Macros for Office 2000, Office XP, and VBA objects. Macromedia Shockwave Digital ID Marimba Castanet Channel Signing Digital ID

Selecting a Vendor

Some criteria to consider when buying your certificate are:

cost, both initial and renewal.
Does the company provide all the different kinds of certificate you will need. It is much less hassle to get everything from one source.
Are the root certificates (code-signing or SSL) of that vendor built in to the browsers your clients will be using? If not, it will be a hassle for your users to manually install them.
What sort of reputation does the vendor have for service? Basically you are paying them to verify that you are you. You want them to do that thoroughly without driving you crazy.

I heartily recommend Thawte for four reasons:

They have low prices.
They have friendly, responsive staff.
They are based in South Africa, less likely to be coerced into disclosing information they should not by the CIA or the US government.
They are not subject US encryption export laws.

Unfortunately they have been bought out by Verisign, a much less customer-friendly company. However, I have seen no sign in deterioration in Thawte as a result.

The Types Of Digital Certificate

There are many different types of certificate. Unfortunately, you need a separate certificate for every application and every browser, (read $$$), e.g. SSL web server, SSL web browser (Netscape, Opera, Internet Explorer ...), software publisher jar signing (sometimes called Object-signing) (in three flavours: Microsoft RSA Authenticode, Netscape RSA X.509 and Sun Java Plugin DSA/RSA X.509), Marimba channel signer, signing authority root certificate, SET financial Visa/MasterCard web transactions and secure email (S/MIME X.509 v3 for Netscape, PGP (*.asc) for Eudora).

The Verification feature in the Netscape Communicator Security Advisor only determines whether a Digital ID is valid for S/MIME email. Object Signing (i.e. jar signing) certificates are (usually) not also valid S/MIME certificates. It can be alarming to have your new jar signing certificate rejected without an explanation as to why. Netscape has stated this interface will be fixed in a later release of Communicator.

Unfortunately, all this innovation and competition leads to a tower of Babel. When you want to send a message to someone else, you both must be using compatible encryption/signing software. PGP is not compatible with S/MIME email for example. It is not always obvious what scheme an incoming message is using. Further, most of the time the certificate file looks like gibberish. You can't tell just by looking at the file with a text viewer, which signing authority created it, who owns it, what program is needed to make sense of it, which browsers/emailers/newsreaders it works with or even whether the file includes a private key. You need to keep track of that externally.

Security software is typically not in the least user-friendly. It is designed for nerds. For example, if you feed an X.509 v3 SHA-1 certificate to browser that only supports X.509 MD5, it will complain the file is "invalid or corrupt", instead of telling you what sort that certificate is, and what kind it wants, and where to get one.

To complicate matters further, certificates can come an a variety of packagings called wrappers. For example, PKCS #12 wrapping allows key portability. This means, for example, that you can move your certificates (and the corresponding private keys) from one computer to another on floppy disks. Your private key and passphrase are encoded in the *.p12 file. Thawte RSA certificates come with PKCS #7 wrappers. Just when you thought you understood it all, you learn that X.509 certificates come in two formats and to add further complication, they have RSA and DSA variants. Here are some of the common types:

Extension	Format	Includes private key?	Netscape 4.79	Opera 7.21	Internet Explorer 6.0.26	Java Plug-In keytool 1.3+	Notes
.asc	PGP	no	no	no	no	no	Pretty Good Privacy.
.ca	X.509/DER binary format	no	yes	yes	yes	yes	root certificates.
.cer	X.509/DER binary format	no	yes	yes	yes	yes	Sun Java 1.3+ user certs.
.cer	X.509/DER BASE64 encoded	no	yes	yes	yes	yes	Sun Java 1.3+ user certs.
.crl	?	no	?	?	?	?	Certificate Revocation List. Used by cryptext.dll.
.crt	X.509/DER binary format	no	yes	yes	yes	yes	Thawte root certificates, Sun Java 1.3+ cacerts.
.csr, .p10	PKCS #10	no	?	?	?	yes	Certificate request, contains the public key, signed with the private key.
.db	proprietary binary?	yes	yes	no	no	no	Netscape export of the entire set of keys. Contains multiple certs with private keys.
.keystore, cacerts.	JKS	yes	yes	no	yes	yes	Sun's keyring format. Can optionally include private key, authentication chain and friendly name. Sun never imports/exports the private key, though .keystore contains it.
.p12, .pfx	PKCS #12	yes	yes	no	yes	yes	user certs. Can optionally include private key, authentication chain and friendly name. Sun never imports/exports the private key, though .keystore contains it. IBM's Keyman will create and manage this format of keyring.
.p7b	PKCS #7	no	no	no	yes	yes	IE binary public key export. Can optionally contain multiple certs, e.g. a certificate chain. IBM's Keyman will create and manage this format of keyring.
.p7r	PKCS #7	no	no	no	yes	yes	Certificate request response. Your signed certificate back from the signing authority ready to import. ASCII format. Used by cryptext.dll.
.pem	PEM	no	?	yes	?	yes	Privacy Encoded Mail format for sending certs embedded in email, typically SSL cert.
.sst	?	yes	?	?	?	?	Windows certificate store.
.stl	?	no	?	?	?	?	Windows certificate trust list. Used my cryptext.dll.
.usr	X.509/DER binary format	no	yes	yes	yes	yes	user certificates.

The Formats Of Digital Certificate

Extensions usually don't matter that much. What matters in the internal format of the file. The file formats are nearly all missing a format signature to make identification easy. It is as though the designers did not want anyone looking at the files and making any assumptions on what they read there. You must externally track what every certificate is for.

We need software that can handle multiple schemes depending on the automatically determined preferences of the recipient. However, it is a Good Thing ^TM there are so many schemes. Not only does it complicate the code-breaker's task, a breakthrough can render an encryption technique void overnight. We need to have viable alternatives waiting in the wings.

Some certificates have binary format, others an ASCII printable format, still mostly gibberish. Unfortunately they don't have human readable markers in them to tell you what type they are or what they are for or what they contain. ASCII format are often called armoured.

Cost

Certificates vary in cost depending mainly on how much research the certificate authority does to verify you are really you, and how much information is in the certificate that the authority is attesting is true. If you are buying a certificate for an SSL webserver, for example, Thawte are about 1/3 the price of industry leader Verisign. Thawte's developer certificates work for Netscape and Microsoft, JDK 1.1, JDK 1.2, JDK 1.3+ plugin, and Web Start. Unfortunately, Verisign bought out Thawte in 2000 February, so prices will rise. With Verisign you need to buy three separate certificates. Thawte has greatly improved over the last year and issued my certificate within one day after I faxed the necessary documentation. Thawte is in South Africa. Verisign is in the USA. Your secrets are probably better kept by a different government that the one wanting to pry on them. All it would take is a court order to discover your Verisign secrets. Thawte has better documentation. There has been a historical tendency of certificate companies to presume extremely high technical knowledge on the part of their users. It is not quite as bad as you might think since, in theory, the signing authority does not know your private key.

Personal certificates are often free, especially ones with a short expiry date. Corporate ones are hundreds of dollars per year. For SSL server certificates, or Developer Object/Applet signing certificates, you want to choose a certificate authority already built into the standard browsers such as Netscape, Internet Explorer and Opera, e.g. Thawte.

What Certificates Do you Need?

A serious Java shop will need to separately purchase at least five different certificates:

S/MIME for email.
SSL webserver id certificate.
RSA X.509 (special Sun Java type) for JDK 1.3+ plugin jars and Web Start.

To deal with legacy customers, they might also want to get:

RSA X.509 for Netscape 4.79 fine grain & Netscape 7.02 crude JDK 1.3+ plugin security.
DSA X.509 for JDK 1.1 and JDK 1.2 plugin jars
RSA Authenticode for Internet Explorer cabs.

What Is in A Certificate?

The certificate may contain information such as your email address, your name, address, birthdate, gender, SIN/SSA number, passport number, company name, DUNS number (Dun & Bradstreet number), your website URL, and other information including your personal public encryption/signing key. You may be required to provide additional information such as Business License, Certificate of Business Registration and Articles of Incorporation which are kept on file at the signing authority, but which are not included in the certificate as vouched for information. None of this information has any effect on how and where you can use your certificate.

The certificate has an issue and expiry date. It does not contain your private key. Some certificates may have a lifetime of only minutes. The signing authority is guaranteeing the information is true. They use their private key to sign the certificate attesting to its authenticity.

What Can You Use Certificates For?

You can then use the certificate to digitally sign email, documents, jar files etc. to prove you were the author, and that they have not been tampered with.

You can also use some types of certificate as digital ID. Others can electronically challenge you to prove you know the private key that fits with the public key in the certificate by encrypting a message they provide. The problem with that is, all the information in the certificate is revealed to whoever you show it to. If you want to selectively reveal information, you need several certificates. You might want one with just your birthdate for entry to pornsites, but no other information. You might want one that revealed only a very minimal amount of information when dealing with online vendors to avoid being bombarded with junk electronic and snail mail.

Certificates can be used instead of passwords to verify who you are to some site. The site challenges you by sending you a message that you digitally sign and send back. If some spy had snooped on you logging in before, it would not help him to spoof you, the way it would had you used a password.

Other types of certificate allow you to encrypt and sign all HTML traffic leaving your web server, thus proving it came from you and providing privacy. Recipients can determine whether data did indeed did come from you by checking the digital signature. To verify, all they need is a master certificate from the signing authority, which comes built into their browser or email software. They don't need to check up your key in an online database unless they want to check to see if the certificate has been revoked.

MasterCard and Visa have designed the SET certificate that can be used for secure financial transactions over the web. Verisign supplies the certificates.

Private Key Vs Public Key

There are two kinds of certificates, ones that contain the private key and ones that don't. often user certs contain the private key. Sun style user certs never do. Authority certs never contain the authority's private key. You want to avoid passing your private keys around, even for phony certs. When you use a phony cert, you want just the public key installed as a signing authority in the various browsers that will use your signed code. The problem is when you export and import keys, it is rarely clear on whether the private key is being included. Internet Explorer is fairly good about keeping you informed and giving you the option to include or exclude the private key. Netscape and Opera keep you in the dark. Sun keytool never imports/exports private keys. I don't even know of a tool that will tell you if a certificate contains a private key. See my student project to rectify this problem.

If you are passing a certificate to another machine to sign code with, then your exported/imported certificate must contain the private key, or you won't be able to sign code, just verify it.

Viewing: What Certificates Do You Already Have?

You already have many certificates installed on your computer. Some are part of the OS, some part of Java and some part of each browser. Some are public keys of signing authorities, some are your personal private key certificates. Here is how to have a look at what you already have.

Where To Look For Certificates
Browser	Where to Look In the Browser	Where to Look on Disk
	Java stores its code signing certificates in a WINNT\Profiles\ Administrator\.keystore file and the verifying authority root certs without private keys in the J:\j2sdk1.4.2_04\jre\lib\security\cacerts file. Use keytool or keyman to view them.	The Java plug-in stores its code signing certificates in a WINNT\Profiles\ Administrator\.keystore file and the verifying authority root certs without private keys in the J:\j2sdk1.4.2_04\jre\lib\security\cacerts file. In JDK 1.3 the plug-in ignores the root certificates in the Microsoft cryptoAPI certificate database (IE browser store). In 1.4 it looks only in cacerts. In 1.5 it optionally looks in the browser certificate database as well as cacerts.
	Click tools \| security \| manage certificates.	Opera stores its certificates in opacert.dat and opcert.dat.
	Click edit \| preferences \| privacy & security \| certificates \| manage certificates.	Mozilla stores its certificates in C:\Documents and Settings\ Administrator\Application Data\Mozilla\Profiles\ username\.
	Click edit \| preferences \| privacy & security \| certificates \| manage certificates.	Netscape 4.79 stores its certificates in .db files. It exports them (with private keys!) to .p12 files. Netscape 7.1 looks in \program files\netscape\users\username.
	Click tools \| Internet Options \| Content \| Certificates.	I have not been able figure out where Internet Explorer hides its certificates, possibly somewhere in the registry. It exports them to .pfx or .p12 files. When you export from IE, you have the option of including the private key.
Windows	Click start \| control panel \| Internet Options \| Content \| Certificates.	I have not been able figure out where Windows hides its certificates, possibly somewhere in the registry.

Updating Root Certificates

You need the latest and greatest root certificates from the various signing authorities installed in the cacerts file and your browser. With them you can validate the public keys of certifates issued by that authority. The easiest way to do that is to use the latest Java JRE and also go to your browser vendor site and get the latest version of your browser, which will naturally include the latest root certificates.

If you don't have the corresponding signing authority root certificate in your browser, your browser will treat bought certificates with the same disdain it treats self-signed phony ones.

For Thawte, you can download a complete zipped collection of Thawte root certificates in three different wrapping styles. JDK 1.5 beta inadvertently left out the root Thawte code signing root certificate. You need to import it into all the cacerts files on machines using your cert.

Verisign don't let you directly download the certificates. You must go to your browser manufacturer and ask them. However, you can visually verify the certificate fingerprints.

Happily upgrading to the latest version of the browser usually also brings you sufficiently up to date with signing authority certificates.

For Java's use, you must import the root certificates into all your cacerts files with keytool.

view

You can always export certificates from one browser and import into another rather that trying to update directly.

With modern JREs, it is most important to get the JREs updated with the recent root certs, then secondarily the browser.

How To Update Root Signing Authority Certificates
Browser	What To Do
	You download the root certificate then import it into both your JRE and JDK with: view Where C:\temp\Thawte Code Signing CA.cer is the name of the root certificate you are importing. The default password for cacerts is changeit.
	Just click on the certificate reference to download and import it, or click File \| Open. To see what root certificates are installed click tools \| preferences \| security \| manage certificate \| authorities.
	Just click on the certificate reference to download and import it, or click File \| Open. Alternatively, click edit \| preferences \| privacy & security \| certificates \| manage certificates \| import .
	Just click on the certificate reference to download and import it, or click File \| Open. Alternatively, click edit \| preferences \| privacy & security \| certificates \| manage certificates \| import .
	Download each certificate, then click file \| open. To see which publishers signing authority certificates are included click tools \| Internet Options \| Content \| Publishers.

See Mitch Gallant's documentation on importing root certificates.

Cracking Security

There are plenty of indirect ways to crack the security provided by digital certificates:

Wait for the user to make an error, such as accidentally publish his private key. The procedures to use security measures are still quite complicated and easily screwed up.
Put up a spoofing display that simply asks the user for passphrases. A dutiful user will mindlessly provide them.
The security systems in Windows9x and NT are made of swiss cheese. Crack them and replace crucial bits of code in browsers or signing tools.

Free Phony Self-Signed Certificates

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 the Netscape jar-signing tool, 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.

See signtool or keytool for details of how to create a phony certificate.

To create phony SMIME email authentication certificates in Windows use:

view

Obscure Certificates

There is a third kind of certificate, legitimate like one from Thawte or Verisign, but with most of the hassle of a phony one. What if you bought your certificate from an small signing authority company that almost no one had heard of, or used a free one, its root certificate would not be built-in to Netscape or Internet Explorer. You would have to manually import either the signing authority root certificate or your certificate into every client's machine before your signed Applet would be recognised. This would be a major hassle if you are dealing with the general public.

This problem even happens sometimes with mainstream companies. For example Thawte sold code-signing certificates in 2004-04, but the root certificate to verify them was not present in JDK 1.5 beta, or any of the browsers. It had to be manually installed, making using the certificate as clumsy as a phony self-signed certificate. Download the root certificate and install it in all the cacerts files on machines that use you application.

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

The Root Certificate Matching Problem --
Why Verisign Jar-Signing Certificates Are All But Useless

Verisign jar-signing certificates are all but useless because of a bug in Netscape 4.79.

Verisign made an minor mistake that is causing severe troubles. They issued several public root jar-signing certificates with the same public key, but different expiry dates. These have been pre-installed in the major browsers.

Unfortunately Netscape is not too bright about how to find the matching root signing authority certificate for a jar. It just takes the first match on public key. This can cause it to pick the wrong root certificate and refuse to accept the jar.

You can encourage it to find the correct one by removing the other Verisign root jar-signing certificates. However, if you do that, it won't be able to verify jars signed by other vendors. I suppose you could remove all but the most recent root Verisign jar-signing certificate and trust all vendors will soon upgrade their certificates. Other solutions: use Thawte certificates which don't have the problem, or wait for Netscape to use improved matching logic.

How Netscape 4.79 Jar Signing Works Under the Hood

Jars may optionally be signed. For Netscape-style signing you will see two extra files:

zigbert.rsa which contains your public jar-signing key and a stripped down version of your jar-signing certificate. It contains your public key, your company name, your certificate expiry date, your signing authority's public key, your signing authority's name, and your signing authority's expiry date. Your private key is not present. Your certificate is digitally signed with the signing authority's private key. By that I mean the checksum of your certificate is encrypted with the signing authority's private key. It can be decrypted with the signing authority's public key to verify the signature. The browser's public key is pre-installed in the browser for verification.
zigbert.sf which looks much like a manifest file. It contains the digital signatures of each member of the jar file. These are encrypted with your certificate's private key. They can be decrypted for verification with your certificate's public key. Netscape computes them a slightly different way from Sun.

How then does Netscape verify that a signed jar was indeed signed by you, unmolested since the signing, and vouched for by a trusted signing authority?

I am not sure of the precise details and ordering, but roughly it works like this:

Netscape looks up the public key of the signing authority (from zigbert.rsa) in its list of valid authorities. If it can't find a matching authority root certificate, it rejects your jar.
Netscape checks that the names in your root certificate and expiry date precisely match those it has on file.
Netscape computes the checksum of your certificate (from zigbert.rsa), and compares it with the one decrypted with the signing authority public key. If they match, your certificate in the zigbert.rsa file is valid, if they don't, somebody has forged your certificate.
Netscape checks that the expiry dates of both your certificate and the backing root certificate are have not lapsed.
Netscape, in theory, could optionally go to the signing authority's website and check that both the root certificate and your certificate have not been revoked. I don't think it does this routinely. If it did, it could challenge the website to prove its identity my asking it to encrypt some random string with the root authority's private key. If it decrypts properly with the root authority's public key, Netscape knows it is talking to the authentic website, not some spoof site.
Netscape recomputes the checksums in the zigbert.sf file. It then decrypts the checksums provided in zigbert.sf using your certificate's public key from the zigbert.rsa file. If they match, all is ok. If they don't somebody has been tampering with the jar file.

How Java 1.3+ Jar Signing Works

I have done only a little experimenting with Sun's Jar signing scheme that uses a policy file. The scheme strikes me as impractical since most end users will be incapable of maintaining policy files. It really only makes sense in a corporate environment with a system administrator who manages all policy files.

For fine-grained privileges (bypassing the RSA ALL/NOTHING default), the end user must include:

permission java.lang.RuntimePermission "usePolicy" in their local policy file. There is no way with Java 1.4.1 security policy for you as the author of signed code to ask the user for specific privileges with your signed code.

However, once the usePolicy is in place, applications may use the javax.security.auth.Subject.doAs(...) or javax.security.auth.Subject.doAsPrivileged(...) methods to request fine-grain privileges. It sounds hideously complicated involving, authenticated Subjects, Principals, AccessControllers, PermissionCollections and Permissions.

Make sure you don't inadvertently give the privilege of rewriting the policy file to a suspect program.

Fine grain policies where you ask the use for permission are pointless because the user does not understand the questions. Further the many questions just irritate him. (As I discovered with the old Netscape fine grain permissions.) I have little to say about it other that my documentation on how to use keytool. For details see Mitch Gallant's site.

I asked in a newsgroup for an explanation of what AccessControllers were for. Hold your breath, here was the response.

The Java AccessController uses the set of ProtectionDomains on the call stack to implement permissions based on code bases (e.g., classes loaded from my local machine can read and write local files, but Applets loaded from the network can't).

When you check for a permission, the AccessController examines each ProtectionDomain on the call stack in the AccessController, ensuring that the associated PermissionCollection for each such ProtectionDomain implies the requested permission.

In other words that the method's caller, or the caller of that method etc. have permission to do the naughty deed.

You can attach a DomainCombiner to an AccessControlContext that you create (if you have permission to create an AccessControlContext), and then your DomainCombiner gets the opportunity (or responsibility) to touch/modify the set of ProtectionDomains before they are checked for the given permission. JAAS authorization is implemented this way, by attaching a javax.security.auth.SubjectDomainCombiner to the AccessControlContext created in javax.security.auth.Subject.doAs(); this SubjectDomainCombiner uses the JAAS policy object to add the subject's permissions into the permission set of each of the ProtectionDomains on the call stack.

Maybe you didn't really need a signed Applet after all...

RSA vs DSA

RSA-signed Applets often refer to the old proprietary Netscape jar-signing scheme. It was been replaced by the Sun-style DSA-signed Applets in Java 1.2. Sun-style RSA-signed Applets were introduced in Java 1.3 and have now completely replaced the DSA scheme. You don't see DSA certificates any more.

Manipulating Certificates

You can manipulate certificates directly with Java. Here is an example of how you would extract the public key from a PKCS12 certificate.

KeyStore ks = KeyStore.getInstance ( "PKCS12" );

// for security, KeyStore wants certificate password as char[]
char[] password = "Sesame".toCharArray();

ks.load( new FileInputStream( "yourcert.p12" ), password );
Certificate c = ks.getCertificate( "thecert" );
PublicKey p = c.getPublicKey();

To do the equivalent with the .keystore file use .getInstance ( "JKS" ) instead of .getInstance ( "PKCS12" ).

Learning More

For more information see this tutorial on installing a Netscape SSL server. It also contains plenty of general information. See Netscape's essay on certificates and security. See this list of links to find out more detail.

See IBM Redbook Java 2 Network Security for notes on how to create your own certificates (you as issuing authority), for Netscape, IE, and Java 2.

Information on Certificates : available:

on the web at java.Sun.com
on J: in the JDK 1.4.2_04: J:\j2sdk1.4.2_04\docs\guide\security\cert3.html
on J: in the JDK 1.5 beta: J:\Program Files\Java\j2sdk1.5.0\docs\guide\security\cert3.html

There are some noticeable gaps in Sun's security classes. You can't produce an X.509 certificate for example. The BouncyCastle classes often come to the rescue.

Applet ¤ Appletviewer ¤ blowfish ¤ BouncyCastle ¤ cacerts ¤ capabilities ¤ cryptography ¤ digital signatures ¤ DSA ¤ DUNS number ¤ email ¤ encryption ¤ fingerprint ¤ Internet Explorer ¤ jar ¤ jarsigner ¤ Java Plug-In ¤ javakey ¤ keyman ¤ keystore ¤ keytool ¤ MD5 ¤ Netscape ¤ Personal Bookshelf (Securing Java) ¤ PGP ¤ PKCS ¤ policy file ¤ policytool ¤ Roedy Green's code Signing Certificate ¤ RSA ¤ sandbox ¤ Security ¤ SET ¤ SHA-1 ¤ signcode ¤ signed Applets ¤ signtool ¤ SSL ¤ student projects(Certificate viewer) ¤ Thawte Multi-Purpose Certificates ¤ Thawte ¤ Verisign ¤ X-ca certificate management ¤ X.509 v3

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 36778.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/certificate.html	J:\mindprod\jgloss\certificate.html