Guidance on provisioning for d.sni.global.fastly.net (Legacy/Non-SNI Support)

Network Services
, ,
1

Hi everyone,

I’m currently configuring a service that needs to support legacy, non-SNI clients (primarily older embedded systems and legacy Windows environments).To ensure compatibility, I need to deploy an RSA certificate as a fallback.

From what I’ve gathered, this requires provisioning onto the d.sni.global.fastly.net shared map. However, in my current TLS configuration dashboard, I only see options for the w.sni and x.sni modern maps.

Could anyone clarify if the d.sni pool is restricted to specific account tiers (e.g., Enterprise or specific Managed TLS packages)?

I’m trying to determine if this is a configuration I can enable on my current tier or if it requires a specific service entitlement from the Fastly side.

Any documentation links or insights on map-to-tier mapping would be greatly appreciated.

Thanks!

2

This is not likely to be something we’ll be able to help with in the forum. As you’ve noted this is a non-standard configuration and will require consultation with your account manager. Along with the need for ‘no SNI’ support, old clients typically also require enablement of ‘legacy’ ciphers that are not part of our standard configuration (because they are likely to be, or known to be, insecure). The lack of SNI means the requests will need to land on a dedicated offset (set of IP addresses), not a shared offset which supports other Fastly customer services, because SNI is the method used to route incoming requests on shared offsets.

Where did you find information indicating that the ‘d’ shared map would be useful in this situation?