It's clear digital certificates can be a great option for your security projects (e.g.,authentication, digital signatures, secure email), but once you've decided on a certificate-based solution, you also need to consider if you're going to partner with a public, cloud-based CA to issue and manage the certificates, or if you're going to run your own PKI services in-house (often by using a Microsoft CA).
There are pros and cons to each scenario, but with advances in public CA offerings and a constantly evolving PKI landscape, some of the most popular reasons for running your own CA may not hold as much weight as they used to. Let's reconsider three of the ones we hear most often.
"It's free..."
This is one of the most common reasons we hear - when we surveyed a group of IT professionals, a whopping 70% of respondents cited this as the main reason for using a Microsoft CA - and refers to the fact that Microsoft CA Services are included with Windows Enterprise Server. While it's true that there isn't a fee for using the services or the certificates you issue, to say that running a Microsoft CA is "free" is oversimplifying matters and can be misleading.
Consider:
-
Internal staffing costs of managing the CA
-
Hardware costs (the hardware security module needed to store your root and signing private keys alone typically cost $20K)
-
Internal (and possibly external) SLA for both certificate issuance, but also certificate lifecycle management and validation services (e.g. updating CRLs, keeping CRLs, and running OCSP services)
-
Are CA best practices being applied to security, policy, and auditing of your CA?
"But I need to connect to Active Directory..."
For organizations operating a Windows environment, being able to leverage the certificate template information already included in Microsoft certificate services, can make running a Microsoft CA extremely appealing. Since AD and Microsoft Certificate Services are connected, you can seamlessly register and provision certificates to all domain-connected objects based on group policies. Auto-enrollment and silent installation makes the certificate deployment process easy for IT administrators and end users alike. There's no denying the benefits of integrating with AD, but thinking that this can only be achieved with a Microsoft CA just isn't the case anymore.
Consider:
-
Most public CAs now offer an Active Directory integration that achieves this same functionality, but using their own proxy into AD rather than Microsoft's
"I'm only using my certificates for internal purposes...."
One of the biggest reasons to partner with a public CA is that they're just that - public. Public CAs work diligently to ensure their roots are embedded in the latest browsers and applications, so any certificates issued from the roots are automatically trusted. The benefit to this is obvious for use cases such as SSL for public websites or document signing, but what if you just want certificates for your private network? Or only need to enable S/MIME for internal communications? In those cases, public trust isn't really necessary.
There are many reasons to work with a web trust audited public CA beyond the public nature of the root. Consider:
-
How are you going to protect your root key material?
-
How are you going to keep up with ever-changing PKI best practices and maintain internal compliance? Over half of respondents in our survey reported that they didn't want to manage this burden themselves.
-
Most public CAs offer cost-effective certificate options for internal purposes.
Like I said, there are some reasons you may still want to run your own CA, however, if you're basing your choice on one of those listed above, you may want to reconsider your stance.
