Previous Tip  |  Next Tip  |  Index (recent)   |  Design Tips   | [Bill's Home]

242. Digital Certificates

It is possible for Bob to sign a message with his private key, and that it is then decrypted by Alice with his public key. There are many ways that Alice could get Bob's public key, but a major worry for her is that who does she trust in receiving his public key. One way would be for Bob to post his public key on his Web site, but what happens if the Web site is down, or if it is a fake Web site that Alice uses. Also if Alice asked Bob for his public key by email, how does she really know that Bob is the one who is responding? Thus we need a method to pass public keys, in the verifiable way. One of the best ways is to provide a digital certificate which contains, mainly the public key of the user or device which is being authenticated. Obviously anyone could generate one of these keys, so there are two ways we can create trust, one is to setup a server or our own network which provides the digital certificates for the users and devices within an organization, or we could generate the digital certificate from a trusted source, such as from well-known Certificate Authorities (CAs), such as Verisign, GlobalSign Root, Entrust and Microsoft. These are generated and have their own electronic thumbprint to verify the creator, and thus can be trusted by the recipient, or not. Typical digital certificate are: [Click here to download of the solution]

•  IKE.
•  PKCS #7.
•  PKCS #10.
•  RSA signatures.
•  X.509v3 certificates. These are exchanged at the start of a conversion to authenticate each device.

A key factor to integrated security is the usage of digital certificates. These are an excellent way of distributing the public key of the owner. The file used is typically in the form of X.509 certificate files. Figure 1 and Figure 2 shows an example export process to a cer file, while Figure 2 shows the actual certificate. The standard output is in a binary format, but a base-64 conversion can be used, such as for the following:


The CER file format is useful in importing and exporting single certificates, while other formats such as the Cryptographic Message Syntax Standard - PCKS #7 Certificates (.P7B), and Personal Information Exchange - PKCS #12 (.PFX, .P12) can be used to transfer more than one certificate. The main information will thus be:

•  The entity's public key (Public key).
•  The issuer's name (Issuer).
•  The serial number (Serial number).
•  Start date of certificate (Valid from).
•  End date of certificate (Valid to).
•  The subject (Subject).
•  CRL Distribution Points (CRL Distribution Points).
•  Authority Information (Authority Information Access). This will be shown when the recipient is prompted to access the certificate, or not.
•  Thumbprint algorithm (Thumbprint algorithm). This might be MD5, SHA1, and so on.
•  Thumbprint (Thumbprint).

The certificate, itself, can then be trusted to verify a host of applications (Figure 3), such for:

•  Server authentication.
•  Client authentication.
•  Code signing.
•  Secure email.
•  Time stamping.
•  IP security.
•  Windows hardware driver verification.
•  Windows OEM System component verification.
•  Smart card logon.
•  Document signing.
•  and so on.

Figure 1 Exporting digital certificates

Figure 2 Exporting digital certificates

Figure 3 Options for signing

The C# code to read a cer file is:

using System;
using System.Security;
using System.Net;
using System.Security.Cryptography.X509Certificates;

namespace ConsoleApplication3
class Class1
static void Main ( string [] args)
X509Certificate cer = X509Certificate.CreateFromCertFile("c:\\test.cer");
System.Console.WriteLine("Serial Number: {0}",cer.GetSerialNumberString());
System.Console.WriteLine("Effective Date: {0}",cer.GetEffectiveDateString());
System.Console.WriteLine("Name: {0}",cer.GetName());
System.Console.WriteLine("Public key: {0}",cer.GetPublicKeyString());
System.Console.WriteLine("Public key algorithm: {0}",cer.GetKeyAlgorithm());
System.Console.WriteLine("Issuer: {0}",cer.GetIssuerName());

And the output from this is:

Serial Number:  C0DD5E19983C6F575EFE454E7E66AD02
Effective Date:  08/11/1994 16:00:00
Name:  C=US, O="RSA Data Security, Inc.", OU=Secure Server Certification Authority
Public key: 308185027E0092CE7AC1AE833E5AAA898357AC2501760CADAE8E2C37CE
EB35786454 03E5844051C9BF8F08E28A8208D216863755E9B12102AD7668819A05A24
Public key algorithm:  1.2.840.113549.1.1.1
Issuer:  C=US, O="RSA Data Security, Inc.", OU=Secure Server Certification Authority

It can be seen that this digital certificate defines the public key for the owner. It is thus an excellent way for a user or organisation to distribute their public key. Thus if a user sends an authenticated message, they sign it with their private key, and the only key which will be able to decrypt it will be the public key contained in the digital certificate:

Other related .NET articles I've written include:

- Design Tip 298. [.NET] HMAC-SHA1.
- Design Tip 243. [.NET] Base-64 or Hex hash values.
- Design Tip 242. [.NET] Digital Certificates.
- Design Tip 241. [.NET] Public-key Encryption.
- Design Tip 240. [.NET] Diffie-Hellman Method.
- Design Tip 239. [.NET] Symmetric Encryption (Private-key).
- Design Tip 238. [.NET] Obfuscation Part II.
- Design Tip 237. [.NET] Obfuscation Part I
- Design Tip 236. [.NET] Data packet capture (filters: IP, TCP, and so on).
- Design Tip 235. [.NET] Data packet capture.
- Design Tip 234. [.NET] Interface to network adapter.
- Design Tip 232. [.NET] Creating an SSH client.
- Design Tip 231. [.NET] Creating an SNMP client.
- Design Tip 216. [.NET] Client/server communications.
- Design Tip 210. [XML/.NET] XML and .NET.
- Design Tip 207. [.NET] Treeviews for interest.
- Design Tip 206. [.NET/Design] Design, evaluate, design, .....
- Design Tip 205. [.NET] Treeviews.
- Design Tip 203. [.NET] Replacing menus with Treeviews.
- Design Tip 202. [.NET/Flash] .NET and Flash - the perfect pair.