7 18 1 Introduction to Certificates

LANSA Integrator

previous page next page

7.18.1 Introduction to Certificates

What is a Certificate?

A certificate is a public key labeled with information to identify its owner (Subject Name) and to control its use.

What is self-signed certificate?

A self-signed certificate is one for which the Issuer Name (signer) is the same as the Subject Name (owner).

What makes a certificate a CA certificate?

When it is used to issue other certificates.

It also contains information (extensions) that support its roles of issuing certificates (CRLDistPoint, BasicConstraints etc...)

It should also contain the BasicConstraints extension with the CA flag set to true.

Root or top-level CA certificates are self-signed.

What is the certificate thumbprint

The certificate thumbprint is a hash calculated on the whole certificate.

This thumbprint is calculated every time a certificate is displayed - it is not contained in the certificate.

What goes into a Certificate?

The X.509 standard defines what information can go into a certificate, and describes how to write it down (the data format).

All X.509 certificates have the following data, in addition to the signature:

Version	Identifies which version of the X.509 standard applies to this certificate. This affects what information can be specified in it.
Serial Number	The entity that created the certificate is responsible for assigning it a serial number to distinguish it from other certificates it issues. This information is used in numerous ways, for example when a certificate is revoked its serial number is placed in a Certificate Revocation List (CRL).
Signature Algorithm Identifier	The algorithm used by the CA to sign the certificate.
Issuer Name	The name of the entity that signed the certificate. This is normally a CA. Using this certificate implies trusting the entity that signed this certificate. Note that in some cases, such as root or top-level CA certificates, the issuer signs its own certificate.
Validity Period	Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century. The validity period chosen depends on a number of factors, such as the strength of the private key used to sign the certificate or the amount one is willing to pay for a certificate. This is the expected period that entities can rely on the public value, if the associated private key has not been compromised.
Subject Name	The name of the entity whose public key the certificate identifies. This name uses the X.500 standard, so it is intended to be unique across the Internet. This is the Distinguished Name (DN) of the entity, for example, CN=Road Runner, OU=Rocket Powered Systems, O=Acme Corportation, C=AU (These refer to the subject's Common Name, Organizational Unit, Organization, and Country.)
Subject Public Key	The public key of the entity being named, together with an algorithm identifier that specifies which public key crypto system this key belongs to and any associated key parameters.

Versions

Version 1 has been available since 1988, is widely deployed, and is the most generic.

Version 2 introduced the concept of subject and issuer unique identifiers to handle the possibility of reuse of subject and/or issuer names over time. Most certificate profile documents strongly recommend that names not be reused, and that certificates should not make use of unique identifiers. Version 2 certificates are not widely used.

Version 3 is the most recent (1996) and supports the notion of extensions, whereby anyone can define an extension and include it in the certificate.

Some common extensions in use today are:

KeyUsage (limits the use of the keys to particular purposes such as "signing-only")

AlternativeNames (allows other identities to also be associated with this public key, e.g. DNS names, email addresses, IP addresses)

Extensions can be marked critical to indicate that the extension should be checked and enforced/used.

For example, if a certificate has the KeyUsage extension marked critical and set to "keyCertSign" then if this certificate is presented during SSL communication, it should be rejected, as the certificate extension indicates that the associated private key should only be used for signing certificates and not for SSL use.

Encoding Format

All the data in a certificate is encoded using two related standards called ASN.1/DER. Abstract Syntax Notation 1 describes data. The Definite Encoding Rules describe a single way to store and transfer that data.

In the X.500, X.509 and X.520 standards the structures are specified with Abstract Syntax Notation 1 (ASN.1) and are encoded for transport using the Basic Encoding Rules (BER) that encode ASN.1 as 8-bit binary data.

In addition, when they represent data to be signed, as they do within certificate management, the signature is calculated on the data encoded using Distinguished Encoding Rules (DER: a subset of BER which has the property that the same data always encodes to the same binary representation).

Information stored in a certificate is a sequence of ASN.1 Objects each labeled with an object Identifier (OID).

An object identifier is a string of numbers identifying a unique object, for example, a certificate extension or a company's certificate practice statement.

OIDs are controlled by the International Standards Organization (ISO) registration authority.

In some cases, this authority is delegated by ISO to regional registration authorities.

The OID is a unique sequence of hierarchical numbers in a dot notation.

Top level OID assignments:

	0	ITU-T assigned
	1	ISO assigned
	2	Joint ISO/ITU-T assignment

Secondary level assignments:

2.5

X.500 Directory Services

Other level assignments:

	2.5.4	Object Identifiers for X.500 attributes type
	2.5.4.3	Common Name
	2.5.4.5	Serial Number
	2.5.4.6	Country Name
	2.5.4.7	Locality
	2.5.4.8	State
	2.5.4.10	Organization
	2.5.4.11	Organizational Unit

	2.5.29	Object Identifiers for Version 3 extensions
	2.5.29.14	Subject Key Identifier
	2.5.29.15	Key Usage
	2.5.29.17	Subject Altervative Name
	2.5.29.19	Basic Constraints
	2.5.29.35	Authority Key Identifier

Certificate viewed using a generic BER viewer:

Critical and Non-critical extensions

If an extension is critical it can only be used for the purposes indicated.

If an extension is non-critical it is an advisory field and not restrictive.

Standard CA Key Usage Dialog:

Standard Certificate Key Usage Dialog:

Key Usage

The critical key usage extension controls how the public key can be used.

RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile describe the role of the different key usage extensions bits.

CRL Sign is enabled when the public key is used for verifying a signature on a CRL. Enable for CA certificates.

Data Encipherment is enabled when the public key is used for enciphering user data, other than cryptographic keys.

Decipher Only and Key Agreement are enabled, when the public key is being used only for deciphering data while performing key agreement.

Digital Signature is enabled when the public key is used with a digital signature mechanism to support security services other than non-repudiation, key certificate signing, or CRL signing. Enable for SSL client certificates and S/MIME signing certificates.

Encipher Only and Key Agreement are enabled, when the public key is being used only for enciphering data while performing key agreement.

Key Agreement is enabled when the public key is used for key agreement.

Key Certificate Sign is enabled when the public key is used for verifying a signature on certificates. Enable for CA certificates.

Key Encipherment is enabled when the public key is used for key transport. Enable for SSL server certificates and S/MIME encryption certificates.

Non Repudiation is enabled when the public key is used to verify digital signatures. Enable for S/MIME signing certificates and object-signing certificates.

previous page start next page