5 best practices for your TLS configuration
TLS is wildly important — but it can also be hard to master even for the best engineers, especially at scale. That’s why our team exists. The TLS Support Engineering team provides support for customers managing one to thousands of certificates, and after helping so many customers tailor their DNS and TLS configurations to meet their needs, we’ve learned a few things.
Today, I want to pass on five best practices we’ve learned that you can implement in your workflow to make the most of your TLS configuration:
1. Avoid certificate/key pinning whenever possible.
Security professionals and several certificate authorities advise that certificate pinning is more complex than we think. While several well-known tech companies used to advise pinning certificates, things have changed. Pinning allows websites to control the risk of a Certificate Authority being compromised or man-in-the-middle attacks. With that said, if you configure your settings incorrectly it could lead to blocking access from your website, and the time that would take to solve the issue could cost your company time and money.
2. Create a plan internally for TLS escalations.
As with any security measure, it’s always a good idea to have a back-up plan. Create an internal plan that includes contacting your vendor in case of an emergency. When it comes to Fastly, we recommend:
Have our support email handy at all times: support@fastly.com.
Add in the first sentence of your email P1, this abbreviation for Priority 1 will get our attention right away.
Include in your email any details that will allow us to solve the issue immediately. This can be the certificate ID, TLS configurations, and any domains that might be affected. If we have all this information at first glance, it will save us time so we can immediately help.
Although I’m using Fastly as an example here, this advice really translates across vendors.
3. Make changes early in the week.
Certificates will expire, Subject Alternative Names (SANs) will need to be updated, and Common Names in your certificates can change — all of which means you’ll need to upload a new certificate to continue to secure your traffic. But whether the TLS Support Engineering team does it for you or you do it yourself, allow time when making changes. If you wait until Friday to push changes live, you run the risk of a skeleton team confronting any problems that might occur. Instead, make changes at the beginning of the week, when you have the benefit of the whole team.
4. Get familiar with your TLS user interface.
Get to know the product. We offer extensive documentation on our TLS offerings, but we also pride ourselves on the user-friendly interface of Fastly TLS. By getting to know the UI and learning some key terms, you can streamline the DNS and TLS process.
Here are two key terms important to the Fastly TLS UI:
Fastly Certificate ID: This is a combination of unique numbers and letters that will identify your certificate and will help avoid any confusion by referencing the certificate by its common name, or by the list of SAN’s that are included in the certificate.
TLS Configuration: The type of the data that you will find here is all related to your CNAME, Anycast Records, Protocols, and TLS Versions. By giving the TLS Configuration a unique name and referring to it as so in your tickets, it will guarantee that while you are looking for immediate assistance from our team we will be able to identify the configuration right away.
5. Flag our team.
Here’s a hack specific to Fastly: when sending your question to support@fastly.com, add a short sentence flagging the issue to the TLS Support Engineering team. This will allow our specialized team to work on your issue as soon as you submit the ticket.
By following these best practices, you can streamline your TLS configurations. Not yet a Fastly TLS customer? For more information on our security offerings and our TLS products, check out Fastly Security Documentation.
