Being Your Own SSL Certificate Authority

[Excerpted from "SSL Authentication: Create And Manage Your Own CA," a new report posted this week on Dark Reading's Authentication Tech Center]

When it comes to Secure Sockets Layer (SSL) deployments, the most complex element of this digital certificate infrastructure is the certificate authority (CA), and so properly building, managing, and securing your in-house CA is crucial.

There's a considerable burden in overhead and processes involved in generating certificates, configuring applications to authenticate via certificates, and managing the rotation of expiring certificates. Nonetheless, self-signed certificates are generally a much more cost-effective approach for internal systems accessed only within the enterprise. Third-party validation is not required, and the cost for the volume of certificates generated for internal usage would be prohibitive.

SSL certificates can be used to secure mobile devices as well as for VPN authentication. Given the increased use of mobile devices, particularly smartphones, to access critical corporate applications and concern over storage of sensitive information, SSL certificates provide a high level of security by identifying both the user and device. In addition, some enterprises are reluctant to extend internal passwords to mobile devices, and want to reduce management and security concerns about expired passwords stored on them.

In addition, organizations often require two-factor authentication for VPN users; certificates can be easier for the enterprise to deploy and more cost-effective than other multifactor authentication technologies. They also work across more technology platforms. As is often the case, there is a trade-off in security vs. manageability, since certificates can be copied and stolen from a device more easily than some other two-factor authentication methods.

Regardless, several hundred Web servers or applications requiring certificates can be a burden. Further, certificates expire every so often to protect against long-term brute force attacks. If not replaced properly, expired certificates can break production as end users get error messages. Further, a certificate sometimes must be revoked, perhaps because it is believed to have been compromised or issued in error, or some value of the certificate, such as the contact information, needs to be changed. Revocation is impossible without a proper CA infrastructure used to validate certificates.

Many companies use commercial public key infrastructure (PKI) products to generate, issue, validate, and manage certificates. Deploying PKI can reduce the overhead associated with certificate requests, generation, and validation. Enterprises rolling out a third-party PKI can configure this PKI to act as the certificate authority.

PKI systems remove several problems in the certificate-generation process. For starters, PKI systems are built based on lessons learned and industry standards. They can ensure certificates are created with company-specified strength and settings, such as requirements that all certificates are at least 128 bits with a particular expiration date (certification expiration dates typically are set no more than two years out).

PKI also assures the use of strong encryption keys, removes the need for manual access to the code used for generating and revoking certificates, and enforces standards--for example, the inclusion of proper company name, department name, and contact information within the certificate.

The purpose of SSL -- to protect data in transit -- will be undermined if you don't take the steps necessary to secure the certificate-issuance/management process. To find out more about how to secure the SSL certificate process, download the free report.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.