Issuing TLS Certificates

Issuing TLS certificates is a common use case including both public providers of TLS certificates and enterprise PKIs needing to provision TLS server certificates internally. In this solution, you strive for short-lived certificates and as much automation as possible and have high requirements on OCSP and CRL generation.

Since this public key infrastructure (PKI) is going to be exposed to the internet, domain security is of dire importance. EJBCA allows outward-facing nodes (Registration Authorities (RAs) and Validation Authorities (VAs)) to not only be connected to the certificate authority (CA) through mutual TLS but also with the CA behind a one-way firewall. Multitenancy support allows all your sub-organizations and divisions to share the same PKI infrastructure with extensive domain security in place to ensure that security silos are kept intact. For more information on how to set all this up with EJBCA, see Issuing TLS Certificates.

Securing Your Microsoft Environment with EJBCA

The Microsoft platform is one of the most prominent Enterprise environments globally, serving both servers and workstations. But while the Microsoft ecosystem is truly as mature as it is ubiquitous, Microsoft's own PKI, Microsoft Active Directory Certificate Services (AD CS), does not always grow in scale with your solution. You can solve that by leveraging EJBCA as the PKI backend instead of the Microsoft Certificate Authority (CA). Not only do you gain the power of one of the worlds best PKI tools in your environment, but you can save both cost and work by having a single EJBCA instance handle the entire PKI of your organization across all forests, domains, and trees, instead of having to maintain a separate Microsoft CA per domain.

With EJBCA's Auto-enrollment functionality your clients' user experience does not change, while your administrators will be overjoyed. Employing EJBCA as the CA backend for your Microsoft environment eliminates the need for a Microsoft CA and Microsoft Certificate Services. To learn how EJBCA integrates into your infrastructure via Microsoft Auto-enrollment and support for Intune and HSMs, see Securing Your Microsoft Environment with EJBCA.

IoT and Device Identities

Whether you're producing radio base stations (eNodeBs) or security gateways for telecom solutions, the latest Internet of things (IoT) devices, or connected cars - if your device communicates via the internet and especially if it is produced by an outside supplier, you are going to want to use PKI to secure communications, ensure the identity of your devices and make sure that only your devices can connect to your network. Your issuance is likely going to be completely automated and fortunately, EJBCA provides support for nearly all enrollment protocols. To find out which setup fits your needs the best, see IoT and Device Identities.

Go Big! Using EJBCA as a Large-scale Enterprise PKI

Are your certificates counted not by thousands but by the millions? EJBCA is built for scale. Through some tweaks and configurations, EJBCA's issuance and OCSP response volumes can handle PKI on a global scale. If your PKI requires world-class performance, then EJBCA is your choice.

If your problem is scale and your current PKI solution is not be able to handle the volumes and throughput of your needs, see Using EJBCA as a Large-scale Enterprise PKI to find out how EJBCA can be tuned to handle even the world's biggest PKIs.

Issuing eID Certificates and Signing ePassports

PrimeKey has over 20 years of experience in issuing certificates for tokens and cards for both X509 and Card Verifiable Certificates (CVC), and EJBCA PKI together with PrimeKey's SignServer form the technology base of many passport authorities worldwide.

EJBCA implements several PKI services that can be included in an ePassport PKI solution, such as Country Signing Certificate Authority (CSCA), Card Verifiable Certificate (CVC) CA, and Document Verifier CA (DVCA). To find out more and how to set these up, see Issuing eID Certificates and Signing ePassports.

PKI and Signature Services for Microservices and DevOps Environments

Microservices as an architectural approach to software development are based on building an application as a collection of small services, typically orchestrated by an automated system. Adoption of microservices is related to the use of DevOps, continuous integration and continuous delivery (CI/CD), and containers.

One aspect of microservices is deploying and managing large numbers of services. These lightweight servers create the need to automate the configuration of servers and applications, including the security keys and credentials needed. It is not only about running the PKI products in a DevOps environment but also about managing (non-PKI) applications in a DevOps environment securely, providing applications with certificates, digital signatures, and credentials as services are created and destroyed. To find out more, see PKI and Signature Services for Microservices and DevOps Environments.

Deploying PKI and Signature Services in DevOps Environments

When deploying a PKI, whether it is a single centralized PKI, multiple distributed PKIs, or perhaps short-lived PKIs for specific purposes, it is suitable to do so using the same tools and processes used for the rest of your environment. Two common tools used are Ansible and Kubernetes, and EJBCA plays well with both.

To learn more about how to deploy your PKI as VMs or containers and use Ansible to automate PKI deployment and configuration, see Deploying PKI and Signature Services in DevOps Environments.

Hybrid PKI Deployments for Modern Manufacturers

The demand for PKI consolidation is apparent when seeking PKI governance in a multi-PKI environment. But as the necessity for PKI services expands over new use cases and compliance and availability requirements, there will always be a need for PKI silos. Thus, you need to standardize and streamline policy and operations across multiple silos to regain governance and minimize maintenance and risks.

To maintain central PKI governance and uphold control and security policy across the whole organization, it is key to consolidate PKIs and HSM usage when possible and automate the installation and configuration of PKI deployments. To find out more about how a flexible implementation of PKI can support both silos and centralized models or deployments, see Hybrid PKI Deployments for Modern Manufacturers.

Post-Quantum Readiness

For Public Key Infrastructure (PKI), the eventual arrival of quantum computers is going to mean that most of the algorithms we currently rely on are no longer secure. The National Institute of Standards and Technology (NIST) states that: the goal of post-quantum cryptography is to develop cryptographic systems that are secure against both quantum and classical computers and can interoperate with existing communications protocols and networks.

The question of when a large-scale quantum computer will be built is a complicated one. At the moment, estimates put the arrival of "meaningful" (at least in this sense) quantum computers at around 2030 or soon after. The primary thing taking place right now is the NIST Post-Quantum Competition, which is coming to the end of its "final" stage, and NIST has stated that the new standards will be released in 2024.

As the time to roll out new Post-Quantum Cryptography (PQC) algorithms gets closer, it is wise to establish a high level of crypto agility in your organization. You can start preparing by being crypto agile and trying out the new algorithms. To learn more about what you need to do and how Keyfactor can help , see Post-Quantum Readiness.

PKI for 3GPP

Using the Certificate Management Protocol (CMP) together with the 3rd Generation Partnership Project (3GPP) technical specification allows an eNodeB (base station in 4G and 5G networks) to automatically provision itself with an operator certificate from the Mobile Network Operator (MNO) without the eNodeB manufacturer and the MNO sharing PKIs.

This is accomplished by the eNodeB using a vendor-issued certificate from the manufacturer's PKI, to authenticate to the MNO upon installation, authorizing the issuance of an operator certificate from the MNOs PKI. The operator certificate is then used to connect the eNodeB to the MNOs network. To learn more about the 3GPP CMP profile and enrollment using certificates through CMP with 3GPP, see PKI for 3GPP.