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:
- Network Solutions
- 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, which makes them perfect for high security internal applications. 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.
Despite the hassle, a private CA offers some very significant benefits. If you foresee needing to issue a high volume of certifications, either because the organization is massive or the certs will need to be reissued frequently, it can be cheaper to run your own CA than to pay for every one issued by a public CA. Private CAs can also be significantly more secure than their public counterparts. Where a public CA hands out certificates to anyone who pays, private CAs restrict their certificates to specific people or devices (usually those within the organization).
Private Certificate Authority Solutions
While possible to generate your own certificate authorities, the process is much less straightforward than creating one with an easy to use management system. Companies such as SecureW2 have created software that can allow you to take advantage of private certificates without building a PKI from the ground up. These solutions can be pivotal as a misconfigured or an expired private CA can leave your network at vulnerable and at risk.
Azure AD DS Certificate Authority
One such solution is Azure AD Domain Services which provides customizable resources for issuing and managing digital certificates used in software security systems that employ public key technologies. One such service allows you to create a policy where you push out a root CA using a Group Policy Object GPO, but you will not be able to use Active Directory Certificate Services (AD CS), or any other PKI, to issue out client certificates which could be used for network authentication.
Private CA Management Software With SecureW2
You can skip the coding and hassle by using SecureW2’s advanced PKI. Our state of the art management tool allows you to benefit from having a private CA without the associated inconveniences that come with them. You can create a private CA in minutes and with SecureW2’s system you can manage and customize your CA ensuring all your security needs are met. It comes with a turnkey suite of Certificate Authority management features so you can customize certificate expiration based on a user’s status, and ensure no certificate expires with our awesome notification features.
SecureW2 also allows you to integrate any SAML/LDAP Identity Provider with your Private CA, which makes it really simple to issue certificates. Create robust policies and issue custom certificate templates based on user groups that already exist in your directory. Our Cloud RADIUS can even perform Identity Lookup with Identity Providers, providing another security measure in those critical moments before you know you need to revoke a certificate.
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.
Internal CA Best Security Practices
If you choose to operate your own certificate authority you’re also responsible for ensuring that it is protected from all threats, internal and external. Here are a few tips to maximize the security of your internal private CA:
- Store the Root CA off-domain. After your Root CA has been used to create intermediate CAs it should be taken offline and stored so that it is protected from wireless attacks in the interim. Ideally a root CA should only ever be stored on a hardware security module (HSM), but they’re prohibitively expensive for smaller organizations. SecureW2 uses HSMs for all of our customers to ensure they have top of the line protection.
- Conduct regular security audits. You would expect a managed PKI service to audit their systems, so it’s only natural that you need to protect yours with the same technique. Pen testing is a must, especially social-engineering tests since they make up a large portion of successful hacks.
- Implement Zero Trust. This recommendation should really apply to your whole network, not just the CA. Limit admin access for CA management to one user and don’t share the credentials. Use proper VLAN segmentation to isolate the intermediate CAs that interact with the rest of the network.
RADIUS Server Certificate Validation
Using a RADIUS server to authenticate users is a sure fire way to defend your network against harmful man-in-the-middle attack. This requires the use of a public key infrastructure (PKI) certificate to identify your RADIUS authentication server. Public certificates authorities are available from well-known certificate authorities like Verisign, Thawte, and GoDaddy, but if devices aren’t configured properly a hacker could easily issue themselves a CA and start spoofing your network. Another option is available if you are using a private certificate authority by distributing a certificate onto your own RADIUS server, significantly increasing your network security.
With either method comes an added level of complexity to the configuration process. The process requires manually configuring the certificate authority or installing the certificate, setting options to verify the certificate, entering the domain of the trusted RADIUS server, and more. The steps to accomplish all this will be different for every type of device you need to support, from company laptops to BYOD hardware like tablets and smartphones. Many devices, including those running Android, do not expose certificate settings to the user, making them very difficult to configure.
SecureW2’s JoinNow MultiOS technology offers a solution to this problem. With JoinNow you will be able to deploy certificates to any type of device on the market. Secure your network with public or private RADIUS server certificates while providing a quick and painless user experience, click here to learn more.