Digital Certificates: place your order
By imrdkl in Technology
Sat Jun 08, 2002 at 10:12:05 AM EST
Tags: Focus On... (all tags)
Sometime soon, or in the near future, you may need to get a digital certificate of your own.
There may be several reasons for this requirement - you might be looking for secure access
to your bank account or other services, or perhaps your employer is setting up a Public Key
Infrastructure (PKI), and you must "join up" to have continued access at your job.
If you are a developer or systems administrator, you may need to obtain a certificate for
authenticating a server, or binary code which is part of your web application.
Alternatively, you might just be curious about what certificates are, and decide to obtain
a certificate of your own to investigate.
In this article, the second of a three-part introduction to digital certificates,
we'll take a look at the process of obtaining a certificate, from key-creation to installation.
I discussed what digital certificates are,
and what they're used for. I'll again limit the focus of this
article to obtaining certificates which are used in a Web-based
including Client, Server, and
CodeSigning certificates. Particular attention will be paid to client certificates,
since those who need or want to obtain one may be the least technically-savvy.
Each of these types of certificates was introduced in the previous article,
and I'll assume that the reader is somewhat familiar with what they are.
There are essentially four primary steps in the process of obtaining a digital
certificate, three of which must be performed by the person or entity which
wants to obtain the certificate, also called the Subject,
and one which must be performed by the Certifying Authority
(CA) which issues the certificate, also called the Issuer.
You may recall from the previous article, that I also referred to the
Subject as the Grantee of authority, with the Issuer as the Grantor.
Regardless which term you use to define the roles, the interaction between
the them is the same.
If you are ordering a certificate through your web browser, then this entire
process may appear to be a single seamless transaction, but it's
worth the time to consider the steps individually before you make your request.
The Four Steps to Obtaining a Digital Certificate
So, we've finally got a certificate. That may be all that the average user ever
cares about, once it's installed. Some, however, may wish to examine the
the certificate a bit more closely, to get an understanding about how
it was made, and what the Issuer has built into it. As we've seen, a digital
certificate probably won't be hung on a wall, but it bears closer inspection.
What did the money that you (may have) paid, and the identification you provided,
get for you, anyways? In the next article, we'll take a much closer look at digital
certificates, how they're built, and what they mean, to find out.
- Create the Key Pair
The first step in obtaining a certificate is to create the
which will be used in it.
This keypair may already exist, for example if you
already have a key pair which you use for other
purposes. Alternatively, if the certificate is to be issued for
installation on a device such as a SIM Card, ID card, or
a Mobile telephone, the key pair may already be installed,
and the Subject will have access to the password (PIN) which
safeguards the existing private key.
As mentioned before, if you are going to use a certificate
for which you did not generate the keys yourself, then you
should consider who has created the
keys, and perhaps find out if any copies were made.
When possible, always create your own key pair.
In any case, the key pair will be created via some means. This is the
first step in the process of obtaining a certificate.
such as those which are installed in a web browser for secure access
and single sign-on, may have their
key pair created via communication
between the browser and some external software, or possibly within
the browser itself, via built-in key-generation capabilities.
For Server certificates, the key pair will typically
be created by the server administrator or operator of the server,
via software which is external to the server software, such as
openssl. Keys which
are to be found within Codesigning certificates
are also created via external software, or alternatively via
tools included with the software development package which is
being used to create the application for signing.
A key pair can be generated using a large number of algorithms,
also called "Providers" in MSIE. The two most common types of
key algorithms are named RSA, and DSA, but there are others.
When creating a key pair via the Microsoft IE browser, a list will be
presented with all of the available providers installed
on the Subject's machine, and which are acceptable to the Issuer. If you
don't know the differences well enough to choose, then have a look
this list which defines them,
including things like key lengths, and other relevant details.
After the key pair is created, you're ready to create the actual request
for a certificate.
- Creating a Certificate Request
The next step which is taken, in the process of obtaining a digital
certificate, is to create something called the certificate request,
(or certreq). The certreq takes the public key
of the requestor (Subject)
and builds it into a file-container which is
to be opened, read, approved and signed by the CA.
Besides the public key, the certreq contains the
Distinguished Name (or DN) of
the Subject along with some other information.
The DN is an important part of the certreq, and eventually,
the certificate. A DN is a long text string built up of
individual components. The components are typically based on a specific
protocol for heirarchical information storage and identification,
Lightweight Directory Access Protocol.
LDAP, and it's heavier (and proprietary) counterpart, X.500.
These protocols define an extensive list of identifiers, but
the certificate DN typically includes only a small subset of them.
Things like Name, Location and Email Address which
pertain to the certificate-requestor, as well as some of the requestors
organization details, such as Organization Name, and department, may
be requested by the Issuer to validate the certificate, and construct the DN.
The interface for obtaining these bits of information may be web-based,
or via a command-line. In either case, the Subject will be asked questions
about themselves or their organization, and will input the answers.
Other details about the Subject may also be requested at the time the
certificate is ordered which will not be directly embedded in the certificate,
as the DN is. These details will be read, validated, and permanently stored by
the Issuer as part of the overall certificate-ordering process.
After the certificate request is built, it is then sent to the Issuer.
Email may be used for this, or it may be a seamless
part of the web-based certificate request.
- Certification Authority approves and signs the certificate
After the certreq is sent to the CA, a number of steps are taken in
the process of approving the certificate. I won't discuss these steps
in depth, except to say that they may vary with any given Issuer.
These steps are the validation of the request. They typically
conclude with the signing of the certificate request, and the creation
of the actual certificate. When the certificate request is signed, the
Issuer inserts its own DN into the certifcate, and inserts the Subject's DN
from the certreq, along with its public key. A lot of other information
is placed into the certificate by the Issuer, which I'll discuss in the next
After the certificate is created, a notification is typically sent to the Subject
informing them that their certificate is ready, and where they may pick it up.
Sometimes, the certificate may be sent via email as well. This sometimes
concerns people, that their certificate has been sent via email, but it's
important to keep in mind that a certificate can't be used for access
without it's private key, which the CA has usually never seen, and would never
send. The certificate contains only the public key.
Depending on the intended usage, type, and "strength"
of the certificate which is desired, the approval
process may be short and simple, or quite lengthy, requiring
extensive documentation and legitimation, especially if the certificate
is being requested for a business. Certificates typically
also require the payment of a fee to the CA, a sort of insurance
premium, for them to certify the requestor, and guarantee their identity.
- The certificate is installed by the requestor
After the notification is received, the certificate is
finally installed on to the device or machine for which it is intended,
and can then be used in the process of secure communications. If
a server certificate was requested, the web server is typically
restarted to activate the certificate, while client certificates
may be used immedietly to login. CodeSigning certificates are
installed within the developer's private files, so that he may
then use the certificate to sign code which will be deployed as
part of a web application, downloaded, and run on a client