Certificates – “quickie”

Here comes a “quick” overview of certificates – how they work and what they are used for (it grew on me as I was writing….)



I’m sure you’ve heard of them and wondered what they really are and how they work – digital certificates.
You find them all over the digital world today – from digital signatures on small executables to the web pages of the world’s largest banks.
It is important that you know what they are, so that you can better employ them in your environment and also to protect yourself.

Certificates are small digital files typically used for:

  • validating an identity (server, user, service etc)
  • encrypting data (stored or in flight)
  • signing data

Certificates can be either private or official – meaning they have been signed by an internal private Certificate Authority (CA) or by an officially recognized CA that is known to be trusted.

Hashing, symmetric/asymmetric encryption and signatures

Hashing is the procedure of generating a unique, fixed size output from any input. It is meant to be a one way operation, but several hashing algorithms have been broken through the years.
If you input a certificates data into a hashing algorithm (i.e. MD5) the output will be unique. No matter how many times you run the same data through the hashing algoritm, the output will always be the same. However, if you change the input just the slightest, the output will change to something totally different. Also, it is imposssible to reverse a hash into the text that generated it. It is like “1+1+1+1+1+1=6” – but if you are given the “6” you don’t know what calculation “6” is the answer to.
To be able to hack a hash, you simply need to try all kinds of different inputs until one matches the output you want to spoof.
For that reason hashing algorithms are designed to be slow so that breaking them will be time consuming. It takes relatively long time to generate a hash from even the smallest amount of data, so that super computers will not be able to run through all possibilities and reveal the hash in a hearbeat.
Remember that spoofing a certain hash is not the challenge – the challenge is spoofing the hash while still making it look like the data being presented makes sense. In a certificate’s case it would still need to be humanly readable and make sense.

Examples: MD4, MD5, SHA-1, SHA-256

Symmetrical keys are simply keys that are the same – the same key that was used to encrypt can also be used to decrypt. This means anyone who gets hold of the key can read/alter the message without the final recipient knowing. A session key in https:// is an example of a symmetrical key.

This is why you must capture the initial SSL handshake to be able to decrypt SSL with Wireshark. That is where the session key is derived from the server’s private key, and so it is the only place where the server’s private key can be applied to reveal the session key that will allow you to peek inside the SSL traffic.

Examples: DES, 3DES, Blowfish, Twofish, AES (Rijndael)

Asymmetrical keys are what is used in PKI
(Public Key Infrastructure)

What is encrypted with a private key can only be decrypted with the corresponding public key, and vice versa. These keys are always produced in pairs.
They are most often generated locally on a system within it’s crypto system (in case the public key needs to be verified as belonging to it’s private partner, the public key + some other data is delivered to a CA for signing).
During SSL handshake the asymmetrical keypair is being used to generate a symmetrical key that is valid for the length of the session (also called session key). The certificate’s public/private key pair is NEVER used for encrypting the communications stream – it is simply used to negotiate a shorter/simpler session key. This is because it would be too labour intensive on the server’s side to encypt/decrypt with 2048/4096++ keys.

Examples: DH (Diffie Hellman), DSA (Digital Signature Algorithm) and RSA (most common – supports both encryption and signature).


PKI is the basis!

An asymmetrical key pair is the key to all.
One key, the private, should NEVER leave the local system (exeptions made for EFS (Encrypted File System) and such, where private key archival is used). Whatever has been encrypted with the private key, can be decrypted with the public key – and vice versa. As long as the private key is kept secret, the corresponding public key can be used to verify the origin of an encrypted message/data (requires that the certificate gets signed by a CA that the relying party trusts).

Common confusions in PKI:
  • Public key:
    A key used to decypt data encrypted with the corresponding private key.
  • Private key
    A key used to decypt data encrypted with the corresponding public key.
  • Certificate
    A signed version of the public key + some other data such as the entity’s name (CN=server1), DNS name (Subject Alternate name DNS=server1.example.com)
  • WYSIWYG (What You See Is What You Get) – No, most likely not.
    When you inspect a certificate in Windows, there will be a few fields with properties that are actually from the certificate file – whereas many fields/properties will be computed from the certificate file data.
    certfields01 certfields02
    First are the actual certificate fields, then the certificate extensions and finally computed fields.
  • Thumbprint
    The thumbprint is NOT part of the certificate – it is a hash that is being calculated on the certificate when it is read. If this hash is to be used for some kind of validation between communicating parties – it is vital they both compare a hash calculated using the same hashing algorithm.

Root CAs or Trust Anchors

Any certificate that should be trusted needs to chain up to a “trust anchor” – a certificate from a Root CA (official or internal to an organization – it doesn’t matter) that has been accepted by the user/computer/application as trustworthy. Such Root CA certificates live in certificate stores – the OS has one and so does other applications (i.e. Internet Explorer).


To be able to validate an identity, we need to trust someone at some level. This “someone” in reality is whatever trusted authorities the operating system vendor has put in the operating system trusted store at point of release and through OS updates. Typically there will be some 10+ really large organizations specializing in validating identities (Certificate Authorities or CAs) already in the OS’s trusted store before you add your own (optional).
As the user of i.e Windows 7, you inherently trust all certificates issued by the CAs already in Windows 7’s trusted store. That means that if some web site presents a certificate issued by one of the CAs in the store, you automatically trust that certificate, and the web page will use https without any more adue. Had the certificate been issued by a smaller CA or even a private CA (you can set up your own internally), you would’ve been presented with the certificate and asked whether to trust it or not before continuing.
If you choose to trust a CA not already in your OS’s trusted store, you need to realize that ALL other certificates issued by that CA also will be trusted.
So what makes a CA trustworthy? Different CAs use different levels of background checking before issuing a certificate. There are also different levels of certificates (seen that green address bar that some certificates give your browser – that is a highly trustworthy certificate that the site paid lots of money for) that you can buy from the different vendors. All that being said, as long as the CA is trusted by the OS all certificate types from any vendor (be it Thawte or your own internal CA) are technically equal and valid.

OS/Application certificate stores

All operating systems have some sort of store where they keep a collection of certificates from CAs they trust. Some applications also keep their own store that they use for reference – Java on Linux being one example. This enables the Java application to trust sources that the OS shouldn’t necessarily trust.
A store typically contains “Trusted Root CAs”, “Trusted Intermediate CAs” and locally installed certificates (certificates that the local computer can present to clients accessing services on the computer). Locally installed certificates can also be certificates that this server gets presented from a communications partner – some applications require them to be installed locally for comparison.

Certificate chaining/Certification Path Processing

All certificates have what is called a certificate chain – that is a “route” up to the Root CA that is responsible for the issuance of that certificate. A server certificate can point to an Intermediate CA that issued it’s certificate. That Intermediate CA can the have a certificate that points to a new Intermediate CA or a Root CA.
A root CA will always be it’s own issuer, there is no one above (that is the very definition of a root certificate).
To be able to verify a certificate’s chain, you either need all certificates in the chain in the local computer’s certificate store – or at least the Root CA certificate. Intermediate certificates can be validated “on the fly” – that is the local computer can go online and check the validity of the certificate’s issuing CA, which then again checks the validity of the CA that issued that certificate and so on.
But when the check finally reaches a certificate that was issued by itself (the very definition of a root certificate) then that Root CA’s certificate need to be in the local computer’s “Trusted Root CA” store. To make this possible it is neccecary that all CA certificates be downloadable for the local computer, or else it will not be possible to perform the check (they are typically placed on highly accessible web servers).
If some certificate is revoked (the issuer replaced it due to technical reasons or it has been c ompromised) that certificate is placed in the CA’s CRL (Certificate Revocation List). This file needs to always be available and the CRL location is always part of the properties of a certificate.


How certificate validation is performed

  1. Chain building
  2. Chain validation

When a certificate has been presented to the local computer (i.e by a web site), the local computer pays careful attention to certain fields within the certificate:

  • Certificate validity – the certificate needs to be within it’s validity period. If not it is discarded as not trustworthy.
  • Subject & Issuer – if these are the same it knows this is a root CA’s certificate.
  • Subject Key Identifier – used in chain building
  • Authority Key Identifier – used in chain building
  • AIA (Authority Information Access) – this is where information about the certificate’s issuer can be found.
  • CRL (Certificate Revokation List) – this is where the CA that issued this certificate places it’s list of certificates that should no longer be trusted.
  • Basic Constraints – End Entity must be “NO” for a CA.
  • Signature hash Algorithm – used to verify the certificate origin.
  • Thumbprint – this is the certificate’s unique identifier. The CA that issued the certificate will keep a list of thumbprints for all the certificates it has issued.

Different OSs perform their certificate validation checks at different degrees of thoroughness. Ideally this is what should happen:

  1. Certificate path is built from leaf to root
  2. Certificate validation is done from root to leaf
  3. Does Subject = Issuer? (proving this is a Root CA).
    Is this Root CA in the trusted store?
    No -> prompt user to accept new Root CA into trusted store, or abort check with error.
    Yes – Move on
  4. Certificate within it’s validity period? Yes -> move on
  5. Certificate valid as CA certificate? (CA=true) Yes -> move on
  6. Validate with Issuer/AIA that it actually issued this certificate.
    This is validated by running the certificate’s signature algorithm on certain parts of the certificate. Then the certificate’s signature is decoded with the Signature Hash algorithm using the issuing CA’s public key as input. If the 2 are the same -> Certificate is OK.
    In the case of Root CAs the Issuer/AIA will be the Root CA itself.
  7. CRL available? Yes -> move on
  8. Check CRL to see if certificate has been revoked ? Not revoked
    -> move on
  9. Now look at the next CA’s certificate and perform steps 4 through 8
  10. Repeat for all CAs
  11. Finally validate the leaf certificate.

Standalone vs Enterprise (AD integrated) CAs

In short commercial CAs are typically standalone and CAs internal to organizations running MS Active Directory are typically Enterprise (Intermediate ones – private root CAs are often Standalone so that they can be turned off for security reasons ).

  1. CA offers a few options to choose from when it comes to validity periods and how deeply the certificate is validated. Domain Validated, Organization Validation and Extended Validation all give the user a different degree of trust in the certificate.
    EV certificates are the ones that turn IE’s address bar green – typically used by banks etc.
    Depending on which validation is used the supplicant can have more/less attributes of the certificate filled in.
  2. Supplicant provides all other information that goes into the certificate themselves (as opposed to templates used by Enterprise CAs)
  3. Standalone CAs never know the private keys of their supplicants
  4. Standalone CAs issue certificates on a per CA administrator approval. That means it is the CA admin’s job to validate if a certain request from a supplicant should be met and a certificate issued. This makes the Standalone CA a very time consuming setup as opposed to the Enterprise CA.
  1. Used by organizations that are not official CAs, hence the logic behind DV, OV and EV makes no sense.
  2. Organizations will install the certificate of their own Root CA in the trusted root store of all their computers (servers and workstations) and thereby make it a trusted one.
    This is normally done through imaging or Group Policies.
  3. Enterprise CAs support the use of templates, which makes the CA able to decide on many properties on behalf of the supplicant.
    The supplicant typically needs to specify its name and what certificate template it wants to use (templates are typically named to identify their use – WebServer5yrs, UserCertLync, EFS etc). Within each of these templates are the settings needed to make the certificate useable with the application that it is intented to be used with.
  4. Being AD integrated, an Enterprise CA can extract information from AD and automatically sign and issue certificates that AD entities apply for. This makes an Enterprise CA highly efficient in issuing certificates.
  5. An Enterprise CA can be setup to archive private keys. Now, that might sound strange right? Remember this can only be done on certificates that the CA automatically issues based on information it finds in AD && that has been configured by the CA administrator to be able to be archived. Archival is an organizational decision – should it be allowed, and if so, on what types of certificates? Typically it is enabled on EFS certificates (Encrypting File System). This enables the CA administrator to reissue the public/private key to a user should the keypair be lost.
    This happens if the user’s computer is reimaged or could potentially be the result of a crashed computer. Had the key not been archived and consequently retrieved, the user would never be able to access his/her files ever again.
    This is the only time I know of when the CA would have a copy of the private key of a certificate (apart from the private keys to it’s own certificates of course).

Cross certification

Two different organizations with totally different PKI solutions in place can choose to trust one another’s CAs (be it root or at a lower level). When set up, certificates from OrgA are trusted in OrgB and vice versa.


  • Remember that all hashing algorithms WILL BE BROKEN sooner or later – it is only a matter of time.
    Data stored and protected by such will have little/no value in the future.
    Data communications today will be safe from eavesdroppers, but remember that large entities can pick up the data off the wire and save it for later days when it can be reverse engineered.
  • Cryptographic algorithms will also be subkect to breaking as years go by. Due to their nature of negotiating individual session keys, they will require slightly more data to “mine on” to be broken – nevertheless they should be considered unsafe for future replay/reverse engineering.


Needs work:

  1. What exacly is being hashed for use as the basis for the signature hash?
  2. SSL  in Wireshark. If you use a Base64 .pem-file containing ONLY the private key, will Wireshark be able to decrypt any protocol within SSL, or only a select few? Do you specify “Data” or the name of the protocol?

Leave a Reply

Your email address will not be published. Required fields are marked *