Guide to modern PKI: Typical setup and basic terms

Let’s look into something more specific. What are the typical components of a modern PKI? What is the typical setup and how to understand the basic terms? Considerations for building the modern and future-proof PKI should give us guidance on what components we need to implement.

When engaging customers with building or upgrading the PKI, usually the first steps begin with the design and architecture of the solution. A good design in the beginning can help you save money and time during implementation, so it is something that should not be overlooked. You should spend more time designing the correct solution rather than redesigning multiple times during the project.

For this reason, it’s important to understand that the building blocks of modern and future-proof PKI.

Trust services lifecycle management

Certificate management with its traditional functions like issuing, renewing, and revoking the certificate is becoming only one integral part of the trust services. Without focusing on the services, we would not be able to effectively manage millions of digital assets spread across hybrid environment.

Trust services have a much broader meaning:

  • digital certificates lifecycle management – we want to be able to issue, renew, revoke, deploy, decommission, automate, notify, report, and much more about various types of digital certificates
  • cryptographic keys lifecycle management – we want to manage symmetric and asymmetric keys that are part of the services, including generation, distribution, storage, renewal, decommission, destroying
  • digital signatures lifecycle management – we want to use digital signature to secure data, supply chain, and many more, therefore we want to be able to manage the state of the digital signature service in time
  • other services lifecycle management – there are many trust services build on top of the basic building blocks mentioned above

Management of the lifecycle for the trust service should be our primary goal, independently on what technology we are going to use and implement. 

Logical architecture

The following diagram represents a typical logical architecture of the modern and future-proof PKI. In the next chapters, we are going to describe each of the components.

Entities relying on trust service

Presentation

Supporting systems

Interfaces and integration

Supporting functions

Trust service lifecycle management

Public key infrastructure core components

Cryptographic keys and secure storage

Building the solution can be simple or complex, depending on the design and the technology used. The core logic is behind the management and lifecycle automation of trust services, allowing you to have a full control and visibility on your certificates and cryptographic keys. However, to build a complete service, other components are needed as well:

Entities relying on trust service

The entity is someone or something that is using one of the trust services. This is basically the end user of the service, for example administrators, operators, partners, customers, servers, clients, databases, and other parts of our infrastructure and business procedures.

Presentation

A presentation layer is what the user sees and how they interact with the trust service. From the end user perspective, this may be represented as a graphical user interface, form, or any similar way of interpreting the trust service.

Interfaces and integration

Trust service can have different options for technical integration. These can be used to create various front ends (see presentation above) and provide options to users in any application they use in day to day task, including the automation. The typical implementation consists of:

  • REST APIs (or some variant of HTTP interface)
  • SOAP Web Services
  • proprietary protocols
  • software development kits

Supporting systems

The modern and future-proof PKI consists of several components. Each of them provides a different function in the ecosystem. The role of supporting systems is to provide necessary assurance when using the solution.

Some typical supporting systems are:

  • identity provider – identifies users, securely stores identities and provides identity verification (authentication) of the users
  • authorization solution – defines roles and permission for identified users, provided authorization proof of the users requesting trust service

Supporting functions

None of the solution would be nowadays complete without the supporting functions. These functions give us necessary management information for our decision making and control.

A typical supporting functions are:

  • discovery – searching and identifying digital assets in the infrastructure
  • monitoring – control about the validity and expiration of digital assets in time
  • reporting – short (and in some cases long) and precise overall information about the current trust services and its state
  • compliance – checking the compliance status against regulations and standards

Trust service lifecycle management

The trust service lifecycle management system or solution is usually the brain that contains complete logic about how the trust service should behave. This part is defining, managing, and interconnecting various service to build the trust service.

It controls the process, communicates with different components in the solution and mediates information between them. It acts as an umbrella for the components in the logical architecture and provides:

  • flexibility – focusing on the services
  • effectivity – control on multiple assets instead of focusing on one individual
  • control – automatic application of policies
  • automation – reduce day-to-day manual operations
  • agility – instant propagation of changes
  • visibility – monitoring and reporting the portfolio of assets

Public key infrastructure core components

The public key infrastructure contains traditional components:

  • certification authority – provides certificate management functions to issue, renew, and revoke certificates
  • registration authority – provides identification and enrolment of entities in the public key infrastructure and typically can control the lifecycle of the certificate
  • validation authority – provides validation of certificates and typically contains database of certificates, revocation lists, or OCSP (Online Certificate Status Protocol, see RFC 6960) service

Not all components are necessary. For example, if you do not need to implement OCSP for certificate validation, you probably do not need to have a validation authority.

Cryptographic keys and secure storage

We need to protect all cryptographic keys and other sensitive digital assets that are used in the solution. That’s why there should be a Hardware Security Module. HSMs

For other non-sensitive data, we need a database. Data in the database should be integrity protected.

Keep in mind that the database can contain the cryptographic keys as well as data encrypted using them. If mis-configured, a security loophole can be created with a risk of potential data breach.

Get more information about the CZERTAINLY

CZERTAINLY is an open-source platform for effective and efficient certificate lifecycle management for companies of any size and individuals. One of its goals is to provide an easy and affordable way to secure digital communication and support information security in more and more connected world.

Need Help

Do not hesitate to get in touch with us!