SSL Certificate Management Criteria
It’s fair to claim that certificate-based cryptographic protocols such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS) have enabled ecommerce as we know it today. Organizations use SSL certificates and encryption keys to protect communications across the Internet, making conveniences such as secure online banking, bill paying and shopping the sorts of amenities we’ve come to expect. Of course, ecommerce isn’t the only use for SSL certificates: Organizations rely heavily upon SSL certificates to encrypt data and authenticate systems and applications—both inside and outside the corporate network.
Encryption implementations are generally wheels that don’t squeak: Because they work reliably when properly configured and deployed, many organizations don’t manage their encryption implementations as well as they should. Of course, SSL certificates and encryption keys aren’t the easiest things in the world to manage—especially using manual processes—and this also contributes to their widespread neglect. Unfortunately, few business processes are as important as effective enterprise key and certificate (EKCM) management. Ask any unlucky organization that has suffered a data breach, a failed audit or costly unplanned downtime.
Problems that arise as a result of poor SSL certificate management reside in categories that correspond to the EKCM lifecycle, namely: discovery, enrollment, monitoring, validation, notification, provisioning, remediation, reporting and revocation.
You can’t manage certificates if you don’t know about them, so you must create a comprehensive certificate and key inventory. The discovery process feeds this inventory by telling you:
- What certificates you have: Most organizations are amazed at the number of certificates they have deployed, which is usually more than three to four times the number they think they’ve deployed. Most often this discrepancy is due to various internal teams issuing certificates from multiple internal and external certificate authorities (CA).
- What certificate authority (CA) issued each certificate: This indispensable information is critical to your ability to recover from CA compromises—of which there have been several in the past few years. You must also know how many self-signed certificates (a best-practices no-no) you have in your encryption deployment.
- When each certificate is set to expire: Expired certificates either cause unplanned system outages or open a door through which hackers can enter your network, or both.
- What is the key strength for each certificate in use: Weak key algorithms leave your organization open to hackers who can masquerade their actions as valid activity on the network.
To feed the most useful inventories, the discovery process also includes finding encryption algorithms and key lengths for each certificate. Obviously, manually collecting this sort of detailed information is tedious, time-consuming and error-prone (If you undertake manual discovery, be sure to check with managers who may have deployed certificates for department-specific applications without going through your IT organization.)
Enrollment is the process of submitting a certificate signing request (CSR) to either an external or internal CA. Your enrollment process should:
- Guide requestors by specifying the domain name, certificate configurations and CAs they can use.
- Restrict the number of administrators who are authorized to request certificates, implementing dual controls (separation of duties) where possible to prevent rogue certificates from infiltrating your network.
You should begin the enrollment process well before the date existing certificates expire or you plan to bring new services online. To do this, you’ll need to monitor existing certificates’ expiration dates.
The provisioning process is closely related to enrollment. It includes steps such as:
- Creating keystores to house certificates and private keys (and keystore backups)
- Configuring keystore parameters
- Distributing intermediate root certificates (intermediate root—or CA certificates—validate certificate chains; it’s very important to install the right intermediate root certificates in the right certificate keystores)
- Generating certificates’ key pairs
- Obtaining CA approvals (often a CA requirement)
- Retrieving and installing issued certificates
- Distributing certificates and keys (for many-to-one implementations, such as load-balancing)
Validation involves making sure certificates are correctly installed, configured and working properly. This process also entails checking to make certain certificates comply with your organization’s policies. Again, you’ll need to know the status of every certificate anyone in your organization has deployed—a level of knowledge that you can acquire only by investing a great deal of time and effort if you manually manage certificates.
After you’ve created a comprehensive inventory of the SSL certificates and keys on your network, you must use your inventory system to monitor important events, such as impending expiration dates.
The person who (or process that) monitors your certificates must notify responsible parties in time to replace soon-to-expire certificates, or certificates that have inadequate key lengths, weak algorithms or were issued by a compromised CA (a condition that requires immediate notification).
When responsible parties receive notifications, they must remedy the issues that engendered them. For example, depending upon the type of notification a responsible party receives, he or she may need to:
- Revoke certificates (from rogue or compromised CAs, for example)
- Enroll new certificates (when current certificates will soon expire, for example)
- Notify stakeholders (when a breach occurs, for example)
- Perform other steps to remedy SSL-related problems (replace weak key length certificates, for example)
Internal security policies and external regulations demand accountability. When your organization deals with protected or regulated information (such as personal health information), you must be able to demonstrate compliance.
This entails creating reports to document events, such as authorized or unauthorized access to your keystores. You can obtain data for reports manually, by scouring event logs and other resources—including your comprehensive inventory—or you can automate the reporting process.
Closely related to the remediation process, revocation is the final stage in the EKCM lifecycle. You should always revoke certificates that compromised CAs have signed, for example. And you should revoke expiring certificates that you’re replacing so they don’t become targets for hackers.
Manually performing the aforementioned processes takes an estimated 4.5 hours per year per certificate. If your organization has only a thousand certificates (and most have far more), you need at least two full-time employees to manually manage them. Because manual EKCM is so time and labor intensive (and, consequently, costly), and because manual processes are fraught with the potential for human error, your organization should seriously consider an automated solution.