To set the stage, assume there exists a webpage which tells us
who are the most
important people on this website. This page, however, is
considered by the owner to be private information. To access it
he demands that you have a digital client certificate. You would
then need to request one from a CA which is trusted by both
you and the owner of the "Most Important People Page". We've
agreed that the Roadkill CA, is ok as the trusted third
party, and now we've sent in the certreqs, as
discussed in the previous article. The
good people at Roadkill CA have approved the requests, and signed
them, creating three new certificates. Now these certificates
have been returned to us, for our own use.
Before we have a look at our new "certs", some overview with
linkage is in order. Digital certificates have an important
history, and have a lot of hardworking people making them better.
Digital certificates are based upon a standard called
This standard, with three major revisions so far, specifies how a
certificate shall be built. Certificates which are created
via the first version of the specification (v1), are generically
used, often as self-signed server certificates. The typical
installation will create a v1 certificate for the
Apache Server using openssl, so that the server can be started and
run in SSL-mode while waiting for a certificate from a major provider,
or as an experimental/demo/internal server. (As a k5 reader, you
might recall that when
were introduced, rusty created
a self-signed certificate to manage the paypal stuff. That certificate
was a v1 certificate.)
With the third revision of the X.509 spec,
called x509v3, a certificate can be specified and created
with more details about exactly what it should be used for.
X509v3 specifies extensions, which themselves specify
additional details about the certificate's usage, and owner.
Extensions define, at a more granular level than was possible
with previous versions of the x.509 specification,
the type of authority
that a certificate is granted to perform secure activities
on a machine or device which requires trust.
The rest of this article will focus on examples based upon
which are encoded within a v3 digital certificate were originally defined within
RFC 2459, which was
written in 1999.
Ongoing work regarding certificate extensions
is defined, codified, and approved (via open and standard internet
process) by the
The PKIX is the organization which generally works
on the definition and specifications of X.509 PKI.
Note - Netscape also had an early certificate specification
which is still supported in certain software implementations, but I will not
discuss that specification further due to length considerations
Rather than consider the exhaustive list of all extensions which are defined
by PKIX and the various RFCs, it's appropriate to again limit our focus to
the the types of certificates which are needed to build an Web-PKI.
These types have been mentioned before, and are likely the type or
types of certificates that you have already seen and approved for
activities on your own machine, if you use the internet for
your personal or professional business already.
Let's start by by analyzing an end-user server certificate.
This is type of certificate that might be issued to you as
the administrator of of a private/internal business website.
Alternatively, as a secure website user, you have acknowledged
and accepted one or more of this type of certificates to
deliver your secure information across the internet.
Before looking at the guts of this type of certificate,
you can download the
complete Server certificate,
if you wish.
You'll notice that the previous link includes the certificate itself,
in a pure text format which looks like this:
Of course, the text form doesn't really help much to understand what
the certificate looks like.
In actuality, a certificate is constructed
as a formal data structure in a binary form, and populated with
the data from the certreq, discussed previously, and the
signing key from the CA. It's this
binary form that is stored in the device or process which
uses it to communicate securely. The text form above is
simply a way to transmit a certificate.
Also included in the link above, is the "text-dump" of the
properties which are contained within the certificate.
By analyzing the
we can learn everything we want to know about the certificate.
Analysis of an End-User Server Certificate
X509v3 Client Certificate Fields and Extensions
- Version - indicates that this is a X509v3
- Serial Number - indicates that this is the first end-user
certificate issued by the CA, although serial numbers
may not always be ordered in this way. Each individual
CA may use its own. In the various documents I read to
researching this article, the PKIX does not supply guidelines regarding
serial numbering, except perhaps that the serial number be unique
within its parent authority.
- Signature Algorithm - the signing key pair for
this certificate is based on RSA, using MD5 hashing.
(Saying more than that about this element is fodder for a
complete article, and well beyond the scope and interest
level of this practical intro.)
- Issuer (DN) - The DN for the CA which issued this
In this case, with the CN=Roadkill Server CA. (The structure
and functionality of the CA and Root is covered later)
- Validity - the certificate expires 90 days after it
was issued. This also happens to be the lifetime (expiry) of the
- Subject (DN) - this is the all-important Subject DN,
which is built in the process of
making the certificate request.
By convention, the CN component of the DN in a server certificate
should always contain the valid DNS name of the server which it
certifies, although there exists no convention in client software
as to the action taken if the CN does not contain the proper
- Subject Public Key Info - the Subject key pair for
this certificate is based on an 512 bit RSA public key.
- X509v3 extensions - here's where the real strength
of v3 certificates is found. Some of them, such as basic
constraints, are standard for end-user certificates. The
most interesting extensions are related to key usage. The
Extended Key Usage extension specifically says what
this certificate was intended for, namely, server authentication.
Each of the values in the key usage class are directly
passed in from the signing (CA) certificate, and therefore
the Roadkill Server CA must also contain the same key usage
capabilities which it passes in. In the case of the Roadkill
Server CA, these were also inherited from a parent, the
Roadkill Root CA.
The Roadkill CA is a multi-tiered CA, and will be the
topic of my next article in this section.
- Signature Algorithm - this identifies the algorithm used
by the CA to sign the certificate. Again, saying more than that
is beyond the scope of this article.
for our demonstration has its own distinct list of fields and extensions.
Some of the fields are the same as for the server certificate, however.
This client certificate contains the
same sort of features as one that you might get from your bank, for
example, to access your account online.
The OU in the this certificate's DN is customized, to allow
someone (you) to gain access
as a "guest". Distributing this sort of a "bootstrapping" certificate
allows the server to run exclusively in a stricter mode of SSL that requires client
certificates for all access.
This certificate is also signed by a different intermediete CA.
The Roadkill Client CA
is a CA which signs client certificates only, based upon specific authority
granted to it from the Root. Again, the Extended Key Usage specifies
what the intent of the certificate is, and note that instead of Key
Encipherment as a Key Usage value, the client certificate has
a different value called Non-Repudiation. Non-Repudiation is a difficult
concept to define, but in the context of a client certificate, it
essentially tries to guarantee the operator of the server to which
you are connecting, using the certificate, that you will pay your bills.
That's just one possible definition of Non-Repudiation. There are
others, as we'll see for Codesigning certificates, for example.
The definition of Non-Repudiation in fact continues to be a widely debated topic,
and that's probably a good thing. In any case, as already stated,
a proper examination of the meaning of key usage attributes is
fodder for a complete article.
Finally, take careful note of the Subject public Key. You'll be
referring back to it after you look at the Codesigning certificate
X509v3 Codesigning Certificate Fields and Extensions
is the last one we'll be looking at.
This is the type of certificate which might be issued to
a company, or an individual developer, for signing code which
is deployed as part of a web application.
Again, the codesigning certificate is signed by a Intermediete CA
beneath the Roadkill Root CA, this time it's the
Roadkill Codesigning CA, and again the subject CN is
specifying the entity for which the certificate is designated,
the demo user or developer.
As well, the Extended Key Usage again specifies the actual intent for
the certificate, and again the certificate requires the
Non Repudiation value. In this case, however, the non-repudiation
is assigned to the distributor/server of the web application,
instead of the user/client of the web. In this way, Codesigning certificates
are also like Server certificates, in that they authenticate and
"guarantee" the web owner. You may have run signed code
(DLLs, Shockwave, Java, etc) on your machine in the past,
after being prompted whether to accept (trust) the certificate which
signed the software, and its CA.
Especially interesting in this case is the public key for the subject.
Note how it is exactly the same public key that is used by the Client
certificate. Both certificates were created with the same key pair.
This is a common scenario, for example, in a development environment where
a developer must have a codesigning certificate as well as his standard
web-client certificate. Using the same keys to create multiple certificates
is a convenient option, but may or may not be available to you for
a given CA. However, if you create your own CA, then you, and the other
members of your CA can make your own policies.
Summary - What have we learned in this boring-assed series?
This series of articles has introduced the basic concepts and mechanics of digital certificates,
with an eye towards implementing a simple Web PKI. There are many other
purposes for which X.509 certificates can be used, of course, but the three which
comprise a Web PKI, Client, Server, and Code Signing, do bundle
together quite nicely, and provide a working example of a commonly-implemented type of
CA. This series only touched upon the subject of certificate
key pairs, signature algorithms, and ciphers. Again, these topics call for an extended
analysis which is beyond the scope of an introduction, and is largely independent of
X.509 certificates themselves. Another thing that has only been touched-on in this
series is CA certificates. Our focus has been primarily limited to so-called end-user
certificates, the kind that the average reader might be obtaining.
Ideally, the reader does have a better idea now, of what certificates are, how to get one, and
how they're built. There's really no magic, or dark mystery in this topic - anyone who
uses a certificate, regardless of the purpose/activities for which they are using it, should
have some basic familiarity with them.
There is a tremendous amount of hype and "salesmanship" available on the web, regarding
certificates and PKI implementations which come from one provider or another. Additionally,
there are many so-called "gurus" out there who love to scream "dont trust them!", when
talking about PKI and X.509, the inference being that there must be a hole in the implementation
somewhere, and when it is found, your identity will be comprimised and sold (cheap) all
around the world.
To all of this hype and naysaying, I politely say, bunk. Certificates and PKI should
not be expensive, and neither are they the answer to all of lifes problems. What they do
provide is an level of security in your electronic transactions which exceeds
that which you'll find with simple passwords or password calculators, and especially cookies,
which all too many sites still use. The US government, for example, has begun to adopt
X.509 PKI in a big way. Several large organizations within the Department of Defense,
have converted major systems over to PKI-based access and single-sign-on with certificates,
Central Contract Registration (PDF)
system. The DoD has had other successes, along with other governmental departments
in the Federal government, which I'll review in an upcoming article. The point is
that PKI is coming, whether you like it or not, or trust it.
Of course, there's plenty of other warts to point out with PKI based on X.509,
as well. Applications which use certificates still have no uniform standard
with how to treat a certificate which is suspicious, for example. Some refuse
to do anything, others present dialogs which try to give fair warning, but
miss the mark in describing the nature of the certificate anomaly.
Hopefully, comments below will also point out other potential flaws.
Neither do I claim to be any sort of expert in the field, albeit I
do find myself in the role of a limited advocate for the technology.
Consider as well, that once the Department of Defense
is sold on a concept, there's going
to be a lot of money made by the people who can develop and implement it
best. I can recall turning up my nose at other technologies that have
come along, only to find my nose slightly out of joint when salaries
for delivering the technology went through the ceiling a few years ago.
Perhaps the industry is a bit more sensible regarding salaries these days, but security
must take a bigger role, as we all know, and X.509 looks to be the
way it is going, although other implementations
are to be found.
Coming up next - Simple Web PKI
My next article in this section, will delve alot deeper
into the CA certificates which form the basis of the Roadkill CA,
and begin to introduce how they might be used as the foundation for
a web PKI, as promised. In an attempt to
catch your interest with this article, I've also tantalized you
with the possibility of access to
a little page that will tell you if you are among the most
important people on this site. Imrdkl's Ark, if I may be so bold.
You may have tried to access it above, but found that you couldn't
get in. If you really think you're ready to come on board, then
go here first, and then
come aboard again.