- About the web interface controls
- Always-on DDoS mitigation
- Browser recommendations when using the Fastly web interface
- Content and its delivery
- Fastly POP locations
- Getting started with Fastly
- How caching and CDNs work
- How Fastly's CDN Service works
- HTTP status codes cached by default
- Self-provisioned Fastly services
- Sign up and create your first service
- Working with services
Domains & Origins
Domains & Origins
- Changing origins based on user location
- Connecting to origins
- Enabling global POPs
- Failover configuration
- IPv6 support
- Maintaining separate HTTP and HTTPS requests to origin servers
- Routing assets to different origins
- Setting up redundant origin servers
- Specifying an override host
- Using Fastly with apex domains
- About Dynamic Servers
- Cache control tutorial
- Caching configuration best practices
- Controlling caching
- Creating and using pools with Dynamic Servers
- Creating and using server entries with Dynamic Servers
- Enabling API caching
- Enabling automatic gzipping
- Failure modes with large files
- HTTP/2 server push
- Implementing API cache control
- Making query strings agnostic
- Request collapsing
- Segmented Caching
- Serving stale content
- Setting Surrogate-Key headers based on a URL
- Setting Surrogate-Key headers for Amazon S3 origins
- Streaming Miss
- Accept-Language header VCL features
- Authenticating before returning a request
- Basic authentication
- Creating location-based tagging
- Custom responses that don't hit origin servers
- Delivering different content to different devices
- Enabling URL token validation
- Guide to VCL
- Isolating header values without regular expressions
- Manipulating the cache key
- IP geolocation variables: Migrating to the new dataset
- Overriding which IP address the geolocation features use
- Response Cookie handling
- Support for the Edge-Control header
- Understanding the different PASS action behaviors
- Using edge side includes (ESI)
- VCL regular expression cheat sheet
Access Control Lists
Monitoring and testing
- Domain validation for TLS certificates
- Enabling HSTS through Fastly
- Forcing a TLS redirect
- Managing domains on TLS certificates
- Serving HTTPS traffic using certificates you manage
- Serving HTTPS traffic using Fastly-managed certificates
- Setting up free TLS
- TLS key and certificate replacement
- TLS termination
Web Application Firewall
- Log streaming: Amazon S3
- Log streaming: Microsoft Azure Blob Storage
- Log streaming: Cloud Files
- Log streaming: Datadog
- Log streaming: DigitalOcean Spaces
- Log streaming: Elasticsearch
- Log streaming: FTP
- Log streaming: Google BigQuery
- Log streaming: Google Cloud Storage
- Log streaming: Honeycomb
- Log streaming: Kafka
- Log streaming: Log Shuttle
- Log streaming: LogDNA
- Log streaming: Logentries
- Log streaming: Loggly
- Log streaming: Heroku's Logplex
- Log streaming: OpenStack
- Log streaming: Papertrail
- Log streaming: Scalyr
- Log streaming: SFTP
- Log streaming: Splunk
- Log streaming: Sumo Logic
- Log streaming: Syslog
User access and control
TLS key and certificate replacement
Last updated September 09, 2019
IMPORTANT: This information is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.
To serve secure traffic from Fastly using HTTPS, a website or application needs to provide clients with a valid TLS certificate signed by a trusted certification authority. Fastly offers a number of ways to deploy TLS certificates across our edge network.
This guide describes how to replace the keys and certificates used to terminate TLS for domains that have already been configured within the Fastly system. If you generate your own keys and certificates and transfer them to Fastly to install, contact firstname.lastname@example.org to see if you qualify for this interface.
To upload new private keys and replace TLS certificates using the web interface, you will need:
- a Fastly user account assigned the role of superuser, or assigned a user role with added TLS management permission
- a valid X.509 TLS certificate from a trusted certification authority (CA)
- a matching 2048-bit RSA private key
- The web interface does not accept 4096-bit keys. If you have such a key you must use Fastly's certificate uploading tool to upload your key.
- When replacing a certificate, the SAN entries of the new certificate must either be an exact match or contain a superset of entries when compared with the existing certificate. All existing domains will be automatically enabled on the new certificate.
Accessing the HTTPS and network settings page
To access the HTTPS and network settings page, log in to your Fastly account, click the Configure link, and then click the HTTPS and network tab.
This brings you to the TLS certificates page, which lets you view your certificates and private keys, and allows you to upload new keys and replace your existing certificates.
Replacing a key and certificate
To upload the new key and replace the certificate used to terminate TLS for a domain, first you must generate a new key and certificate with your preferred certification authority. When regenerating a new certificate, you must specify the exact same list of SAN entries as the existing certificate. The TLS certificates page will provide you with information on all of your current certificates and the SAN entries of each of those certificates. If you need to modify the SAN entries for a particular certificate, or if you need to add a brand new certificate for a new set of domains, contact email@example.com for assistance.
In order to replace a TLS certificate you will first need to upload the matching private key that was used to generate the new certificate.
On the TLS certificates page there is a drag-and-drop area that you can use to drop your private key file. Alternatively you can browse your file system for the private key. This upload tool currently only accepts 2048-bit RSA keys. If you require longer key lengths, contact firstname.lastname@example.org. Valid private keys will automatically upload to Fastly upon being dropped on the page, or after being selected from the file picker.
Upon successfully uploading a private key, the TLS certificates page will display the key with the label, Orphan key. This refers to a private key that has no matching TLS certificate. If you have multiple private keys, you will be able to identify each by a unique upload date time. Private keys can only be deleted if they are in the orphan state.
Once you have uploaded the new private key, you will be able to replace the TLS certificate. Find the certificate in the list of certificates. In the example below we show a certificate that is nearing expiration. You will see the Replace icon at the top-right corner. Clicking this icon brings up a file-picker that can be used to select the new certificate. The certificate you select should be PEM-formatted and must contain all the same SAN entries as the current TLS certificate, either as an exact matchinig list, or as a superset. You can select either a file containing the full certificate chain or a file containing just the leaf certificate. The intermediate certificates will be automatically backfilled when just the leaf certificate is uploaded.
After selecting the new certificate, a success message will be displayed and the certificate information will be updated. When a certificate is replaced, it will be automatically deployed and all domains actively serving TLS traffic on the old certificate will be automatically transitioned to the updated certificate within a matter of minutes.
NOTE: If the new certificate is not being used to serve TLS traffic within 1 hour, contact email@example.com for assistance.
There may be situations where Fastly identifies certificates that should be replaced. These certificates will be clearly marked.
Back to Top