An Application Security Overview: Part I: A
Certificate Introduction
By Orial Lazimi, /n software.
Requirements: The
CertMgr component, which is included in
IP*Works! SSL,
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! SSL, 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! SSL 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 (signature)
|
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! SSL,
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!
SSL, IP*Works!
S/MIME, and IP*Works!
EDI / AS2.
We appreciate your feedback. If you have any questions, comments, or
suggestions about this article please contact our support team at
kb@nsoftware.com.
