Status: Final Published

Date: May 2008, more revisions and alterations implemented

Region: United States

Document: Link


The X.509 standard defines the format of public key certificates for the public key infrastructure (PKI) used, including for the Transport Layer Secure (TLS)/Secure Sockets Layer (SSL), which secure the majority of the HTTPS. Over its lifetime, the x.509 and its alternative models were developed through the collaboration of multiple entities, including the ITU, the Network Working Group (NWG), and the Internet Engineering Task Force (IETF), and has undergone further examination by organizations like the NIST, key technology vendors like Microsoft and Entrust Datacard, and CAs like GlobalSign. The current version is x.509 V3 and has been further enhanced by ISO/IEC, ITU-T, and ANSI X9.


Brief introduction to PKI: Different entities make use of PKI to securely encrypt, decrypt, and authenticate the identity of messages from other parties, thus increasing confidence in the value chain that the entity sending a message “is who they claim to be.”

The x.509 in PKI: Successfully deploying a digital certificate is the most critical function outlined in x.509 and the standard mentions the programming parameters required to achieve that task. x.509 certificates enable parties to securely authenticate the entities (and their subsequent services) that hold a private encryption key, thus allowing the exchange of information.
External third-party CAs serve the vital function of overseeing and expediting this process on top of distributing digital certificates. While online servers, gateway/router applications, web-browsers, and related Internet-based activity (e.g., emails, enterprise services, government websites, etc.) are the primary targets for the x.509 and digital certificates, their reach extends to the greater IoT landscape, including connected car OTA services, user accounts, infotainment systems, and any application that may require a secure IP-based authentication.

Examining the Information Stored in Digital Certificates: Digital certificates allow PKI to function properly, so the x.509 standard specifies a number of crucial functions for digital certificates that must be implemented at all times. This is the second most important function outlined in the x.509 standard. Depending on the target application, digital certificates compliant with the x.509 are required to hold information about every device, user, or entity they are attributed to and are used to protect both things and the data originating from them. They also include validation and expiration date of the certificate, ID, serial number, name of official holder of the certificate, and a trusted copy of the originating party’s public key. Other information can include extensions related to certificate name or constraints, authority identifiers, alternative name of the issuer of said certificate, and other related policy parameters.
x.509 Function Parameters: To provide more concrete examples, the aforementioned parameters outlined in the x509 allow the following functions to take place:

  • They define the key policies and objectives, and target applications for that certificate, as well as different names that might be held by legitimate parties.
  • They allow one or more service URLs to access and make use of the very same digital certificate, this functionality is added in less critical applications and can be added as an additional cost-effective or efficiency option.
  • They decide whether an application can or should be used with that certificate in more vital applications. For example, a certificate aimed at automotive infotainment systems should
    not tackle critical automotive safety components. If needed, however, for efficiency purposes, certificates aimed at driver/passenger in-cabin personalization or entertainment systems could be merged (i.e., shared) with other less important applications.
  • They set certain security policy constraints, such as blocking other entities to act as if they were a CA themselves. This additional security option was made available in V3 of the x.509. Leading CAs like DigiCert have outlined that some online clients might still maintain this vulnerability and, therefore, allow cyberattackers to access connected car systems and impersonate a CA.

After all parameters have been set and CAs can successfully provision and manage digital certificates, that public encryption key is what allows for the successful encryption/decryption of all incoming and outgoing information between users, entities, devices, and services.
The third most important function for digital certificates is the ability to set an expiration date and actually revoke them. Many IoT-focused organizations are usually “cutting corners” when it comes to the management and revocation of certificates. Additionally, some companies may have difficulty (or may ignore) managing the encryption keys used in PKI and successfully managing their lifecycle. Some have even been found sharing encryption keys, but not engaging in rotation of these keys that are tied to services or devices.


The majority of vendors believe that the task to develop, scrutinize, and further evolve PKI cryptographic standards falls primarily on the CAs. However, key IoT vendors (including the companies that helped develop the x.509) believe that it falls to the companies themselves to study, adapt, and potentially even rework such cryptographic standards. This means that further examination is quite likely to first emerge from key tech companies before it eventually finds its way to the standardization papers of leading industry entities.

Subscribe to our blog

Recent Posts
ee architectureprinciples