An Overview of Registration Authority Functionality in the KMES Series
The KMES Series has long been a reliable source for certificate authority (CA) functionality, and now the KMES Series has expanded to incorporate the functionality of a registration authority (RA). This post intends to provide users with a glimpse at how an RA works within a public key infrastructure and how this technology can be accessed.
Public key infrastructure (PKI) is a system of people, processes, and technologies used to manage, create, and revoke digital certificates. Using PKI, multiple users can communicate privately on a public network. As you may have noticed when your web browsers’ address bars are marked with a green “HTTPS” and the padlock icon, TLS encryption is acting to protect your web browsing. TLS encryption is reliant on the core concept of PKI. The RA and CA are two prominent aspects of PKI known as trusted third parties.
How CAs and RAs Work Together
In short, CAs are a trusted source for securely signing, issuing, revoking, and storing certificates. RAs preside over CAs and inform them of which certificates can be issued. When users place requests for digital certificates, RAs verify the identity of requesters before forwarding the request to the CA. Often using an RA, users create a certificate signing request (CSR) that will be sent to the CA. The CSR contains enough information to confirm the user’s identity and the user’s public key. The CA, after validating the user’s identity, creates a digital certificate with the user’s public key, and signs the certificate with the user’s private key.
As depicted in this diagram, featuring both an RA and a CA (on the right), a user applies for a certificate at the RA using their public key. The RA confirms the user’s identity by having multiple approvers log in to verify the request. After approval is granted, the CA allows the original user to download the certificate.
How Futurex RA Functionality is Accessed
For greater convenience for the end user, Futurex leverages RA functionality across multiple channels, including through a GUI, an API command set, and a secure web portal.
GUI: Through the client GUI, users can leverage full control of RA functionality. From this tab, users can create, edit, delete, and filter registration authorities; or users could create, edit, delete, revoke, approve, deny, or renew certificate signing requests. Users can anonymously add certificate requests, making it easier for large organizations who do not have the time to create a user account for each user needing to upload CSRs. Additionally, users can oversee every aspect of X.509 extension profiles through creating, modifying, and applying templates. Once certificates have been signed, users can download them as .pem or .der files.
Web Server: This web portal is accessible from virtually anywhere with an internet connection. Once enabled, the portal can allow for users to upload, submit, approve, or deny CSRs. Once the CSRs have been signed, users can download the associated certificates. Users can also anonymously upload certificate signing requests through the web portal.
API Commands: A complete set of API commands allows users to manage RAs, X.509 templates, and CSRs. The commands are provided through a technical reference that gives further details and examples of command usage.
For enterprise-level organizations, the RA functionality can save time and resources by providing an accessible and robust channel for creating and verifying certificate signing requests. Since it is stored within the same device as the CA, users benefit from the maximum level of convenience and functionality. Equally importantly, all functionality is displayed in an intuitive, easy-to-learn, and graphics-based interface, reducing training time.