Partner Blog 03-09-2018

Keeping Subscribers Safe: Partner Best Practices

Vincent Lynch

As a Certificate Authority, we’ve always prioritized security when it comes to our infrastructure, adherence to industry standards, and the products we provide. As a DigiCert Partner, we want to make it easy for you to place that same level of care in security.

After years of experience building our infrastructure—and working with our partners building their own businesses—we’ve learned best practices for security, and we want to pass them on.

Not all customers have a technical background or experience with deploying SSL. As their provider, these users will seek your guidance and recommendations, which makes it incredibly important to promote best practices and design your own systems with them in mind.

Maintaining a Secure Website

Partners should make sure their website and any associated functionality is secure and free from exploitable vulnerabilities.

This can be broken down into three main categories:

  1. Serve all pages over HTTPS and check your server configuration to make sure it complies with industry best practices. We recommend deploying HSTS, which ensures your site is only accessible over HTTPS.
  2. Make sure operating systems, web servers, and any other components are regularly patched and updated.
  3. Make sure any custom software is free from common vulnerabilities, like injection flaws.

Protecting Subscriber Keys

A subscriber’s (the certificate end-user and your customer) private key is what is used to uniquely authenticate the subscriber. It’s a significant security risk if the subscriber’s private key can be accessed by anyone other than the subscriber.

Industry best practice is for the subscriber to generate their own key pair and CSR directly on their web server or a local machine.  In certain situations (for example, hosting environments), it’s necessary for the hosting provider to have access to the subscriber’s private key in order to provide HTTPS services, but outside of these situations, Partners shouldn’t have access to private keys unless absolutely necessary.

We don’t recommend storing private keys for users or making them available for download through user portals.

Section 6.1.2 of the CAB/Forum Baseline Requirements states that parties other than the Subscriber SHALL NOT archive the Subscriber private key without explicit authorization by the Subscriber. Again, the best way to accomplish this is for the subscriber to generate the private key themselves, and for the Partner to never have access to it.

In cases where you provide guidance or assistance to your users, ensure that you are using current best practices and defaulting to secure options. For instance, recommend new industry standards for key lengths and hashing algorithms, instead of older methods that may provide more compatibility but are closer to being deprecated due to security risks.

When certificates are renewed, make sure users take that opportunity to create a new key pair instead of reusing the existing one. By rotating keys with certificate renewal, you limit the risk posed by a compromised key or poor key storage hygiene.

Providing DigiCert Tools

DigiCert provides a number of excellent tools, including tools to assist subscribers in creating CSRs (https://www.digicert.com/csr-creation.htm). Partners are encouraged to point customers to these tools, which have been vetted to make sure they appropriately protect subscriber information.

More Information

With the wide range of use cases and end-user scenarios it can be hard to account for every situation. As industry standards and technologies change, you may find yourself questioning practices and procedures. If you have any concerns or questions, please reach out to partner-bestpractices@digicert.com.

 
UP NEXT
PKI

3 Surprising Uses of PKI in Big Companies and How to Ensure They Are all Secure

5 Min

Featured Stories

04-11-2024

Pioneering the next wave of secure digital solutions 

Why Q-Day is closer than you think

The challenges of achieving crypto-agility for private keys