![BSS logo [Converted].png](https://static.wixstatic.com/media/15e830_03ad02647a44460db48ad34179ee2f0e~mv2_d_2135_2022_s_2.png/v1/fill/w_91,h_83,al_c,q_85,usm_0.66_1.00_0.01,enc_auto/BSS%20logo%20%5BConverted%5D.png)
WorkCE CA Solution
Overview
PKI Infosec’s CA solution enables Trusted Third Parties to enroll users/devices and issue X.509 V3 certificates, as well as manage certificate revocation and validation activities efficiently.
The PKI infrastructure may also require the following components, as per the security policies and the law of the land:
Hardware Security Modules (HSM) – HSMs provide the highest form of security for protecting private keys. PKI Infosec’s products uses HSMs for signing keys used by the CA.
The Certifying Authority server forms the core of any secure PKI framework. The primary function of a CA is issuing and managing digital certificates, including revocation, renewal, suspension and re-activation of certificates.
WORKCE is a powerful, fully standards compliant and scalable certification authority server with support for commercial strength RSA keys and ECC keys. Certificates generated by Workce comply with X.509 V3 Standards. The server is fully policy driven and would enable a CA to enforce certificate policy statements easily and effectively
Components
Certification Authority (CA)
A certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party, trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 standard.
Multiple RA can connect to a single CA instance using Secure REST API.
RootCA
A RootCA has a self-signed certificate and is also called Trusted Root. Verification of other certificates in the PKI ends with the RootCAs self-signed certificate. Since the RootCAs certificate is self-signed it must somehow be configured as a trusted root for all clients in the PKI.
SubCA
A subordinate CA, or SubCA for short, is a CA whose certificate is signed by another CA, that can be another SubCA or a RootCA. Since the SubCAs certificate is signed by another CA, it does not have to be configured as a trusted root. It is part of a certificate chain that ends in the RootCA.
Registration Authority (RA)
A Registration Authority (RA) is an administrative function that registers entities in the PKI. The RA is trusted to identify and authenticate entities according to the CAs policy. There can be one or more RAs connected to each CA in the PKI. Multiple end-Entity clients can connect to RA using Secure REST API to perform following actions:
-
Certificate Enrolment
-
Using CSR
-
Using new keypair generated by CA Server
-
-
Certificate Search & Download
-
Certificate Revocation Request
Validation Authority (VA)
A Validation Authority (VA) is responsible for providing information on whether a certificate is currently valid or not. The VA does not issue or revoke certificates, but it validates certificates by providing a list of revoked certificates for a CA, known as a Certificate Revocation List (CRL). Another method that the VA can support is the Online Certificate Status Protocol (OCSP). It is a real-time lookup of a certificate status, compared to the CRL which is generated on a set schedule. The VA can respond to OCSP requests and reply if a certificate is good, revoked, or unknown. There can be one or more VAs connected to each CA in the PKI.
End Entitity
An End Entity is a user of the PKI, like a device, person or a server. It is called the End Entity because in a hierarchy of certificates in the PKI, it is always the end point, since it is not authorized to issue any certificates of its own. The End Entity individual or device can request a certificate from the RA by consuming REST API provided by RA.
Certificate Profiles
A Certificate Profile is used to configure certain content and constraints of certificates, such as certificate extensions.
The certificate extensions allows you to define if a specific extension is present and whether it is critical or not. Some extensions are populated with a value, where it is the same value for all certificates such as CRLDistributionPoint. For other extensions only the presence is determined, where the value is user- or cert-specific such as SubjectAlternativeName. Here is also determined if these certificates will be published and with which publisher.
End Entitity Profiles
The End Entity Profile defines what information can be in the certificate, for example, country and organization. The Certificate Profile (as a constraints template) and End Entity Profile (as a certificate content template) and used together to create the certificates signed by the CA.
End Entity Profiles determine what data can or must be present for users connected with the profile. Some values can also be pre-determined such as the organization (o in the Distinguished Name (DN)). The End Entity Profile contains all information, that is specific to each individual End Entity, for issuance of certificates. When adding a user in the PKI, the user must be connected with an End Entity Profile. The End Entity Profile specifies one or more certificate profiles used when generating certificates.
Crypto Tokens
WORKCE stores cryptographic keys in a Crypto Token. A Crypto Token can either be stored in a database, known as a Soft KeyStore, or on a Hardware Security Module (HSM).
A Crypto Token is the token used by a CA to store its keys. The Crypto Token's most important key are the CA signature keys. The Crypto Token can also contain other keys used for encryption of sensitive data in the database. A Crypto Token can be configured per CA or multiple CAs can share a Crypto Token. The different forms that are stored in the database are:
-
Soft token PKCS#12 files protected by a password.
-
Hardware token configuration, usually referencing a Hardware Security Module (HSM) accessed using the PKCS#11 API.
Publishers
A publisher stores issued certificates to a central location. WORKCE can publish to LDAP and Active Directory.
WORKCE Architecture
There are multiple ways that you can implement and architect a PKI solution, ranging from simple and low cost, to very complex and costly. WORKCE allows implementing virtually any type of PKI architecture and the following sections describe a selection of common PKI architectures deployed:
PKI Architecture
SingleCA/RA
You can deploy a complete PKI in a single instance. Since WORKCE has everything built in you can have a single instance functioning as both CA and RA. This is a very efficient, easy to manage, and cost-effective solution that is suitable for many SME enterprise deployments.
Multiple CAs for different use-cases can co-exist in a single instance and security levels can be scaled with, for example:
-
Administrators can use smart cards or soft tokens for accessing administration interface.
-
The CA can use an HSM or soft tokens for the CA signing keys.
-
Users and machines can be issued with soft tokens or smart cards/USB tokens.
-
Various filtering options can be deployed in firewalls.
CA with Distributed Ras
To set up a PKI capable of enrolling a diverse set of users and devices, it is usually necessary introduce multiple types of RAs, for different purposes. Using WORKCE you can connect an unlimited number of distributed RAs, communicating with the CA using Web Service.
Multiple CAs can be easily configured to serve different purposes.
Offline Root CA and Multiple Sub Cas
A common model within PKI is to use a secured, off-line, Root CA with subordinate, on-line, issuing CAs. Using WORKCE you can easily deploy such an architecture with multiple Root CAs and issuing SubCAs.
All discussed enrolment methods and interfaces are available to the issuing CAs.
Multi-level PKI Architecture
You can extend the architecture with as many levels of Sub CAs as you like, creating 3 or 4 tier architectures.
Validation Authority
WORKCE has built in Validation Authority (VA), meaning that the Single CA/RA setup comes with complete certificate validation capabilities. When setting up a larger PKI however you typically want to separate the validation authority from the certificate authority. Using a separate Validation Authority you can serve multiple PKIs from a single VA. You can publish revocation information in real time, also called white listing, or using CRLs for periodical revocation updates.
Primary and Disaster Recovery Site
In mission critical PKIs it is also common to set up the system with a primary site and a disaster recovery (DR) site. During normal operations traffic is directed to the primary site, which contains a clustered configuration as in the previous picture. All data is replicated to a disaster recovery site, holding a mirror of the primary site (commonly with slightly less capacity for cost reasons). If there is a major problem (disaster) with the primary site, traffic is redirected to the disaster recovery site and operations can continue while the primary site is being rebuilt.