Complete Guide To Certificate Authorities

What is a Certificate Authority?

A Certificate Authority is the body that handles the certificate management for a PKI. They  assist in validating the identities of different websites, individuals and devices before administering digital certificates to them. 

In a PKI system, the client generates a public-private key pair. The public key and the end users information are sent to the CA. The CA then creates a digital certificate consisting of the user’s public key and certificate attributes verifying that the information is correct. The certificate is signed by the CA with its private key, solidifying the legitimacy of the certificate.

Source: en.wikipedia.org/wiki/Certificate_authority

Once the certificate is issued to the user, the user can present the signed certificate to a server, who can then trust that the user is who they claim to be because of the inherent trust of certificate authorities.

Is a Certificate Authority part of a Public Key Infrastructure?

A Public Key Infrastructure (PKI) is implemented by organizations attempting to put their network’s security at the forefront. PKIs rely on asymmetric cryptography, currently the best form of authentication, which consists of a pairing between public and private keys. 

PKI consists of a variety of entities:

  • Certificate Authority
  • Certificate Store
  • Certificate Revocation List
  • Public Key
  • Private Key
  • Hardware Security Module

The Certificate Authority certifies the ownership of the key pairs and generally handles all the management of certificates for the PKI. 

The Trust Hierarchy 

A certificate authority must be trusted in order to fulfill its role in the PKI, But how exactly can it earn that trust?

In short, trustworthy CAs are a part of the CA/Browser Forum, a regulatory group for certificate authorities. They are tasked with creating and updating the guidelines used to govern the creation, use, and distribution of certificates on the internet. A CA that wants to be utilized online is also forced to adhere to a strict set of rules set by different browsers and operating systems. 

Older CAs are usually regarded as more trusted compared to newer ones, as the longer a CA has been active, the more time it has had to prove its trustworthiness.

Certificate Trust Chain

You can trace the path from the client’s certificate back to a single root CA, and every chain ends in a person (or company) from which all the trust is ultimately derived. 

Through cross-signing, we can expand this hierarchy with CAs interlinking trust with each other. This allows certificates to be validated by CAs that trust one another which increases the trust of the certificate. As more CAs sign a certificate the more trust you have in that certificate.

Root vs Intermediate Certificate Authority

Root CAs and Intermediate CAs are both parts of the trust chain that make these certificate-based networks effective.

What is a Root CA?

A Root CA is just that, the “root” of the chain of trust. It is a certificate authority that can be used to issue other certificates, which means it is imperative that Root CAs are secure and trusted. If the Root CA were to be compromised the entirety of the chain would be obsolete. 

In order for a device to get a certificate, it needs to be issued from a trusted source, and because Root CAs can be established by anyone, there must be a work around to establish initial trust. The most common solution is pre-installed Root CAs that come with browsers and applications from their root stores.  These are based on the OS that your device is using, Google, Microsoft, and Apple all have their own, each with stringent guidelines. 

What is an Intermediate CA?

An Intermediate CA is also a CA, and is used as a chain between the root CA and the client certificate that the user enrolls for.  Because the trusted root CA has signed off on the intermediate CA, it is treated as trusted as well. 

SecureW2’s PKI is designed to always make use of an intermediate CA to issue client certificates for Wi-Fi authentication, as is the standard practice. Certificate authorities rarely sign certificates using the root CA directly. They are too valuable and need to be secured at all costs. Instead, they put one or more levels of separation between themselves and the client by using intermediate certificate authorities.

What is a Public Certificate Authority

Public CAs are the default option when it comes to certificate authorities. They are CAs established by organizations to be used by operating systems and web browsers. 

These organizations have garnered trust in the same manner that any organization does, by providing the public with good service over a long period of time. Some examples of trusted organizations with public CAs are:

  1. Symantec
  2. GeoTrust
  3. Comodo
  4. DigiCert
  5. Thawte
  6. GoDaddy
  7. Network Solutions
  8. RapidSSLonline
  9. SSL.com
  10. Entrust Datacard

What is a Private Certificate Authority

Private CAs are locally hosted certificate authorities usually meant for internal use only.

A private CA is only trusted by users within the organization where it was created, usually a large company or university. The potential benefit of this is that with fewer links in the chain of trust there is less potential for a breach of information. The downside is that a private CA needs to be set up and run by an individual, which can cause a massive amount of time and money.

While possible to create your own certificate authorities by yourself, the process is much less straightforward than creating one with an easy to use management system. You can skip the coding and hassle by using SecureW2’s advanced PKI. Click here to learn more.

What is a Certificate Revocation List (CRL)?

A CRL is a list of certificates that have been revoked by the CA that issued them before they were set to expire. This is a vital security feature – if, for example, a device were lost or stolen  the certificate can be revoked from the certificate authority that issued it, protecting your network. 

There are two types of CRL:

  • Base CRL: Large file that contains all non-expired revoked certificates.
  • Delta CRL: Small file that contains all non-expired revoked certificates that have been revoked since the last base CRL was published.

A CRL is typically maintained by the CA that issued the corresponding certificates, but could also come from other trusted sources.

Best Practices For Managing Certificate Authorities

Certificate Authority Cross Signing 

Certificate authority cross signing is a way to expand the trust of one trusted CA to multiple others. If you have CA-X that trusts CA-Y then you indirectly have a trust between all certificates that CA-Y distributes. The same goes for the inverse situation in which CA-Y trusts CA-X then all clients of CA-Y have an indirect trust in CA-X.

Through cross signing, clients can verify trust more efficiently by not having to send certificates to both parties. Every system that trusts either X or Y will be able to validate certificates emitted by both. Furthermore, in a situation where one of the CAs is compromised, your certificates are still valid due to the trust still established from the other party.

Protecting Your Root CA

Root CAs offer a unique challenge when it comes to security because all lower level CAs rely on the trust from the root CA. If a Root CA is compromised, all other CAs linked to it have the potential to be compromised as well. Thus, taking precautionary measures is paramount to network security.

It is recommended to use your root CA only to issue intermediate CAs, and never directly issue certificates to end devices. This minimizes the potential danger if the root CA is compromised.

The post Complete Guide To Certificate Authorities appeared first on SecureW2.


*** This is a Security Bloggers Network syndicated blog from SecureW2 authored by Eytan Raphaely. Read the original post at: https://www.securew2.com/blog/certificate-authority/