Welcome back Securism readers! It’s been a while since my last post, but I have plenty of new topics to write about based on my client engagements the last few months.
For my last PKI engagement, I was called in to assist a customer with replacing a scripted OpenSSL PKI with an enterprise PKI solution. It’s worth noting that personally I believe that an OpenSSL PKI solution can work just fine and is perfectly appropriate for certain situations. However, this customer was struggling with typical certificate management issues (keeping track of expiring certificates, producing reports of issued certificates on demand etc.) which are not easily addressed by OpenSSL’s CA functionality.
During the course of the engagement, we also looked at the customer’s method for issuing certificates to clients. The PKI administrator:
- Logs into PKI system and generates public/private keypairs for client system owners
- Issues a client certificate
- Combines the client’s private key and certificate into a password protected PKCS12 file
- Emails the PKCS12 file directly from the PKI system to the client system owner
- Calls the client system owner and provides them with the PKCS12 passphrase
At face value, this enrollment method has several problems: client private keypairs are stored directly on the PKI system, the passphrase used to protect the PKCS12 file is known to both the PKI administrator and the client system owner, and encrypted PKCS12 files are exchanged via email.
The most obvious solution to this problem is to use one of the many certificate enrollment protocols that are available to permit the client system user to enroll for certificates without requiring the PKI administrator to be involved in the process. Once we identified and appropriate certificate enrollment method, we discussed the impact of switching to an enrollment protocol.
Interestingly enough, once we started doing a risk assessment of the current process vs a client enrollment process, the costs/benefits of the client enrollment process were not as clear as originally thought.
Consider that using an alternative model where the client is responsible for obtaining their certificate themselves, directly from an enrollment server. While it is true that additional vetting of the user can be done when the user applies for a certificate, in my experience most systems are automated assuming that the user has valid credentials to access the enrollment interface. If the PKI administrator is responsible for generating the certificate for the end user, they have an additional opportunity to vet the certificate applicant. Using email to send the certificate to the user also adds an additional control to the process, since the certificate applicant must have access to the email address that the PKI administrator sends the file to. This model also helps reduce the attack surface of the PKI system, since only the PKI administrator issues certificates there is no need to expose the certificate enrollment system to end users.
As with any other risk based decision, it always boils down to exactly what resources you are trying to protect and their value. For my client, the client certificates were being used for machine to machine authentication to a key management system. Unlike S/MIME certificates, non-repudiation isn’t really a factor for these certificates. Additionally, the set of clients that will be issued certificates is relatively small and well known to the PKI administrator.
The lesson learned from this particular engagement is that there is no automatic ‘one size fits all’ solution when choosing certificate enrollment models. Rather than dismiss a solution out of hand because it sounds insecure in theory, it’s important to step back and reconsider all solutions while carefully considering the applicable risks for your environment.