HTTPS and TLS
Automatic HTTPS, TLS certificates, and custom domains on Easel.
Every Easel deployment is available over HTTPS.
Easel automatically provisions and renews TLS certificates for deployment URLs and configured custom domains, so visitors can connect securely without manual certificate management.
Automatic HTTPS
Easel enables HTTPS for:
- production deployments
- preview deployments
- Easel-provided deployment domains
- configured custom domains
Requests made over plain HTTP are redirected to HTTPS.
Application code does not need to handle the redirect.
Easel deployment domains
Every deployment receives an Easel-provided HTTPS URL.
The certificate is managed automatically and is ready as part of the deployment lifecycle.
Deployment URLs are useful for:
- previewing changes
- testing production builds
- sharing pull-request deployments
- verifying domain-independent behavior
- diagnosing custom-domain configuration
No additional certificate configuration is required.
Custom domains
When you add a custom domain to an Easel project, Easel verifies the domain configuration and provisions a certificate for it automatically.
A custom domain generally follows this process:
- Add the domain to the Easel project.
- Configure the required DNS records shown in project settings.
- Easel verifies that the domain points to the project.
- Easel provisions the TLS certificate.
- The domain becomes available over HTTPS.
Certificate provisioning begins after the required DNS records are visible.
For setup steps, DNS records, redirects, and migration, see Domains and HTTPS and TLS for custom domains.
Certificate management
Easel manages the certificate lifecycle for supported domains.
This includes:
- certificate issuance
- installation
- renewal
- replacement before expiration
- serving the correct certificate for the requested hostname
You do not need to upload certificate files or private keys for automatically managed domains.
Avoid removing or changing required DNS records after a certificate has been issued. Easel must continue to validate and route the domain correctly in order to renew and serve its certificate.
Provisioning status
A newly added domain may pass through several states before HTTPS is ready.
| Status | Meaning |
|---|---|
| Invalid DNS configuration | The required DNS records are not visible yet or do not match |
| Provisioning SSL certificate | The domain is verified and certificate issuance is in progress |
| Valid configuration | HTTPS is available |
| Configuration error | DNS or domain settings prevent activation |
| Removed | The domain was removed from the project |
DNS changes are not always visible immediately. Provisioning continues automatically after the correct records propagate.
If a domain remains unavailable, inspect its status in the Easel dashboard rather than repeatedly removing and re-adding it.
Domain coverage
A certificate covers only the hostnames associated with the project and included in the certificate configuration.
For example:
are separate hostnames.
Adding example.com does not necessarily configure every subdomain beneath it.
Add each hostname separately. Customer wildcard domains such as *.example.com
are not currently supported.
Apex and subdomain configuration
Easel supports custom domains at both the apex and subdomain level.
Examples:
The required DNS record depends on the hostname and DNS provider.
Apex domains commonly use an address or flattening record, while subdomains commonly use a CNAME. Follow the values shown in the Easel dashboard rather than copying records from another project or provider.
Domain redirects
You can configure one domain as the canonical hostname and redirect alternate domains to it.
For example:
or:
Easel provisions HTTPS for the redirecting hostname as well as the destination hostname. This prevents visitors from encountering a certificate warning before the redirect occurs.
See Domains for domain configuration.
HTTPS redirects
Plain HTTP requests are redirected to the equivalent HTTPS URL.
For example:
is redirected to:
The path and query string are preserved.
Applications should generate secure absolute URLs in production and use secure cookies for authentication-related data.
HSTS
Easel includes the Strict-Transport-Security response header on HTTPS
responses:
HSTS instructs compatible browsers to use HTTPS for later requests to the hostname.
Because browsers can retain HSTS policies for a long time, confirm that the domain can continue serving HTTPS before enabling a custom or more restrictive HSTS policy.
Settings such as the following should be used deliberately:
includeSubDomains affects every subdomain, including subdomains that may not
be hosted by Easel.
Submitting a domain to browser preload lists can also be difficult to reverse. Review all subdomains before enabling preload behavior.
Custom security headers
Applications can add additional HTTPS-related response headers through framework or project configuration.
Common examples include:
These headers control browser behavior and are separate from TLS certificate management.
Test security-policy changes in a preview deployment before applying them to production. A restrictive Content Security Policy can block scripts, styles, images, or third-party integrations required by the application.
Secure cookies
Authentication cookies should use appropriate security attributes.
The Secure attribute prevents the browser from sending the cookie over an
unencrypted HTTP connection.
The appropriate SameSite value depends on the application’s authentication and
cross-origin behavior.
Certificate Authority Authorization
A domain can use CAA DNS records to restrict which certificate authorities may issue certificates for it.
Easel uses Let’s Encrypt for managed certificates. If the domain has CAA records, they must permit Let’s Encrypt. A restrictive or incorrect CAA record can prevent certificate provisioning or renewal.
Example CAA records look like:
Do not invent CAA records for other certificate authorities unless you intentionally issue certificates outside Easel. Confirm that any existing CAA policy still permits Let’s Encrypt.
When troubleshooting issuance, check for CAA records on both the exact hostname and its parent domain.
DNS proxies
Some DNS providers can proxy traffic in front of Easel.
A proxy can affect:
- domain verification
- certificate issuance
- request routing
- client IP forwarding
- redirects
- caching
- security rules
When initially configuring a domain, you may need to disable the proxy until Easel verifies the DNS records and provisions the certificate.
After activation, confirm that any upstream proxy is configured to connect to Easel over HTTPS and does not introduce conflicting redirects or caching behavior.
Connecting to application compute
Visitors establish an HTTPS connection with Easel’s delivery network. Easel then securely routes the request to the deployment resource responsible for serving it.
The exact resource may be:
- a cached response
- a static deployment asset
- an Easel Function
- an external origin reached through a rewrite
You do not need to manage certificates between Easel’s delivery layer and Easel-managed application resources.
For external origins, configure HTTPS on the origin and validate the origin certificate whenever supported.
External origins
When a rewrite forwards a request to an external service, prefer an HTTPS origin URL:
Avoid forwarding sensitive requests to an unencrypted HTTP origin.
When the origin should not be publicly accessible, use an authentication mechanism such as a secret request header or another supported origin-access control.
Do not rely only on obscuring the origin hostname.
Local development
Local framework development servers may use HTTP by default:
This is separate from deployed Easel environments, which use HTTPS.
Some browser features require a secure context but treat localhost as secure
for development purposes.
Test the deployed preview URL when validating:
- secure cookies
- HTTPS redirects
- certificate behavior
- mixed-content warnings
- Content Security Policy
- third-party OAuth callbacks
- production domain handling
Mixed content
A page served over HTTPS should not load active resources over HTTP.
For example, this can be blocked by browsers:
Use HTTPS for scripts, stylesheets, fonts, API requests, images, and embedded content whenever available.
Mixed-content errors appear in the browser developer console and are not caused by certificate provisioning for the page itself.
Verifying HTTPS
Use a browser or curl to inspect the connection and response:
A working domain should return an HTTPS response without a certificate error.
To inspect the HTTP redirect:
The response should redirect to the HTTPS URL.
You can also inspect the certificate with OpenSSL:
The -servername option ensures that the hostname is included during TLS
negotiation.
Troubleshooting
The domain is waiting for DNS
Confirm that:
- the hostname uses the exact DNS records shown by Easel
- conflicting records have been removed
- the record is configured on the authoritative DNS provider
- a DNS proxy is not hiding the expected value
- enough time has passed for the DNS change to propagate
Do not add duplicate A, AAAA, or CNAME records unless the Easel configuration explicitly requires them.
The certificate is still provisioning
Confirm that the domain has completed DNS verification.
Also check for:
- restrictive CAA records
- conflicting records for the hostname
- an upstream proxy
- DNSSEC configuration errors
- a recent domain transfer or nameserver change
- certificate-authority rate limits
If the domain status reports a configuration error, correct the underlying DNS issue before retrying provisioning.
The browser shows a certificate warning
Check that:
- the browser is opening the exact hostname configured in Easel
- the hostname points to the correct Easel project
- certificate provisioning is complete
- an upstream proxy is not serving a different certificate
- the local network or security software is not intercepting TLS
A certificate for example.com does not automatically validate an unrelated
hostname such as internal.example.com.
HTTP does not redirect to HTTPS
Confirm that the hostname is active and associated with the project.
Also check for a custom redirect or upstream proxy that intercepts the HTTP request before it reaches Easel.
The site redirects repeatedly
Redirect loops commonly occur when both Easel and an upstream proxy independently force HTTPS while disagreeing about the original request protocol.
Configure the upstream proxy to connect to Easel over HTTPS and preserve the forwarded protocol correctly.
Also inspect application-level redirects and framework configuration.
The certificate does not renew
Check that:
- the domain still points to Easel
- required DNS records remain present
- CAA records still permit issuance
- the hostname remains attached to the project
- an upstream proxy does not prevent validation
Easel renews managed certificates automatically when the domain remains correctly configured.
OAuth or authentication fails after enabling HTTPS
Update callback and origin allowlists to use the production HTTPS URL.
For example:
Also verify cookie attributes, trusted origins, redirect URIs, and proxy-header handling.