- 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
- Authenticating URL purge requests via API
- 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
- Getting started with surrogate keys
- HTTP/2 server push
- Implementing API cache control
- Logging purge requests
- Making query strings agnostic
- Purging API cache with surrogate keys
- Request collapsing
- Segmented Caching
- Serving stale content
- Setting Surrogate-Key headers based on a URL
- Setting Surrogate-Key headers for Amazon S3 origins
- Single purges
- Soft purges
- Streaming Miss
- Wildcard purges
- 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
Serving HTTPS traffic using Fastly-managed certificates
Last updated September 28, 2019
IMPORTANT: This feature is part of a limited availability release. For more information, see our product and feature lifecycle descriptions.
This guide describes how to use Fastly TLS to enable HTTPS for a domain using a certificate managed by Fastly. Fastly-managed certificates use the ACME protocol to procure and renew TLS certificates from Let’s Encrypt.
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. TLS (Transport Level Security) and its predecessor SSL (Secure Sockets Layer) are the protocols that allow clients to form secure server connections so traffic can be served over HTTPS.
TIP: Our TLS subscriptions API allows you to manage Fastly TLS subscriptions programmatically.
Before you begin
To use Fastly TLS with Fastly-managed certificates, be sure you have the following prerequisites in place:
- a paid Fastly user account (not a developer’s trial) assigned the role of superuser or assigned a user role with added TLS management permission
- permission to modify the DNS records on the relevant domains that appear as SAN entries on the TLS certificate
- the relevant domains added to a properly configured Fastly service
In addition to these prerequisites, be sure you understand the following limitations:
- Fastly TLS cannot be used by customers with TLS certificates that have been uploaded as part of the Customer-Provided TLS Certificate Hosting Service. For information on migrating certificates from the Customer-Provided TLS Certificate Hosting Service to Fastly TLS, contact email@example.com.
- Fastly TLS comes with a 50 certificate limit. To discuss how to raise this product’s certificate limit, contact firstname.lastname@example.org.
- Fastly generates one certificate per domain.
- Fastly managed certificates require clients to support TLS v1.2 and Server Name Indication (SNI) by default. To discuss how you can use settings other than these defaults, contact email@example.com. The ability to use custom settings may require you to use a dedicated Fastly IP address pool, which must be purchased separately.
- Fastly TLS does not support the Triple DES (3des) cipher suite.
Setting up TLS for a domain
To set up TLS for an HTTPS domain, follow the steps below.
- Log in to the Fastly web interface and click the Configure link.
- Click the HTTPS and network tab. The TLS domains page appears, displaying any domains for which you have TLS either enabled or for which TLS can be enabled. If you've not yet started setting up TLS on any of your domains, this page appears empty.
Click the Add HTTPS to your domains button. The Enter domain window appears.
- If you have your own TLS certificates and private keys, click the I want to bring my own certificate and private key link, and follow the guide to uploading and deploying your own certificates instead of this one.
- In the Domain name field, enter an apex domain (e.g.,
example.com), a subdomain (e.g.,
api.example.com), or a wildcard domain (e.g.,
- Optionally, if you have access to multiple Fastly IP addresses or have multiple Fastly CNAME records created with different networking or TLS configurations, then from the TLS configuration menu, select which TLS configuration to apply. This option defines both the IPs that the certificate will be deployed to and the associated TLS settings that will be applied.
- Click the Add domain button. The TLS domains page appears with a series of cards displayed, each listing a single domain, including the domain you just added along with any other domains and their current TLS and certificate statuses.
Verifying domain ownership
To begin serving HTTPS traffic, Fastly needs to verify that you control any domain you’ve added to the web interface. Fastly offers two options to verify apex domains and subdomains: the ACME DNS challenge type and the ACME HTTP challenge type. Each requires you to make specific DNS changes. Wildcard domains require the DNS challenge type.
IMPORTANT: Fastly may modify the behavior of your services and DNS to complete ACME challenges for domain verification.
Using the ACME DNS challenge to verify domain ownership
The default method for verifying you control a domain being added to a Fastly managed TLS certificate uses the ACME DNS challenge type. It’s suitable for all kinds of domains (apex, subdomains, and wildcards). It will only point the
_acme-challenge subdomain at Fastly, allowing you to set up TLS first, before pointing production traffic at Fastly.
To use this verification method, create a CNAME record with a unique target for your domain. The formats for the record and target appear in the What’s next notification above your domain’s name in the list of TLS domains.
The steps to create the CNAME record will vary depending on your DNS provider's control panel interfaces. Refer to your DNS provider's documentation for exact instructions on how to do this. Your CNAME record must use the format
_acme-challenge.www.example.com) and must be pointed to a unique target for your domain (e.g.,
domain_token.fastly-validations.com). Once you’ve pointed your DNS records at Fastly, we encourage you to keep the
_acme-challenge subdomain CNAME in place to avoid interruptions in service.
Using the ACME HTTP challenge to verify domain ownership
An alternative method for verifying you control a domain uses the ACME HTTP challenge. This method is only suitable for apex domains and subdomains (wildcard domains can only be verified using the DNS challenge). It will point production traffic immediately at Fastly.
WARNING: The ACME HTTP challenge domain verification method can potentially point all end-user traffic to Fastly before you’ve completed TLS setup. This means that your end users may get an insecure warning in their browser related to your website or be totally unable to access your domain. To avoid this, ensure you have a properly configured Fastly service and have disabled any forced TLS redirection before you use this verification method.
To use this verification method, click the Alternative domain verification method(s) link in the What’s next notification above your domain’s name in the list of TLS domains. A verification options window appears:
Choose the verification alternative that suits your needs:
- for a subdomain, create a CNAME record that points directly to the Fastly hostname
- for an apex domain, create A records for the domain with the noted IP addresses
In both cases, once set up, production traffic will immediately begin flowing through Fastly.
What happens next
It should take no more than an hour for the TLS enablement process to progress through all of the TLS statuses shown below:
|Checking domain DNS records…
Step 1 of 3
|Domain validation is in progress. Fastly is checking domain DNS records to verify that you control the domain being added to a certificate. To advance to the next enablement state, you must verify control by updating your domain’s DNS records to complete one of the ACME challenge types.|
|Certificate requested. Waiting for response from CA…
Step 2 of 3
|Domain validation has been confirmed. Fastly believes the DNS records correctly point at Fastly and a certificate has been requested from the Certification Authority.|
|TLS enabled (certificate being deployed globally)||The Certification Authority has issued a TLS certificate. Newly issued certificates can take between 20 minutes to an hour to fully deploy across Fastly’s global network.|
If more than an hour has passed and TLS enablement appears to be stalled in one of the stages of adding a domain, there is likely an issue.
Domains stuck in the Checking domain DNS records state
If the domain is stuck in the
Checking domain DNS records state, it is likely that you have not configured your DNS records correctly in order to verify domain ownership. You can check the DNS records yourself using a
dig command in a command line application as follows:
|ACME challenge type||Command to type|
Be sure to replace
example.com with hostname you used when you configured your DNS records.
If you have correctly configured your DNS records, the result from this command will include one of the CNAME or A Records required for verification as defined in the Verifying domain ownership instructions.
If you recently added or modified DNS records, you may need to wait up to 72 hours for your DNS changes to propagate across the internet. If you don’t see these addresses within that time period, you may have misconfigured your DNS records.
If you are still having issues, there may be a CAA record on your domain that is blocking the certification authority from issuing certificates. This Certification Authority Authorization (CAA) record is used to specify which Certification Authorities (CAs) are allowed to issue certificates for a domain. If a CAA record exists, you may need to remove this record in order to use a managed Fastly TLS certificate.
Domains stuck in the Certificate requested state
If the domain is stuck in the
Waiting for a response from CA state, this is likely a temporary issue with the Certification Authority. Be sure to allow up to an hour in this state before contacting firstname.lastname@example.org for assistance. If this is a new certificate request, you can also try deleting the domain and starting again.
TLS enabled but certificate not deployed everywhere
If the domain displays the
TLS enabled state but the certificate doesn’t appear to be available everywhere, the certificate is likely still in the process of being deployed throughout the Fastly network. It can take anywhere from 20 minutes to an hour for certificates to fully deploy. Be sure to allow up to an hour in this state before contacting email@example.com for assistance.
Pointing DNS to serve HTTPS traffic
To serve secure traffic via HTTPS once the certificate is deployed, follow these steps.
- Ensure that the domains you've added via the TLS domains interface have been added to a properly configured Fastly service.
- Configure your DNS records to point traffic at the newly created certificate’s IP addresses. All DNS details (CNAME, A records, and optionally AAAA records) can be found by clicking More details to view the TLS configuration associated with the domain. If you used the HTTP challenge method to verify domain ownership, you’re already pointing traffic at the certificate.
If you have custom network maps or multiple, dedicated IPs, your domains and certificates can be set to use one or more TLS configurations. For more information, refer to the details on managing DNS and TLS configurations.
WARNING: If you point your DNS away from Fastly after the initial setup, we will be unable to terminate TLS on your behalf and we will also be unable to renew your certificate, which will expire after 90 days.
Disabling TLS and deleting a TLS domain
Once a domain has TLS enabled, you have the option to disable TLS via the Disable TLS link listed on the TLS domains page. Once disabled, Fastly will no longer serve TLS traffic on the selected domain. Fastly will attempt to renew a certificate for a disabled domain. To prevent this renewal process, you must delete the domain after you disable it. Fastly will not renew certificates for deleted domains.
Certificate management and renewals
Let’s Encrypt issues certificates that are valid for 90 days. Fastly will attempt to re-verify your domain and renew your certificate after 60 days. However, if DNS records no longer point at Fastly, or if a CAA record blocks Let's Encrypt, the certificate will lapse at the end of the 90-day period.
Thirty days before it is due to expire, Fastly will automatically email all account users with TLS management permissions, notifying them of the upcoming expiration. If the renewal continues to fail, Fastly will continue to email users on the account on a schedule up until the expiry date.
If you have the correct DNS records for verifying domain ownership, and there is no blocking CAA record, but you are still receiving renewal failure emails, contact firstname.lastname@example.org.
Migrating domains from shared certificates to Fastly-managed certificates
To migrate a domain on Fastly’s shared certificates over to the Fastly TLS product, start by following the Setting up TLS for a domain instructions. Be sure to use the ACME DNS challenge using the
_acme-challenge subdomain for verification, to keep production traffic pointing at the shared certificate.
Once your domain enters the TLS enabled state, wait at least 10 minutes and then verify that the certificate is globally deployed before changing over your DNS records to point away from the active shared certificate. You can do this using the following command in a command line application:
1 openssl s_client -connect TLS.CONFIG.CNAME.RECORD:443 -servername your.domain.com | openssl x509 -noout -text | grep 'Subject: CN'
If the result includes your TLS hostname, this means that Fastly has successfully generated and deployed a managed certificate to our network, and it is safe to update your DNS records with your DNS provider.
If you are currently using a shared certificate with a wildcard or subdomain, your CNAME record will likely end in
shared.global.fastly.net. For apex domains, you will likely be using four A records. Provided the certificate is present on our network, you can now use the DNS records outlined in the Pointing DNS to serve HTTPS traffic instructions to point your domain to your new certificate, and away from the shared certificate.
After changing the DNS records for the domain with your DNS provider, check to see if the changes have propagated to a local DNS resolver by using the following command:
1 dig your.domain.com +short
TIP: Depending on your time to live (TTL) settings, you may need to allow up to 72 hours for DNS records to propagate across the internet.
As soon as your DNS information has been updated worldwide, visit your domain in a browser and check to see which certificate is served. Once you confirm that the new certificate is being served across clients, follow the instructions for deleting a TLS domain to remove the domain from the shared certificate.Back to Top