certificate : Java Glossary

How Certificates Work

Make sure you back up your .keystore files especially when upgrading your OS or Java. Otherwise you will lose your code signing certificates.

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.

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 .

The Types Of Digital Certificate

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.

PKCS #11 (cryptoki) is used inside thumbdrives for identification and decryption.

Here are some of the common types:

The Formats Of Digital Certificate

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.

To sign XML you need to convert the pvk/spc pair with pvkimprt.exe

Cost

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?

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

1. RSA X.509 for Netscape 4.79 fine grain & Netscape 7.1 crude JDK 1.3+ plugin security.
2. DSA X.509 for JDK 1.1 and JDK 1.2 plugin jars
3. RSA Authenticode for Internet Explorer cabs, for signing VBA (Visual Basic apps) for signing XML files including PAD program descriptions, for signing device drivers, and for signing applications for Vista written in C++.

What Is in A Certificate?

• email address
• your name
• address
• birthdate
• gender
• SIN/SSA number
• passport number
• company name
• DUNS number (Dun & Bradstreet number)
• your website URL
• personal public encryption/signing key.
• Some certificates also contain your personal private key, but these are never distributed. All the ones you download do not contain a private key.
• issue and expiry date
• A certificate usually has a distinguished name of the form CN=mindprod.com, OU=Secure Application Development, O=Canadian Mind Products, L=Victoria, S=BC, C=CA where CN is the website, OU is subdivision of the comppany, O is the company name, L is the city, S is the province/state and C is the country code.
• The digital signature of the certificate authority attesting to the information in the certificate.

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.

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.

Infuriatingly, there is almost always two crucial things missing :

1. The URL where you can download the official version of the certificate.
2. The URL of where you can view the certificate’s human-readable fingerprint to verify it is valid.

What Can You Use Certificates For?

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

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?

Where To Look For Certificates
Last revised: 2008-01-23
Logo	Browser	Where to Look In the Browser	Where to Look on Disk
	Java	Java stores its code signing certificates in a WINNT\Profiles\ administrator\.keystore file and the verifying authority root certs without private keys in the cacerts. file. cacerts : in C:\Program Files\java\jre6\lib\security\cacerts in the JRE 1.6.0 on your local hard disk. in J:\Program Files\java\jdk1.6.0_10\jre\lib\security\cacerts in the in the JDK 1.6.0 on your local hard disk. in C:\Program Files\java\jre1.5.0_16\lib\security\cacerts in the older JRE 1.5.0 on your local hard disk. in J:\Program Files\java\jdk1.5.0_16\jre\lib\security\cacerts in the in the older JDK 1.5.0 on your local hard disk. 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:\Program Files\java\jdk1.6.0_10\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..
	Opera	Click tools ⇒ preferences ⇒ advanced ⇒ security ⇒ manage certificates.	Opera stores its certificates in opacert.dat and opcert.dat.
	Firefox	click Tools ⇒ Options ⇒ Advanced ⇒ Manage Certificates	Firefox stores its certificates in C:\Documents and Settings\ administrator\Application Data\mozilla\firefox\Profiles\username\. When importing, make sure you import Java code-signing certs as website type.
	Sea Monkey	Alternatively, click Edit ⇒ Preferences ⇒ Privacy & Security ⇒ Certificates ⇒ Manage Certificates ⇒ import .
	IE 7	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.
	IE 6	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.
	Safari	click start ⇒ Control Panel ⇒ network ⇒ Internet Options ⇒ Content ⇒ Trusted Root Certificate Authorities.
	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.

Cracking Security

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

Obscure Certificates

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.

The Root Certificate Matching Problem —
Why Verisign Jar-Signing Certificates Were All But Useless.

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

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

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

1. 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.
2. Netscape checks that the names in your root certificate and expiry date precisely match those it has on file.
3. 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.
4. Netscape checks that the expiry dates of both your certificate and the backing root certificate are have not lapsed.
5. 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 by 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.
6. 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

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

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

Whether you choose DSA or RSA, the SHA-1 digests in the MANIFEST.MF manifest will be the same either way, as will the digests in the *.SF file. For reasons unknown, the SHA-1 digests in MANIFEST.MF don’t match those in the *.SF file. The only thing that literally gets digitally signed (manifest encrypted with the private key) is the digest of the entire *.SF digests file.

If you choose DSA, then your public key certificate will appear in a *.DSA member of the jar. If you choose RSA, then your public key certificate will appear in a *.RSA member of the jar.

Manipulating Certificates

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();

Learning More

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.

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.

	recommend book⇒Digital Certificates: Applied Internet Security
		paperback
	ISBN13:	978-0-201-30980-5
	ISBN10:	0-201-30980-7
	publisher:	Addison-Wesley
	published:	1998-10-09
	by:	Jalal Feghhi, Jalil Feghhi, Peter Williams
The main thing wrong with this book is its age. It is a surprisingly easy to follow book. The JCE itself is daunting, but this book tames it with lots of code examples and an informal style. Consider this book an introduction to the JCE, not the final authority on high security. The end of the book degenerates into a bit of sales pitch for the author’s employer, Verisign, showing you the Verisign way of doing business. The book, is inconsistent in its intended audience. For example, the S/MIME section seems aimed at the JCE for dummies crowd. Yet near the end of the book, the authors throw an alphabet soup of undefined terminology at you as if you were a roomful of Versign techies.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz