Migrating a SaaS Platform to Full‑Site HTTPS: Principles, Resources, and Practical Considerations

HTTPS adds SSL/TLS encryption on top of HTTP, becoming the standard security protocol for modern websites. For a SaaS platform such as Youzan, enabling site‑wide HTTPS is a basic guarantee for protecting critical processes like product listings, transactions, and payments. This article explains the fundamentals of HTTPS, the resources that need to be switched, monitoring and operational steps, and common challenges.

1. Basic Principle

The HTTPS handshake adds certificate verification and encryption, solving problems such as 运营商劫持 , 中间人攻击 , 钓鱼网站 , and improving SEO.

Client sends a ClientHello containing SSL version, supported cipher suites, compression methods, and a random number (R1).

Server replies with a ServerHello that includes the selected cipher suite, compression method, session ID, digital certificate, and another random number (R2).

The client (browser) validates the server’s SSL certificate; if invalid, a warning is shown.

The client sends a ClientKeyExchange message containing the pre‑master secret (used to generate symmetric keys).

Both client and server derive a master secret from the three random numbers (R1, R2, pre‑master secret) and generate all symmetric keys for encryption and authentication.

Server performs the same derivation to obtain the master secret.

Client sends a “ChangeCipherSpec” message, after which both sides use the negotiated symmetric algorithm and keys.

Server also sends a “ChangeCipherSpec” message.

The SSL handshake ends and subsequent communication uses symmetric encryption.

2. Resources and Services Involved in the Switch

When starting the HTTPS migration, you need to inventory the following items:

Static resources deployed to CDN (JS, CSS)

Image assets

Primary domain and sub‑domains

Third‑party resources (ads, videos, etc.)

API calls that may still return HTTP URLs

External services offered by the platform

Dynamic Loading of Static Resources

<link rel="stylesheet" href="${loadStaticContent(www/css/main.min.css)}">
<script type="text/javascript" src="${loadStaticContent(www/js/main.min.js)}"></script>

Using a template method to load JS/CSS dynamically prevents hard‑coded domains. When the CDN domain changes to HTTPS, only the template needs updating.

CSS Dynamic Image Loading

.loading { background-image: image-cdn('/logo_loading.png'); }

With tools like Sass, internal images can be referenced via the CDN domain and replaced uniformly.

Old Image Issues

For legacy HTTP image URLs, scripts should re‑upload the images to an HTTPS‑enabled storage or replace the URLs programmatically.

Domain and Sub‑domain Assessment

Analyze Nginx logs (e.g., using awk) to count HTTP traffic per domain. Consider factors such as 请求量的大小 , 业务的轻重缓急 , 业务切换 HTTPS 难度 , and 各域名功能 to prioritize migration order.

Third‑Party Resources

Use HTTPS‑supported video services (e.g., Tencent Video).

Re‑host external images that lack HTTPS.

Require third‑party ad scripts to provide HTTPS endpoints.

3. Points to Note During the Switch

Relative Protocol

Replace hard‑coded http:// URLs with protocol‑relative URLs (e.g., //domain.com/img/logo.png ). This allows the same code to work over both HTTP and HTTPS, facilitating testing and rollback.

<img src="//domain.com/img/logo.png">
<script src="//www/js/libs/jquery/1.4.2/jquery.js"></script>

301 vs 302 Redirects

After all resources are switched and tested, configure Nginx to issue a 302 temporary redirect from HTTP to HTTPS for an observation period. Once stability is confirmed, change to a permanent 301 redirect.

Content‑Security‑Policy (CSP)

To prevent accidental HTTP loads on an HTTPS site, you can use either:

block-all-mixed-content – blocks all HTTP resources.

upgrade-insecure-requests – automatically upgrades HTTP requests to HTTPS, providing a more user‑friendly fallback.

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Testing Environment

While HTTP may be convenient for testing, using HTTPS in the test environment ensures parity with production, especially when relative protocols are employed.

4. Common Difficulties

Numerous front‑end and back‑end callers for the same API make it hard to locate all HTTP references.

Missing Referer headers on some pages hinder traffic source analysis; forcing HTTPS can mitigate this.

Legacy client versions that still use HTTP need to be phased out based on usage volume.

Third‑party services that only expose HTTP endpoints must be notified to upgrade within a defined deadline.

Beyond these explicit challenges, hidden issues include aligning deadlines with business owners, coordinating API upgrades, and handling complex legacy integrations. A firm migration deadline is essential to keep the HTTPS rollout on track.

In summary, this article shares practical experience from the perspective of a project leader driving a full‑site HTTPS migration: understanding the protocol, preparing resources, executing the switch, and handling obstacles. After the migration, further work such as performance tuning, monitoring mixed‑content traffic, and ensuring HTTPS availability should continue.