Introduction to digital certificates
By imrdkl in Technology
Sun Apr 28, 2002 at 03:49:49 AM EST
Tags: Focus On... (all tags)
What is a digital certificate? What does it do?
Where is it kept? Can you hang them on your wall?
And most importantly, why should you care?
If you're working in the IT industry, or
for a large security-minded company, or possibly even
if you only have a bank account with internet access,
then you may already have one - although you
may not be completely aware of it, or how it works.
This article will give a short and simple overview of
digital certificates, with some bits about what they're used for,
and perhaps pique your interest enough to learn more about them.
The digital certificate is a cornerstone of many Digital Id
implementations which are available today, and others which
are being considered, including the
National ID Card.
They can be very useful for increasing security, and despite
what some may contend, they are probably not the
dreaded mark, although
I don't recommend that you have one implanted.
What is a certificate?
Since I won't be discussing digital certificates which are
implanted in or tattooed on a person, we may consider
the certificate purely as an electronic assertion which resides on
a specific device, such as a computer, or mobile phone. The assertion
can take many physical forms, such as a file,
or an entry in the computer registry. The assertion is to trust.
The primary roles of Certificates
A certificate can be used in many different types of activities,
but there is only one of two possible roles for
all certificates. These are as follows.
- Grantor of authority - the owner (or creator)
of this type of certificate
grants authority to the other type of certificates (Grantee)
so that they may be used to execute the activities. A Grantor
type of certificate is also called a Root or CA certificate,
or sometimes an SubCA certificate.
- Grantee of authority - this type of certificate
is granted authority (signed) from the Grantor certificate.
The owner (or holder) of the Grantee certificate may then use it's
granted authority to execute the activities.
These activities are referred to as trusted activities.
The Grantee certificate may also called an end-user certificate.
Every certificate has a pair of encryption keys
Every certificate has associated with it an so-called
keypair, which are usually created by the owner of the certificate. This person,
or other entity, is known as the requestor of the certificate. The keys usually will have
been generated via a
software tool or device which is capable of such things.
One of the keys in the keypair is called the public key, and is built-in to
the certificate itself. The other key, called the private key is not part of the
certificate. The private key is kept secure by the owner of the certificate,
via encryption using passwords, or other means. The private key is only used
during the time when the certificate is physically granting or executing it's authority.
This article will not attempt to
address the mechanics related to encryption keys.
However, there is one addition point worth mentioning here.
If you are asked (told) to accept a digital certificate for which you
did not create the keys, you should consider the request carefully. If you
do not make the keys which are in your certificate, then you may not have exclusive
control over it.
Every certificate is unchanging
Certificates, out of necessity, are immutable. Once they are created, they cannot
be changed, or renewed. They have a specific lifespan, which is assigned at the time of
creation, in the case of Grantor certificates, or at the time of the signing,
for Grantee certificates. When a Grantor certificate is created, we say
that the creator has created an Certifying Authority, or CA. This CA then has
a specified lifespan, and can grant some or all of it's specific, unchanging Authority
to end-user certificates. The owner of the CA certificate also specifies the amount of time that the
the end-user certificate shall have permission to execute the Authority, or "live".
Every certificate has Authority
The Authority which is granted by Grantor certificates, and received by Grantee certificates,
is given in order to allow the Grantee certificate to perform one or more
specific trusted activities, as already mentioned.
The high-level activities which are allowed each have specific low-level requirements which
must be granted in the correct combination and amount, for the end-user certificate
to properly perform the activity. These specific low-level requirements are also called the
attributes of a certificate. This article will not discuss the attributes which are
built into a certificate. It will discuss the high-level activities which
certificates are used for, to execute their Authority in a particular setting.
The authority which is built into a certificate is valuable and should be protected.
Any grant, or execution of the authority built into a certificate requires both of the
keys, discussed earlier.
If, at any time in the life of the certificate, the Grantee or the Grantor decides
for any reason that the certificate should be invalidated, the process by which this
invalidation is accomplished is called revocation. When a certificate is
revoked, it's effective life ends immedietly. The revocation occurs via a process
which is initiated by the Grantor of the certificate's authority. Any entity which
then wishes to validate the Grantee's certificate will be told that it is no longer
Some High-Level activities authorized by certificates.
When considered in the realm of an computer operating system, the
activities which are executed with the aid of Grantee
certificates include four specific types which are interesting, among others which
won't be considered in this article. These four types of end-user certificates
- Server - an server certificate has been granted
authority to participate in the activity of implementing an secure webserver,
or other type of secure internet server. Anytime you connect your
browser to a secure website, a Server certificate is executing it's
- Client - an client certificate has been
granted authority to participate in an internet client-server
relationship as client (with a Server). The client certificate may
authenticate the person which is actively using the client machine,
or it may specify characteristics of the network or machine where
it is installed, or both.
- CodeSigning - an codesigning certificate has been granted
authority to permanently mark binary object code which runs on a computer.
This activity entails applying a sort of permanent "seal" to the object
code, so that changes can be detected in it, as well. This activity is
also referred to as code signing, as inferred by the name.
Note - this is not the same sort of signing that is done with an Grantor certificate.
- Email - an email certificate has been granted authority to
participate in the activity of securing email between individuals or groups.
Many popular mail user agents implement secure email options with
the help of Email certificates.
More on Grantor/CA certificates
At this point, one important point should be re-emphasized.
Grantor/CA certificates sign certificates, but cannot be used to execute their own
authority. Only Grantee/end-user certificates can execute the Authority which is
granted by Grantor certificates. Likewise, Grantee certificates cannot sign other
certificates. Grantee certificates can be used to sign data and code, however.
This is an important distinction. Another article may further consider the finer points
of this distinction. Root certificates are, by nature, self signed. As
previously mentioned, SubCA certificates also can sign certificates. An
SubCA certificate is signed by a Root certificate which is granting it's power
to sign certificates, along with the one or more of the authorities previously
discussed. Think of an SubCA certificate as a middleman, of sorts, who is
an authorized re-distributor of some or all of the authority held by the Root.
Again, more on the topic of SubCA belongs in a separate article.
There's not much that can be discussed in the realm of Digital Id without a good
basic grasp what a certificate is, it's uses and authority, the risks
associated with them, and at least something about their mechanics.
This article is intended as a starting point only.
More information about certificates and how they're built and used,
will be found in my next article. If you
cant wait until then, then have a look at
Digital Id World for other
introductory articles. For more than you probably would ever want to know
about certificates and Certifying Authorities, and the broader topic
of Public Key Infrastructure take a look at the