Managing certificates

This topic describes security certificates, and the following security concepts:

Central Governance certificate management

When using Transfer CFT with Central Governance, certificate management is performed by Central Governance. See  Central Governance registration concepts for details on certificates during installation and registration.

What is a certificate?

A certificate is an electronic document used to identify an individual, a server, a company, or other entity and to associate that identity with a public key.

While communicating with any remote party, you need to be sure of the correspondent’s identity before dealing with the data integrity and confidentiality. In other words, forbidding the access to data and verifying that the data received has not been modified is meaningless if you are not  sure of the other party’s identity. Certificates help prevent the use of fake public keys for impersonation. Only the public key certified by the certificate will work with the corresponding private key possessed by the entity identified by the certificate.

A certificate, more precisely a X509 certificate as defined by ISO, is a data set that provides information about the owner and links them it to his public key. To ensure that this information is correct, the whole certificate is signed (data is hashed and the generated hash is ciphered using an asymmetric algorithm such as RSA) by a third party called the Certificate Authority (CA) which itself owns a public/private key pair. It uses its private key to create the certificate signature and makes its public key, which necessary to decrypt the signature, available to anyone through its own certificate.

Certificate standards overview

The following sections give an overview of certificate fields as defined by ISO in the X509 standard.

Users don't usually need to be concerned about the exact contents of a certificate. However, system administrators working with certificates should be familiar with the information listed below in this topic.

Distinguished names

An X.509 v3 certificate binds a Distinguished Name (DN) to a public key. A DN is a series of name-value pairs, such as uid=dupont, that uniquely identify an entity. In this case, it is called the certificate subject.

For example, this could be a typical DN for a Axway employee:

uid=dupont,,cn=Albert Dupont ,o=Axway Corp.,c=FR

The abbreviations before each equal sign in this example have the following meanings:

  • uid: User ID
  • e: Mail address
  • cn:The user's common name
  • o: Organization
  • c: Country

DNs may include a variety of other name/value pairs. They are used to identify both certificate subjects and entries in directories that support the Lightweight Directory Access Protocol, LDAP, the protocol generally used to access X.500 directories.

Certificate fields

Every certificate consists of two sections, the data section and the signature section as described below.

Certificate file description

Certificate field 



The version of the encoded certificate value for X509v3 is 2. 

Serial Number 

An integer assigned by the CA. The issuer name and serial number must identify a unique certificate. 

Issuer Signature Algorithm 

The signature algorithm identifier used by the CA to sign the certificate (e.g., RSA with SHA-1). 

Issuer Distinguished Name

The DN of the entity who has signed and issued the certificate. 

Validity Period 

The dates on which the certificate becomes valid and on which the certificate ceases to be valid.  

Subject Distinguished Name 

The entity associated with the public key stored in the subject's public key field. 

Subject Public Key Information 

The public key and identifier algorithm with which the key is used. 

Issuer Unique Identifier (optional) 

To prevent the reuse of issuer name over time, a unique identifier is assigned to the CA. 

Subject Unique Identifier (optional) 

To prevent the reuse of subject name over time, a unique identifier is assigned to the CA. 

Extensions (optional) 

Extensions are additional information about the certificate. Extensions consist of three fields: type, criticality, and value. Type field is the ASN.1type of the data (for example, text string, numerical, date). The criticality flag is either critical or non-critical. If PKI client application cannot process a critical extension, the certificate will be rejected. The actual value is the value associated with the extension. 

Signature description

The signature provides the following information:

  • The cryptographic algorithm or cipher used by the issuing CA to create its own digital signature
  • The CA's digital signature obtained by hashing all of the data in the certificate together and encrypting it with the CA's private key


This displays the data and signature sections of a certificate in human-readable format:

Version: v3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Axway Certificate Authority, O=Axway, C=US
Not Before: Fri Oct 17 18:36:25 1997
Not After: Sun Oct 17 18:36:25 1999
Subject: CN=Albert Dupont, OU=Marketing, O=Axway, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Public Exponent: 65537 (0x10001)
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL Client
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
Algorithm: PKCS #1 MD5 With RSA Encryption

Database protection

A database record corresponds to a certificate, regardless of whether it is from a root authority, an intermediate authority, or a user. In the case of a user, the record also includes the private key associated with the certificate's public key.

Records containing authority certificates, either root or intermediate, are in plain format and simply sealed. Sealing is used to detect fraudulent modifications, other than by the PKIUTIL utility.

Records containing user certificates are in plain format for the certificate and encrypted for the private key. They are also sealed.

Private key encryption is based on a password that must be passed as an argument in the PKICER command.

Complete CA certificate chains

In Transfer CFT 3.1.3 and lower, you can perform a SSL transfer even if the certificate chain is not complete (not signed by a ROOT CA). However, for Transfer CFT 3.2.0 and higher, the certificate chain must be complete for a transfer to succeed.

For more information, see Unknown CA leads to a failed certificate verification.

Related Links