It’s OK this is a lot less hard going
than the Crypto page. But I think it’s important to be a bit comfortable with the terms and how the
generics work in order to understand what’s written in this page.
I call Digital Certificates : ‘passports’ really. Part of
the training program I helped to write about PKI explained this really
well, if I manage to find it again I’ll post it.
Think about what a passport is, its proof of identity
which is associated to a country. Hopefully using security techniques
to prove the authenticity in that the passport hasn’t been forged.
Digital certificates are literally no different, they
show an identity associated to a trust highearchy using cryptography to
prove the authenticity.
Go back to the Crypto page and think about the public
and private keys, and that the private key should only be held by you….
If the private key should only be held be you then it
would be fair to assume that your public key can identify you as the private
key holder. But just with the keys alone, you can’t unless somehow it’s
linked to an identity.
Digital Certificates are a way of showing the identity
of the entity that holds the private key of the corresponding public key
within the certificate itself. It’s a bit like saying your photo and name
in the passport is only held by you so it must be you. And since it’s
got a country’s crest on the front, they are vouching your identity as
a citizen.
So your certificate will contain some information about
you, your public key and it lifespan etc… but at the end of the day,
anyone could just replace your key with theirs, this is called a ‘man
in the middle’ attack. But if the information within your application
– Public key, info about you etc… and this is then signed by a root
certificate – this is like then putting the country’s crest on the passport.
Who ever is identified in the Root Certificate is happy that they have
made checks about your identity to a level that they are happy to say
that you are part of their group, or trust model.
If I go through what happens to make a digital certificate,
then we can go into what they look like and what’s contained in them.
You can go to many sites which offer trial certificates,
basically they all follow the same type of process.
You visit the site and navigate to apply for a certificate,
the site will ask you for personal information such as your name, address
etc… your computer will generate a public and private key pair for you
(how nice). Your Private key is stored in either the registry, a token
(USB Token or SmartCard) or database never to see the light of day until
you need it. The public key on the other hand will be sent to the CA as
part of your application. And then at the end of the application the site
you are at will collect the info and save this in a database.
Depending on how much they care if you are who you say
you are, they will conduct checks on the information to a level that they
are happy with (this is set out in the CPS – Certificate Practice Statement)
and then format the information that goes into a digital certificate request
using PKCS #10. PKCS is Public Key Crypto Standards, and #10 is used to
format the requests.
The request will contain, something called a DN or Distinguished
Name, this is a standard way of being able to identify an entity.
CN = Common Name
O = Organization
OU = Organizational Unit
L = Location
ST = State
C = Country (As defined in an ISO Standard for Country Codes)
E = Email
G = Given Name
So mine would be ” CN=Graham Dunnings, O=My Company,
OU=My Department, L=My Town, ST=Hampshire, C=GB, E=graham@dunnings.net,
G=Graham M Dunnings “
Using this, it ‘distinguishes’ me from any other identity
that may exist, and if it doesn’t you can add more OU fields until you
do.
For personal certificates, its normally Email addresses
that help the most. Unless its for a webserver where the CN would be the
servers DNS name… ie. www.dunnings.net
So this DN is then added to other information about what
type of things I want to use the certificate for, i.e. Email encryption,
authentication, code signing etc… these are formatted using OID’s called
Object IDentifiers, which there are hundreds of thousands of (for general
computing) but certain ones mean certain things in the certificate requests.
So it’s my DN, my Public key which was collected at the
site (normally called the RA – Registration Authority), the uses that
I want for my certificate and things like validity period.
Then it’s cryptographically signed by a private key belonging
to the issuer (or Root Certificate). This then creates a string that contains
all my information, and the information of the issuer. You can see my
information in a certificate called “subject” and the issuers
info is under “issuer” both of these are displayed as DN’s.
Depending on the security of the Issuer (or CA – Certification
Authority) the private key is normally held on kit called HSMs – Hardware
Security Modules, these are shit hot bits of kit that store Crypto keys
in a secure way, so say if I nicked it and tried to break into it, the
likelihood of me doing so without destroying either the box or the keys
is so remote, I’d have more chance winning the lottery without actually
buying a ticket.
Once signed and you get the encoded certificate, this
is written back the their database and then you can either go and collect
it and go through an installation process, or they will send it to you
in an installation Email. – Job done.
On any windows computer, do a search for .cer or .crt
then right click and open with notepad, you’ll see what a certificate
looks like encoded. There again, if you can live without that type of
boredom – don’t.
Have a look at what a digital certificate looks like in
IE.
In a certificate viewed in IE5, if you view the certificate
and select the Public Key (see below)

Now think back to the Crypto tutorial and think about asymmetric keys, the public and private key… I said that the public key was given out, but see the below to what it all means… Its in BASE64 which is a way of storing/displaying information in a format that doesn’t look like complete crap to the untrained eye, well in either format to the untrained eye, both will look like garbage, just a little more pretty. The structure is in ASN.1 which is a way of formatting data in a way that is meaningful to the computer that is processing it – I’ll explain a little more about what the below ‘crap’ is…

3048 0241 00D0 51DF E628 7459 3D62 23EB 3A11
B638 0F79 D341 5CBA 40EB 60A0 772E E8F0 2C64
6C14 BDBE 984B BFBF 977C 7F1E 2734 406E 9AD2
74C0 8A6F D921 24D0 D54A 60EB 6BCA CB02 0301
0001

Looking at the string above, see below for what the different numbers represents: – 30 – This denotes a “Constructed String of Unknown Length” (String) 48 – The Length of the “String” in (Hex) = 72 in Decimal 02 – This denotes that the String is an Integer (no decimal places) 41 – This denotes the length of the Integer in (Hex) = 65(octets) in Decimal And from the 00D0 to the end of CB02 on the 4th Line represents the Public Key and the rest of the string means: – 02 – This denotes that the number is an Integer (no decimal places) 03 – This denotes the length of the Integer in (Hex) = 3(octets) in Decimal 010001 – This denotes 65537, used as your E for the RSA algorthim.

There are documents that CA’s can post, the most relevant ones are the CPS and a Certificate Profile, a Certificate profile gets all technical about what the certificate is made up from. This is just a quick overview without going into ‘too’ much detail, I could list all the RFC and other standards that are used from one end of the process to the other, but I’ll save you from that for now, I may write another page to explain all that.