An X.509 certificate is a vital safeguard against malicious network impersonators. Without x.509 server authentication, man-in-the-middle attacks can be initiated by malicious access points, compromised routers, etc.
X.509 is most used for SSL/TLS connections to ensure that the client (e.g., a web browser) is not fooled by a malicious impersonator pretending to be a known, trustworthy website.
However, X.509 certificates secure network communications of all kinds:
- Securing Internet communications
- Securing intranet communications
- Securing email communications
- Securing device communications
This article isn’t intended to offer a comprehensive overview of any X.509 standard or framework. Rather, this article aims to simplify the understanding of X.509 digital certificates, and how they are used to establish secure connections between a client and server during internet communications.
X.509 for Internet Communications
SSL/TLS Handshake
During SSL/TLS connections, the server authenticates according to the handshake and record protocols. When initiating the handshake protocol, the server presents a signed X.509 certificate to the client. Only the server needs to be validated in most secure browsing sessions. Client authentication is less common but would require the server to verify the client’s certificate as well.
The X.509 certificate’s signature must be verified by the client before establishing an HTTPS connection. The required format and information contained in an X.509 certificate enable the client to confidently authenticate and verify the integrity of the certified identity.
Trust Stores
Client browsers and applications rely heavily on their trust in Certificate Authorities(CA) for proper validation of X.509 certificates. Every client application and Operating System (OS) maintains a list of trusted Root CA Certificates, this list is called a “Trust Store.” For example, at the current time of writing, the Firefox trust store holds 150 root certificates that are automatically trusted by their web browser.
In contrast, Google Chrome uses the underlying OS’s trust store to determine whether a certificate is trusted, with a few exceptions. Google maintains a hard-coded list of “EV-Qualified” root certificates, along with a unique ID that must appear on certificates issued from that root. Note: Since 2015, Chrome requires all EV certificates to use Certificate Transparency.
Hierarchical Trust Chains
As part of the X.509 verification process, each certificate must be signed by the same issuer CA named in its certificate. The client must be able to follow a hierarchical path of certification that recursively links back to at least one root CA listed in the client’s trust store.
However, the certification path structure can be hierarchical (like a tree with a single source root CA) or non-hierarchical (like a forest with many cross-certified root CAs). It’s easier to understand cross certification by imagining international telephone calls. If each country code is represented by a root CA, then cross-certification agreements among the CA would extend the calling reach. When two roots CA sign each other’s certificates, they inherently trust all other certificates in each other’s paths.
Certificate Format
The issuer and subject of a certificate need to provide specific information for valid certification. The X.509 standard defines those requirements.
X.509 certificate fields:
- version: The version number of the x.509 certificate. (if omitted, version 1 is assumed)
- serialNumber: Unique serial number that is created for each certificate that is created by a CA.
- signature: The algorithm used to generate the signature. It must match the signatureAlgorithm.
- issuer: The distinguished name (DN) of the issuing CA.
- validity: Two dates of time—from notBefore (issued date) through notAfter (expiry date).
- subject: Distinguished name of the validated entity to which the certificate is issued.
- subjectPublicKeyInfo: The public-key algorithm and value (RSA, DSA, or Diffie-Hellman).
X.509 Version 3 extensions fields:
- extnId: This is used to identify this extension.
- critical: This is a boolean value that is used to inform if the extension is vital or not.
- extnValue: Contains an octet string that could be interpreted freely by a community utilizing an optional extension.
Note: Many extensions enabled by X.509 Version 3 are essential for business relationships within and across PKI domains.
X.509 Certificate Encoding
X.509 does not define how certificate contents should be encoded to store in files. However, two commonly used encoding schemas are used to store X.509 certificates in files, DER and PEM.
DER (Distinguished Encoding Rules) is a data object encoding schema that can be used to encode certificate objects. DER is the most popular file format to store X.509 certificates. DER-encoded certificates are binary files and cannot be read by text editors, but they can be processed by web browsers and some applications without any problems.
PEM (Privacy Enhanced Mail) is an encrypted email encoding schema that can be used to convert DER-encoded certificates into text files.
X.509 Version History
In 1988, X.509 version 1 was published. The hierarchical arrangement of the distinguished names followed the rules for X.500. These rules were inspired by the systems used to assign telephone numbers globally.
In 1993, X509 version 2 added two new fields: Issuer Unique Identifier and Subject Unique Identifier. These fields are now considered deprecated by the IETF, and should not be used in your certificates. The widespread use of the Internet inspired further development of the hierarchical naming system.
Since 1996, Version 3 of X.509 enables multiple extensions that can be added to a certificate. The extensions provide enhanced information about key usage, certificate policies and constraints, alternative name forms, and more.
Next Steps
As mentioned by Gartner, X.509 certificates are critical to establish digital trust in the digital world. Without proper management of these certificates, security teams leave their company open to outages, breaches, and failed audits.
Take an inventory of your current X.509 certificate management capabilities and evaluate if a new solution is required to address the continuous increase of your digital certificates.
