An Application Security Overview. Part I: A Certificate Introduction

An Application Security Overview:  Part I:  A Certificate Introduction

Requirements: The CertMgr component, which is included in IP*Works!, IP*Works! S/MIME, and IP*Works! EDI / AS2.


Preface

Today's computer security revolves around key concepts and ideas implemented through complex mathematical algorithms. Terms such as encryption, digital certificates, SSL, S/MIME, etc. are all part of today's security requirement reality. However, at /n software, we believe that a company should not have to sacrifice efficiency and rapid application development to provide security solutions in their applications. Toolkits such as IP*Works!, IP*Works! S/MIME, and IP*Works! SSH encapsulate complex protocol and security logic into easy to use components, enabling developers to focus on their business requirements. These toolkits provide a simple yet powerful interface for secure Internet protocols such as HTTPS, FTPS, LDAPS, S/MIME, SShell and many others.  The series An Application Security Overview will focus on:

  • Part I - A Certificate Introduction: An overview of certificates and the CertMgr component.
  • Part II - SSL and SSH: An overview of each standard, commonly used controls in the IP*Works! and S/Shell toolkits, establishment of trust in a high level protocol, and some analysis on which security protocol would best fit your application's requirements.
  • Part III - S/MIME and EDI: Data integrity and assurance principles with IP*Works! S/MIME and EDI toolkits, combining various IP*Works! toolkits to implement other security standards such as the HIPAA standards.

Part I: A Certificate Introduction

Contents

Introduction - What is a Digital Certificate?

So what is a certificate? A digital certificate is an electronic "passport" that establishes your credentials when doing business or other transactions through the internet. Every digital certificate is issued by a Certificate Authority (CA), which establishes the certificate's credentials. If the CA is trusted then the certificate that the CA issued is also trusted, otherwise the certificate will not be trusted. The degree of trust of a certificate will become an important role in the security of the protocols and standards that use digital IDs such as SSL, SSH, S/MIME, etc. We will take a look at the security implications that a low degree of trust in a certificate can cause in these protocols in the second part of this series. For now, I'll focus on understanding public key certificates, Digital IDs, the different fields in certificates, certificate storage in different platforms, and the CertMgr control's certificate management and generation features.

Types of Certificate Formats - Certificate vs. Digital IDs

Public Key Certificates

Public Key certificates contain only the public key of a certificate (no private key). These certificates are used to verify digital signatures (once signed by the private key or Digital ID corresponding to this public key) or encrypt data (which will be decrypted only by the private key of the certificate). A public key certificate file can be stored in DER or PEM formats. DER files are binary, PEM files contain base-64 encoded data.

Digital IDs

Digital Certificates that contain the private key in addition to the public key are called Digital IDs. These private keys are used to sign and decrypt data. Digital IDs are issued by CAs and they are trusted by evaluating their certificate chain. Simply put, the certificate chain is the path of all CAs that are involved in the generation of the certificate. Usually, the root of the certificate chain is the issuer of the certificate (the CA) and the last node of the certificate chain is the certificate itself. The private key is kept confidential and it is never disclosed with other parties.

Certificate Fields - What is a Certificate Composed of?

The latest X.509 standards dictate that a certificate can hold as many as 11 different fields. The CertMgr component, designed for certificate generation and management, supports all the fields described below:

Version The version field identifies the version of the x.509 standard that the certificate conforms to. As of the writing of this document, the latest version of the x.509 certificate standards is version 3.
Management CertMgr will show the certificate version for a selected certificate in the CertVersion property.
Generation The control will generate version 3, however, if other versions are required please email us at support@nsoftware.com and we should be able to help you configure the control to sign certificates for other versions. Please note however that the latest specifications are recommended.

Serial Number The serial number is a unique identifier of the certificate from the issuer (CA). The certificate authority should make sure that the serial number for each certificate that it issues is unique.
Management CertMgr will report the serial number of a certificate through the CertSerialNumber property
Generation When creating certificates, make sure that the serial number of each certificate issued is unique. To remind the developer to specify a serial number for the certificate that is issued, the CertMgr control's CreateCertificate method takes as one of the parameters the serial number for the certificate.

Signature algorithm This field represents the algorithm used by the CA when it signed the certificate. This field is called "signature" in the specs, however the naming convention here can be confusing. There is no signature in this field. Nothing is signed here; this is just a representation of an algorithm.
Management CertMgr reports the certificate's signing algorithm through the CertSignatureAlgorithm property. Please note that this is not a field that dictates what signature algorithms this certificate can be used with.
Generation The certificates that are generated by the CertMgr component will use the default signature algorithm of the CSP (cryptography service provider) used by the system. Most likely, the algorithm used by the CSP will be SHA1.

Issuer The issuer field identifies the CA that issued this certificate. The format of the issuer field is a distinguished name (DN). A DN can be looked at as a hierarchy, a way to specify various information (such as country, state, province) about the issuer through a logically structured format, usually starting from country and working it's way to down to the name of an individual. In practice, the format is very loose and most CA DNs will contain various company information as well as location data.
Management CertMgr reports the certificate issuer through the CertIssuer property.
Generation When you create a self-signed certificate using the CertMgr component's CreateCertificate method you are creating it from scratch and you don't have a CA at that given moment, so the issuer of the certificate will be the certificate subject (look at it this way: the certificate that you are generating is a self-signed certificate, it means that it will sign itself).

On the other hand, if you create a signed certificate using the CertMgr component's IssueCertificate method, the issuer of the certificate issued is your CA certificate's subject.

Looking at it from a practical standpoint, you would generate your CA's certificate through the CreateCertificate method, and you (as your own CA) would issue certificates by using the IssueCertificate method.


Period of Validity This field identifies the period in which the certificate is valid. It is bounded by the earliest period and the latest period that the certificate should be considered valid.
Management CertMgr will report the certificate's validity through the CertEffectiveDate and CertExpirationDate properties.
Generation When generating a certificate the CertValidityTime configuration setting will allow for the developer to specify the number of days for the certificate's validity period from the date that the certificate was issued.

Subject This field is arguably the most important (security-wise) field of a certificate; it contains the information that identifies the party being certified. This means that if you are generating a certificate, the subject is the field that contains information about the entity that you will issue the certificate to. For example, all trusted CAs (such as Verisign, Thawte, and Comodo Security) will use this field to identify the entity that they are issuing the certificate to, and these CAs will verify this information before they put it there. This field, just as with the Issuer field, is a DN. The most important part of that DN is the common name (CN). This value identifies the actual name of the certificate being verified.
Management CertMgr reports the certificate's subject through the CertSubject property.
Generation When creating a self-signed certificate or issuing one, the certificate subject is passed as a parameter to the CreateCertificate or IssueCertificate method.


There are a few other fields that we will not mention here because they are managed automatically by the CertMgr component.

Certificate Management

Digital IDs are found in certificate stores.  A certificate store is nothing more than a collection of one or more certificates in a storage unit such as a file, registry entry, blob in memory, etc. The most commonly used technique for storing a digital ID is with a PFX file certificate store. These are usually .pfx or .p12 files for which the format is dictated by the PKCS #12 standard. Please note that we are talking about digital IDs (recall: A digital ID is a certificate which contains the private key) so these files store both the public and the private key of the digital ID. There can be more than one digital ID per store (files are no different; there can be more than one digital ID in the file).

Windows, unlike other operating systems, offers a very unique way of certificate management - certificate stores based on your access in the registry. Some of the most important certificate stores in Windows are:

  • Personal (MY) store which usually contains all your digital IDs.
  • Trusted Root Certification Authorities (CA) store which contains the public keys of all CAs trusted by the machine and/or the user.
  • Intermediate Certification Authorities store which is important because it contains the Certificate Revocation Lists (CRLs). These lists are generated by CAs when they do not want to guarantee the credentials of a certificate that they issued in the past. This could happen because the certificate has expired or any other reasons set by the CA. When this list is correctly installed in your machine, the machine/user will not trust the certificates in the CRL, bypassing the trust state of the certificates signed by that CA.

There are a few security restriction issues with registry certificate stores in Windows because these stores, just like most keys in the registry, are based on the access level of the user (including permissions to machine level keys). Take for example a web application project (being developed in ASP.NET) that requires access to the machine store "MY" to access a digital ID which it needs to authenticate itself with another host. By default, the worker process for ASP.NET (aspnet_wp.exe) runs under the local machine account to restrict access to domain resources and provide a more secure environment. ASP.NET running with these permissions cannot access the machine certificate store MY. As a workaround, the digital ID can be exported to a PFX file which is located in a path that ASP.NET has permissions to read from (i.e. Server.MapPath("/")).

On all *nix platforms (i.e. Unix, Linux, BSD, Mac OS X, etc.) certificate management is done through file stores. If you want to trust a certain list of CAs in your application, you will need to generate your own CA file store which includes the public keys of all the CAs that you want to trust.

The JRE's (Java Runtime Environment) certificate management is somewhere in between Windows and *nix platforms. The JDK includes a CA file which contains a collection of all the CAs that the JRE trusts by default. This file is found at %jdk_home%\jre\lib\security\cacerts. Every java application that will be run within the JRE will only trust the certificates issued by the CAs present in the "cacerts" file. The "cacerts" file in the JDK is equivalent to the Intermediate Certificate Authorities store in Windows.

CertMgr - The Certificate Manager Component

The CertMgr control is included in the IP*Works!, IP*Works! S/MIME, and IP*Works! EDI / AS2 toolkits.

Restrictions and minimum requirements:  In order to use the CertMgr component, you must have a security provider installed in your development machine:

  • On Windows you won't have to worry about this unless you are using Windows 95 or 98, which did not ship with the security libraries necessary for these operations.  There are steps you can take to install these libraries onto Win9x - if this is something you want to do, please contact our support team at support@nsoftware.com.
  • Java developers, note that JDK1.3 and below did not ship with a security provider, so in order for a security provider to be present, JDK1.4 or above can be used. JDK1.3 can also be used but the JSSE distribution must be installed manually in the jdk's path.
  • On *nix and Mac OS X machines you will need to have openssl installed.

Previously, in the certificate fields section, I explained how CertMgr comes into play when a certificate is created or for management of certificates installed on a machine.  To better explain the use of the CertMgr component, take a look at the CertMgr demo that is included in the product download. This demo can be found in the demos folder.

Listing certificate stores and the certificates within them can be very handy, especially when it comes to searching a certificate store for a certain certificate that must be used for client authentication, signing, etc. The CertMgr control offers this functionality through the ListCertificateStores and ListStoreCertificates methods. The ListCertificateStores method will list all the registry stores in a Windows operating system. The ListStoreCertificates method will list all the certificates in a particular certificate store, firing the certList event for each certificate found. Please note that it does not matter what kind of physical storage the certificate store has, the ListStoreCertificates will work nonetheless.

The generation of certificates with CertMgr makes the control one of the most important components in any of our secure toolkits. Generating a certificate with CertMgr is as easy as answering the two questions below.

Will you be issuing multiple certificates?

If so, then you will need to establish yourself as a CA, and then your CA will issue the certificates. This will establish a common root for all the certificates that you issue, and it will also create a common node for establishing trust for all of them.  The process of creating a certificate with the CertMgr component is explained under the Issuer field description of the "Certificate Fields" section of this document.

How secure do I want my certificate to be?

This question will establish a couple of settings for this certificate such as the expiration date and key length. The expiration date corresponds to the "period of validity" certificate field explained earlier, and it can be set through CertMgr's CertValidityTime configuration setting. Please note that the smaller the validity time, the most often you will need to re-issue the certificate and the more secure the certificate is (because this limits the amount of time that a potential attacker has to crack or guess your private key). The key length of a certificate is set through CertMgr's CertKeyLength configuration setting. This setting is self-explanatory, it basically determines the length of the new public key (in bits). The default value in most cases is 1024. The greater the key length, the more secure the certificate but the longer it takes for an application to perform operations using the certificate.

Another great feature of CertMgr is its ability to generate certificate requests. Most CA's today require a certificate request to be generated from your application (i.e, commonly a webserver) which will use the certificate. With the CertMgr component you can create these certificate requests programmatically making the certificates that are issued by other CA's custom to your application's runtime.

The CertMgr component has a lot of other features that are useful in particular situations, for example the management of RSA keys. These features, while not covered in this tutorial, are fully covered in the CertMgr demo included with the installations of IP*Works! , IP*Works! S/MIME, and EDI Integrator.


We appreciate your feedback.  If you have any questions, comments, or suggestions about this article please contact our support team at kb@nsoftware.com.