x509 Certificate – Asymmetric encryption and Digital Signatures

The X.509 specification defines a standard for managing public keys through a Public Key Infrastructure (PKI). Public keys are maintained in X.509 certificates, which are digital documents that bind a subject’s identity claims to a public key from a public/private asymmetric key pair. Identity claims are usually understandable by humans, such as a person’s full name or e-mail address, or a machine host name or domain name. X.509 certificates are endorsed and issued by a trusted third party, which is known as a certificate authority (CA).

Asymmetric (Public Key) Encryption and Digital Signatures

Public key encryption, also known as asymmetric encryption, is based on a public/private key pair. The keys are mathematically linked, so that data encrypted with the public key can only be decrypted with the corresponding private key. X509 certificates use asymmetric encryption as an alternative to shared symmetric keys.

With public key encryption, the sender converts the plain text message into cipher text by encrypting it with the public key in the message recipient’s X.509 certificate. The message recipient converts the cipher text back into the plain text message by decrypting it with the corresponding private key.


By using public key encryption, a message sender has assurance that only the recipient will be able to read the message.

In addition to providing data confidentiality through encryption, you can use the public key in the X.509 certificate to verify digital signatures created by a message sender. A digital signature is a value produced by the message sender to bind message data to the sender’s identity and to provide a means of verifying the integrity of the message to detect tampering. In this case, the private key of the message sender is used to create the digital signature. The corresponding public key, which is found in the sender’s X.509 certificate, is used to verify the signature. Digital signatures are used to assure the message recipient that the message originated from the identified sender, and that the message contents have not been altered since they were signed by the sender.

Note   With digital signatures that use public key cryptography, the origin of the signed message can be traced to the sender’s identity, thereby satisfying nonrepudiation requirements. This differs from symmetric key integrity, where a message may have been signed by either party with knowledge of the shared secret key.

The public key can be distributed openly to encrypt messages and to verify digital signatures, but the private key in a key pair should be carefully guarded by its owner. This is necessary because it is used to prove the identity of the certificate subject and to decrypt messages that are intended for that subject.


X.509 Certificates

X.509 certificates contain several required and optional attributes that enable the identification of the subject. You can obtain the following list of attributes in an X.509 certificate:

  • Version number: The certificate version.

    Note   Different versions (version 1, 2, and 3) of X.509 certificates have evolved over time, to provide additional security and attributes that are bound to the certificate. In practice, only version 3 certificates should now be used.

  • Serial number: A unique identifier for the certificate.
  • Signature algorithm ID: The algorithm used to create the digital signature.
  • Issuer name: The name of the certificate issuer.
  • Validity period: The period during which the certificate is valid. (This is typically set to be approximately one year.)
  • Subject name: The name of the subject represented by the certificate. (The subject of a certificate is typically a person, an organization, or a Web/application server.)
  • Subject public key information: The public key algorithm.
  • Issuer unique identifier: The identifier for the issuer.
  • Subject unique identifier: The identifier for the subject.
  • Extensions: Extensions that can be used to store additional information. such as KeyUsage or AlternativeNames.
  • Signed hash of the certificate data: The hash of the preceding fields encrypted using the issuer’s private key, which results in a digital signature.

Implementations of X.509

Security using X.509 certificates can be implemented at different layers of the network or application infrastructure, and each implementation had its own advantages and disadvantages.

Secure Sockets Layer (SSL)

SSL is a secure handshake protocol that supports X.509 certificates at the transport layer. It enables two parties to establish a session to communicate securely by providing confidentiality and data integrity. data origin authentication can also be provided if both parties use X.509 certificates. This is commonly referred to as SSL with client certificates. Some of the benefits of using SSL are:

  • SSL is a well established protocol that is broadly interoperable, and is easy to configure and use.
  • SSL has a performance advantage over message layer security because it is closer to the operating system than the message layer.

While SSL has some strong benefits, it does have the following liabilities:

  • SSL operates point-to-point, which means that messages cannot be persisted in a secure state. It also means that SSL-encrypted SOAP messages cannot be processed by intermediaries without first being decrypted.
  • If you use SSL in conjunction with WSE 2.0 or WSE 3.0 to provide data confidentiality and integrity at the transport layer, WSE cannot verify that SSL is being used to protect messages at the transport layer. Conversely, SSL cannot verify that clients are satisfying policy requirements defined in WSE, which is a requirement for client authentication.

WS-Security X.509 Binary Security Token

At the message layer, you can use X.509 certificates as binary security tokens in accordance with the WS-Security specification to sign and encrypt messages and to provide data confidentiality and data origin authentication.

The benefits of using X.509 at the message layer with binary security tokens include:

  • Message layer security that uses X.509 certificates is flexible enough to provide point-to-point or end-to-end security. This allows messages to be persisted in a secure state for short periods for queue-based processing or for longer periods in an archived state.
  • Message layer X.509 provides a high degree of interoperability. It provides standards based on the messages as they are sent over the wire instead of focusing on implementation for a particular platform.

Message layer security also has the following liabilities:

  • Processing message layer security with X.509 certificates tends to have a greater impact on system performance than implementations that are lower in the protocol stack. This is because the message layer is further away from the hardware layer.
  • Message layer security that uses X.509 certificates provides a great deal of flexibility, but it tends to be more complex to implement than security that uses X.509 certificates at other layers. This requires more knowledge of the underlying protocols, security policy, and programming against a Web services security API.

Certificate Authorities

Certificate authorities (CAs) are organizations that issue signed X.509 certificates. CAs can be internal or external to an organization. They can issue different types of certificates that are for a specific purpose or confer varying levels of trust. External CAs are typically commercial entities that provide certificate issuance to customers for a fee. Examples of external CAs include Thawte, VeriSign, and RSA.

CAs offer different “grades” of signed certificates for purchase. Some have a nominal fee and come with minimal requirements to prove the subject’s identity. For example, a certificate that is used to sign e-mail messages may only cost a few dollars and require only e-mail confirmation to prove that the e-mail address represented by the subject in the certificate is authentic. A certificate that is used for more trusted activities may cost upwards of a hundred dollars and require a far more rigorous screening process to ensure that the subject meets the requirements for the certificate.

Internal CAs, such as Certificate Services in Windows Server, can simplify certificate management activities, but in this case the trust of the certificate is now based on the organization that issued it. Certificates that are issued for subjects within the organization’s security domain (usually defined in Active Directory) are typically signed with the organization’s root certificate or another “parent certificate” that is allowed to sign certificates.

The chain of certificates, from the subject’s certificate to the root certificate that is used by the CA for signing subject’s certificate, is known as a trust chain. A party may decide to trust certificates at any level within the trust chain. This allows them to trust certificates further down the chain, as long as they are able to trace the trust chain back to the level of the certificate they original trusted.

Note   In test environments, you may choose to use certificates that do not have rigorous requirements for proving the identity of the subject. Certificates can be generated and self-signed with the MakeCert utility. However, there are known performance issues when verifying digital signatures with certificates that are generated by the MakeCert utility.

Obtaining an X.509 Certificate

Depending on the type of CA, X.509 certificates can be obtained in a variety of ways. For external CAs, certificates are typically obtained for a subject by submitting a certificate signing request (CSR). A CSR contains the subject’s name, the public key, and the algorithm that is used. (The majority of X.509 certificates you are likely to encounter use RSA for its algorithm).

The public key included in the CSR comes from a public/private key pair, which is generated specifically for use with the requested certificate. As soon as the public/private key pair is generated, the private key should be immediately stored in a secure place, such as a machine key store. Access to the key should be solely restricted to authorized parties. Ideally, the only party able to access the private key file is the subject that is represented in the X.509 certificate, although some infrastructures may allow access to the certificate private key by other accounts. When parties other than the subject represented by the X.509 certificate are allowed to access the certificate private key, the ability to support nonrepudiation may not be possible. The public key of the public/private key pair is required for the CSR, but the private key should never be sent to the CA under any circumstances.

Internal CAs may also use CSRs to process X.509 certificate requests. However, because the CA is internal to a specific organization, there can be additional options that reduce the overhead that is required to process requests and verify subject identities. For example, an internal CA that uses Windows Certificate Server may enable auto enrollment, which automates certificate request and issuance for user accounts that are created within an Active Directory domain.


Certificate Revocation

The issuing CA can revoke X.509 certificates if the integrity of the certificate has somehow been compromised. The justification to revoke an issued certificate varies with each CA, but some general causes for certificate revocation include the following:

  • The private key has been stolen or wrongly disclosed due to improper storage or use. For example, when the subject’s private key is attached to an outgoing message instead of its X.509 certificate that contains the public key.
  • The subject represented in the X.509 certificate has breached the trust of the CA that issued the certificate. For example, if information about the subject was intentionally misrepresented to the CA during the process of verifying the subject’s identity.
  • An identity that corresponds to a certificate has been removed from an organization that manages an Internal CA. For example, a user account is removed from the system or is disabled when the user’s employment is terminated.
  • A subject no longer requires the certificate (cessation of operation). A CA may revoke a certificate if the certificate is no longer required and will not be used by the subject any more.

X.509 CAs typically publish a list of certificates that have been revoked, based on the CA’s criteria for certificate revocation. These lists are known as certificate revocation lists (CRLs). CRLs are made publicly available so that a recipient can verify whether a certificate that was used to sign a message is valid. Any message recipient that receives a signed message should verify that the subject’s certificate has not been revoked. This ensures the integrity of the signatures, based on the expected level of trust associated with the type of certificate.

Certificate Storage and Access

X.509 certificates can be stored and accessed in a number of ways, including:

  • Local repository. X.509 certificates may be exchanged out-of-band and stored in a locally accessible repository, such as the machine certificate store in the Windows operating system. You should only use a local repository if a small number of certificates are required for use by an online application.
  • PKI server. Public Key Infrastructure (PKI) is a platform that allows an organization to centrally manage X.509 certificates that are required by the organization’s services and subjects to authenticate and verify digital signatures. Certificates for that organization’s subjects may also be made accessible outside of the organization. An example of a PKI solution is Certificate Services, which is included in Windows Server 2003.
  • Direct presentation. X.509 certificates may be presented to a message recipient by attaching the certificate directly to the message. The recipient may subsequently decide to cache the certificate locally, pass it off to a central repository for storage, or simply reprocess it when it is attached to a new message.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s