Steve Young - Fotolia

Running a private certificate authority: What are the risks?

Running a private certificate authority can pose significant risks and challenges to meet baseline requirements. Michael Cobb explores what enterprises should know.

Is it possible to create a public key infrastructure that can bypass certificate authority baseline requirements...

and browser certificate policies? Is there server software that can bypass the policies and requirements?

Without knowing why such a requirement exists, it's difficult to offer advice other than these policies and requirements exist for a reason, and any network relying on a noncompliant public key infrastructure (PKI) is at risk for man-in-the-middle attacks, snooping and worse.

Enterprises have long used self-signed certificates, or set up private certification authorities to authenticate and secure internal servers, applications and IP addresses that do not require public trust, yet need the security provided by SSL encryption. However, in such situations, it's important to use appropriate, dedicated hardware and software to provide the necessary level of security.

Due to the seriousness of attacks abusing incorrectly installed or incorrectly issued certificates, the CA/Browser Forum, which manages the baseline requirements for the issuance and management of publicly trusted certificates, and sets the industry standard for the use of SSL certificates, introduced stricter checks and controls on public certificate authorities and the types of certificates they can issue.

For example, since 2015, the CA/Browser Forum no longer allows publicly trusted SSL certificates to include local names, such as internal server names and reserved IP addresses. Likewise, it's no longer possible to purchase a validated SSL certificate for mail or wiki domain names for internal use. This is why many companies run their own private certificate authorities and use self-signed certificates; it reduces costs and enables the use of domain names like mail, wiki and test.

Microsoft Windows Server and other server operating systems provide the ability to operate a private certificate authority. Other third-party solutions also exist, like Symantec's Private Certification Authority and GlobalSign's IntranetSSL, which issues certificates using GlobalSign nonpublic CAs.

Because these certificates are issued from nonpublicly trusted root certificates -- roots that are not distributed by the major browser and operating system vendors -- the certificates are not constrained by the CA/Browser Forum baseline requirements.

However, to prevent internal users' browsers from flagging these certificates as untrusted, it's necessary to push out the nonpublic root certificates to users via Group Policy Object or another centralized management system. This enables network administrators to configure internal browsers to accept certificates issued by the private certificate authority, although they still won't be trusted outside the network environment. Any public-facing servers used in production environments have to use certificates issued by root certificate authorities that are trusted by all the major operating systems.

Even though administrators don't have to maintain the same stringent controls over their in-house certificate keys and infrastructure as a public certificate authority, weak security practices can compromise the entire PKI and create a situation where no internal certificates can be trusted.

Before committing to running a private certificate authority, take the time to understand the pros and cons of running an internal PKI, and ensure that the IT department has the in-house skills and resources to manage it effectively and securely.

Next Steps

Learn how PKI problems can complicate VPN management

Read more about the differences between public and private CAs

Find out about different CA management products

This was last published in October 2017

Dig Deeper on Identity and access management