The importance of certificate authority
Certificate authority (CA) is a complex subject in cryptography. It combines encryption and key management to establish trust throughout a network. Certificate authorities are essential to authenticating users, devices, websites, and other digital objects. Without digital certificates, it would be difficult to know whether or not certain users are authorized to access resources on a network. It would be next to impossible to prove that the users and machines we communicate with are who they claim to be.
Given its importance and complexity, this article will shine some light on the topic and, hopefully, make it easier to understand.
Definition and overview
A certificate authority is a cryptographic system that creates and manages digital certificates. Digital certificates authenticate users, devices, websites, and other digital objects. They verify these entities by binding their identifying information—such as a user’s name or a computer’s IP address—with asymmetric encryption keys. With digital certificates, client devices can prove their identities to other entities in a network.
For example, when you visit a website, your browser checks the website’s digital certificate to make sure the site is authentic. If the website’s certificate was issued by a trusted certificate authority (and is still valid), then your browser will establish an encrypted connection with the site.
CAs are interrelated with public key infrastructure (PKI), a cryptographic system designed to manage digital certificates for the purpose of network security and authentication.
Digital certificates explained
We’ve explained that CAs use digital certificates to verify entities and create trust. But what are digital certificates, and how (or perhaps why) do they work?
Concretely, digital certificates are electronic files. Each one contains information that identifies the entity to which the certificate is issued. For instance, if a certificate is issued for a website, the identifying information it contains may include the website’s fully qualified domain name or the name of the site’s owner. A certificate also contains the public key of the CA that issued it.
Certificates and asymmetric encryption
The public key is half of what’s called an “asymmetric” encryption key pair. These asymmetric key pairs consist of two different types of encryption keys: a public key which encrypts data, and a private key which decrypts data. When someone receives data encrypted under their public key, their computer uses their private key to authenticate the public key and to decrypt the data.
- Public Key: When someone or something sends encrypted data to the owner of an asymmetric key pair, they (or rather, their computer or application) will run an algorithm that uses the public key to encrypt the data.
- Private Key: When the owner of the asymmetric key pair receives encrypted data that was encrypted under their public key, they use their private key to decrypt that data and reveal the original message.
International standards for certificates
X.509 is an international standard for public key certificates. X.509 certificates are commonly used by major internet protocols like TLS/SSL. The X.509 standard includes specific fields of identifiable information within a certificate.
The standard fields of an X.509 certificate include serial number, what algorithm was used to produce the signature, the certificate issuer name and ID, the certificate’s validity period, the subject name and ID, public key information, and more. A CA can then refer to these fields to verify incoming certificates and requests.
Issuing and managing certificates
In addition to issuing certificates, certificate authorities also manage the lifecycles of certificates. The certificate lifecycle involves creating, issuing, renewing, revoking, and suspending certificates.
Certificate authorities exist within logical hierarchies. At the top of the hierarchical pyramid is the offline root CA. Subordinate to the root are intermediate CAs, followed by issuing CAs and registration authorities (RAs). Below is a summary of the different components of CA hierarchy.
Offline root CA
The offline root CA is the absolute anchor of trust for the entire system. Because the negative consequences of a compromised root CA are impossible to exaggerate, its cryptographic integrity is safeguarded by keeping it offline, with no network connectivity. The offline root CA is only brought online infrequently to complete very specific tasks, such as signing an issuing CA. Aside from that, the unit is powered-off and stored in a secure, access-controlled environment.
Issuing CAs are subordinate to the offline root CA. They do all the cryptographic heavy lifting associated with CAs, responding to certificate requests, providing certificates for authorized users and devices, and a variety of other services. They can be used in specific organizational or project silos, in different geographic regions, and with unique security levels.
Registration authority (RA)
A registration authority (RA) is an important subset of CA infrastructure. The RA makes the process of submitting certificate signing requests much more efficient by verifying the requests and passing their information along to the CA to issue the appropriate certificates. Quite often the RA is a separate entity from the CA. Futurex, on the other hand, combines them in the same platform for efficiency.
CA management: CRLs and OCSP
CAs can be set up to handle Certificate Revocation Lists (CRLs) and use the Online Certificate Status Protocol (OCSP) to provide information about revoked or expired certificates, ensuring that users can be notified if a certificate becomes invalid.
Deploying a CA
While CA infrastructure may seem complex, it can be deployed in a fairly straight-forward manner. The most secure and user-friendly way to deploy a CA is with a hardware security module (HSM) or key management server. These hardware-backed cryptographic solutions create and host CAs within their architecture. HSMs can generate asymmetric key pairs, encrypt and decrypt data, manage and securely store certificates, and define the CA’s overall security policies.
The setup process
First, an HSM creates an offline root CA. The root CA’s private key is kept offline within a FIPS 140-2 Level 3 and PCI HSM (for EMV CA) validated cryptographic device until the private key is needed to authenticate subsequent CAs. When that need arises, the root CA is brought online to authenticate an issuing CA. The issuing CA creates and signs asymmetric keys, and does most of the work in the digital certificate process.
It’s important to note that there are public certificate authorities well as private certificate authorities. The former are commercially available, while the latter are used for internal purposes within organizations.
In summary, digital certificates are electronic files that contain identifiable information and a public key. They authenticate clients and objects to create trust throughout a network. Certificate authorities (CA) manage certificates by creating, issuing, and revoking them, as well as by determining the security policies which control their use. CAs are created and maintained through cryptographic solutions like HSMs.
Without CAs, it would be close to impossible to establish trust among client devices that communicate over networks. As such, they’re well worth deploying for organizations looking to establish a secure, trusted network backed up by strong encryption and authentication.