certificate : Java Glossary


certificate  certificate
How Certificates Work What Can You Use Certificates For? Why You Want A Real Certificate
Certificate Vendors Private Key Vs Public Key Obscure Certificates
Selecting a Vendor Viewing Certificates Java 1.3+ Jar Signings
The Formats of Digital Certificate What Certificate is a Site Using? RSA vs DSA
The Types of Digital Certificate Where are Certificates Stored? Manipulating Certificates
Cost Installing/updating Root Certificates Certificate Expiry
What Certificates Do you Need? Cracking Security Learning More
What Is in a Certificate? Free Phony Self-Signed Certificates Links

How Certificates Work

A certificate is just a file, digitally signed by a signing authority. It may be a freestanding file, pure binary or ASCII (American Standard Code for Information Interchange) armoured. Usually it lives inside an encrypted container file called a keystore. Your personal certificates are kept in a file called .keystore and the publicly distributed root certificates belonging to certificate issuing companies and other trusted companies are kept in a file called cacerts..

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

The certificate is like a cross between a:

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

There are many different types of certificate. Unfortunately, you need a separate certificate for every application and every browser, (read $$$), e.g. SSL (Secure Sockets Layer) web server, SSL web browser (Opera, Internet Explorer…), SSL EVSSL (Extended Verification Secure Socket Layer), software publisher jar signing (sometimes called Object-signing) (in three flavours: Microsoft RSA (Rivest, Shamir and Adelman) Authenticode, 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 (Secure Multipurpose Internet Mail Exchange) PGP (Pretty Good Privacy) (*.asc) for Thunderbird).

Why are the re so many types? It is partly marketing. The more types there are, the more certificates the vendors can sell. In theory, one certificate could do everything:

There is good reason some certificates cost more than others. The certificate authority has to do research to vouch for the truth of certain information in the certificate. e.g.

The CA has to do almost no work for a mail certificate. That is why they are often free. They can charge thousands of dollars for a premium SSL certificate.

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 (Secure Hash Algorithm 1) certificate to browser that only supports X.509 MD5 (Message Digest algorithm 5), 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 (Public-Key Cryptography Standards) #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 (Digital Signature Algorithm) variants.

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

Here are some of the common types:

Types of Certificate
Extension Format Includes
Netscape Opera Internet
keytool 1.3+
*.asc PGP

Pretty Good Privacy.
*.ca X.509/DER binary format

root certificates.
*.cer X.509/DER binary format

Sun Java version 1.3 or later user certs.
*.cer X.509/DER BASE64 encoded. Sometimes a chain of certificates.

Sun Java version 1.3 or later user certs.
*.crl ?

CRL (Certificate Revocation List). Used by cryptext.dll.
*.crt X.509/DER binary format

Thawte root certificates, Sun Java version 1.3 or later cacerts..
*.csr, *.p10 PKCS #10

Certificate request, contains the public key, signed with the private key.
*.db proprietary binary?

Netscape export of the entire set of keys. Contains multiple certs with private keys.
.keystore, cacerts. JKS (Java Key Store)

Oracle’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

user certs. Can optionally include private key, authentication chain and friendly name. Sun never imports/exports the private key, though .keystore contains it. IBM (International Business Machines) ’s Keyman will create and manage this format of keyring.
*.p7b *.pk7c PKCS #7

IE (Internet Explorer) 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. Looks like a signed document without content.
*.p7r PKCS #7

Certificate request response. Your signed certificate back from the signing authority ready to import. ASCII format. Used by cryptext.dll.
*.pem PEM (Privacy Enhanced Mail)

PEM format for sending certs embedded in email, typically SSL cert. Base64 ASCII-amoured.
*.pfx MS proprietary

Authenticode private key. *.spc is the public key
*.pvk PKCS #12

Authenticode public/private key, used for signing XML (extensible Markup Language) and PAD (Portable Application Description) files.
*.spc PKCS #7/X.509

Authenticode public key. *.pvk is the public key
*.sst ?

Windows certificate store.
*.stl ?

Windows certificate trust list. Used my cryptext.dll.
*.usr X.509/DER binary format

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

Signing XML requires canonicalisation to put the document in standard format, then computing a digest and embedding it in the document.


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 all browsers,Java version 1.1, Java version 1.2,Java version 1.3 or later plug-in and Web Start. Unfortunately, Verisign bought out Thawte in 2000-02, so prices will likely gradually 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 than 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 Chrome, Firefox, Internet Explorer and Opera, e.g. Thawte.

What Certificates Do you Need?

A serious Java shop will need to separately purchase three different certificates:
  1. S/MIME for email encryption and signing.
  2. SSL webserver id certificate for https.
  3. RSA X.509 (special Sun Java type) for Java version 1.3 or later plug-in jars and Web Start.
To deal with legacy customers, they might also want to get:
  1. RSA X.509 for Netscape 4.79 fine grain & Netscape 7.1 crude Java version 1.3 or later plug-in security.
  2. DSA X.509 for Java version 1.1 and Java version 1.2 plug-in jars
  3. RSA Authenticode for Internet Explorer cabs, for signing VBA (Visual Basic Applications) (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?

The certificate may contain information such as: The information is not in human-readable form. You need a program to decode and display it.

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 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 (Hypertext Markup Language) 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. Opera keeps you in the dark. Sun keytool.exe 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 Certificates: 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
Last revised/verified: 2008-01-23
Logo Browser Where to Look In the Browser Where to Look on Disk
Get Java Java Java stores its code signing certificates in a C:\users\user\.keystore file and the verifying authority root certs without private keys in the cacerts. file:
cacerts.\ :
. Use keytool or keyman to view them.
The Java plug-in stores its code signing certificates in a C:\WINNT\Profiles\user\.keystore file and the verifying authority root certs without private keys in the J:\Program Files\java\jdk1.8.0_131\\jre\lib\security\cacerts file. In Java version 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 logo Opera Click tools ⇒ preferences ⇒ advanced ⇒ security ⇒ manage certificates. Opera stores its certificates in opacert.dat and opcert.dat.
Firefox logo Firefox click Tools ⇒ Options ⇒ Advanced ⇒ Manage Certificates

Old version of windows put the Firefox certificates in: "C:\Documents and Settings\user\Application Data\mozilla\firefox\Profiles\username\" In recent versions of Windows, look in: C:\Users\user\AppData\Roaming\Mozilla\Firefox\Profiles\username\.default\cert8.db When importing, make sure you import Java code-signing certs as website type.

SeaMonkey logo SeaMonkey Alternatively, click Edit ⇒ Preferences ⇒ Privacy & Security ⇒ Certificates ⇒ Manage Certificates ⇒ import .
Internet Explorer 7 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.
Internet Explorer 6 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 logo Safari click start ⇒ Control Panel ⇒ network ⇒ Internet Options ⇒ Content ⇒ Trusted Root Certificate Authorities.
Windows 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.

What Certificate is a Site Using?

You can find out what SSL certificate a site is using with Firefox or Opera by clicking the icon to the left of the URL, (with IE and Safari click the lock icon to the right) to give you certificate details. Chrome no longer lets you view the certificate. You need a root certificate in the chain in your store for that certificate to work.

You can also get more detailed information from the Comodo certificate analyser

Where are Certificates Stored?

The moral of the story is, when you import a root certificate, you must import it into multiple certificate stores. Because different browsers have different libraries of certificates, different SSL sites and different signed Applets will work with each browser.

Cracking Security

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

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 a small signing authority company that almost no one had heard of, or used a free one, its root certificate would not be built into 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 (Java Development Kit) 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.

How Java version 1.3 or later Jar Signing Works

I have done only a little experimenting with Oracle’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. I have little to say about it other than my documentation on how to use keytool.

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 (Java Authentication and Authorisation Service) 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…


In the beginning, there were RSA signed Applets using a proprietary Netscape jar-signing scheme. Then with JDK 1.2, they were replaced by Sun-style DSA-signed Applets. Then with Java version 1.3, they were augmented by RSA-signed Applets. Thawte now sells only RSA-style Java version 1.3 or later certificates. If you create a self-signed certificate and choose DSA, it will work on JDK 1.2+. If you create self-signed RSA certificate will work only on Java version 1.3 or later. Pretty much all certificates are RSA now.

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

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

Certificate Expiry

According to Thawte, you can buy a code-signing certificate from them, valid for one or two years. You can sign code for one or two years, then the certificate stops working. However, the code you sign stays valid up to ten years. You get to choose how long you want it to remain valid when you do the signing. However, since jarsigner.exe has no -expiry option, I don’t know just how you would specify that.

More and more websites are refusing to update their expired SSL certificates. If you want to see the content, you have to override the expiry. This is defeating the whole point of expiry dates. However, the bright side of this is it should force down the cost of renewed certificates which should be cheaper for the certificate authority to research. It is a blinking nuisance though for link checking.

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.

Oracle’s Javadoc on HttpsURLConnection.getServerCertificates : Gets you are array of Certificates starting with the certificate for the host followed by the chain of authorities. HttpsURLConnection is as subclass of HttpURLConnection that URL.openConnection returns. : available:

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

book cover recommend book⇒Digital Certificates: Applied Internet Securityto book home
by Jalal Feghhi, Jalil Feghhi, Peter Williams 978-0-201-30980-5 paperback
publisher Addison-Wesley
published 1998-10-09
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 Verisign techies.
Australian flag abe books anz abe books.ca Canadian flag
German flag abe books.de amazon.ca Canadian flag
German flag amazon.de Chapters Indigo Canadian flag
Spanish flag amazon.es Chapters Indigo eBooks Canadian flag
Spanish flag iberlibro.com abe books.com American flag
French flag abe books.fr amazon.com American flag
French flag amazon.fr Barnes & Noble American flag
Italian flag abe books.it Nook at Barnes & Noble American flag
Italian flag amazon.it Kobo American flag
India flag junglee.com Google play American flag
UK flag abe books.co.uk O’Reilly Safari American flag
UK flag amazon.co.uk Powells American flag
UN flag other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

This page is posted
on the web at:


Optional Replicator mirror
of mindprod.com
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number