Guide to modern PKI: Technology and deployment options

In the previous parts of this series, we were focusing on what are important aspects to build the modern and future-proof PKI. We were not discussing any technology, because the PKI should be technology-agnostic. You would like to avoid any vendor lock and to be able to quickly react on development and changes.

There are many different technologies out there, and the right choice should be made based on the results from the proper scoping and gap analysis.

We are going to demonstrate the solution based on the technologies of our choice that we believe can support and cover majority of the service and use-cases you someone might be looking for.

Few words about technology

Technology is important, you should choose it wisely. But on the other hand, you do not want to be dependent on the technology and create a vendor lock. In today’s world, you should count with several technologies that should be part of the PKI and take it into consideration.

Entities

You have web servers like IIS, Apache, application servers like Wildfly, Websphere, firewalls and load balancers like F5, Baracuda, transparent proxies like nginx, HAProxy, database like MS SQL, Oracle, PostgreSQL and many more. This is just a few examples of where you should expect to use digital assets.

Certification authority

Although you want to have one consistent CA technology for issuing your certificates, the reality is that you need to support hybrid environment with different level of trust. For that reason you might need public CA such as DigiCert or GlobalSign, you internal CA such as MS ADCS or EJBCA, and purpose build CAs for example for transparent proxy, Kubernetes, or cloud.

HSM, database, and many more

There is a wide range of HSM vendors you can choose from. If you are building your internal CA, keep in mind that the private keys for your CA have longer lifecycle than the HSM model. Prepare your key management procedures and ask HSM vendor if the keys are transferrable or not. You might have a local regulation or standard enforcing you to work with the data in some specific way.

There are technologies for database, infrastructure management, credentials and secrets management, identity and access management, etc. Carefully consider each of them.

Deployment options

Depending on the technology, you can decide how you would like to deploy the solution. The decision is typically based on the available resource and skills to manage such solution in time.

You can simply subscribe to trust service and consume as it as you go or grow, or you can spin-up the solution in your infrastructure and support your internal business processes and services. The choice is up to you.

I do not care, I just want to have it running

In this situation, the best possible solution would be to subscribe to trust services lifecycle management as a service that includes all required components to start consuming trust services. Use the solution in a couple of minutes.

I want a simple solution under my control

Deploy the solution in your own infrastructure (on-premises, cloud, or hybrid) using existing installation and configuration options that do not require extensive skills and experience. Deploy and provide trust service in a couple of minutes or hours.

I want to know details about the solution

Take a look into how components of the PKI solution work and interact between. Tweak components configuration parameters and understand the best way how to deploy the complete solution within the boundaries of your infrastructure in days or maybe weeks.

Let's dig in to the source code and technology

When you are interested in how the technology works, you can look into the source code, if available. You can try to build the solution from the source code and even add or change some parts to your needs and specific requirements. You should count with the learning curve in weeks or months.

Our technology stack and deployment

We are going to set up the system that will be based on the open-source components and will be deployed in the containers. For the underlying infrastructure will be using Kubernetes and we will describe the approach to “spin it up” so you can start working with the solution in a matter of minutes.

Ingredients we are going to use are:

  • The infrastructure – for simplicity, we will use Kubernetes and Helm to install the required software in the infrastructure and configure service
  • The database – for storage of the data the certification authority and platform, we are going to use Postgres database.
  • The certification authority – any certification authority can be connected, for our purposes, we are going to use open source EJBCA
  • The trust management platform – there is only one choice for the open-source trust management platform, which is of course CZERTAINLY

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!