HTTPS Best Practices for Mini Program and Backend APIs: Domain Planning, Certificates, and Key Considerations

For mini program interfaces, most issues are not about “not knowing how to configure,” but rather poor initial planning, which forces configuration changes every time a new domain is added—and the number of allowed configuration changes is limited.

This article outlines several practices to avoid trouble during the early stages, following the order of “Domain Planning → Certificate → Configuration → Long-term Maintenance.”

1. Domain Planning: Think Before You Act

Core Principle: Minimize the number of domains that need to be registered.

Recommended Structure:
  api.example.com     All business APIs
  static.example.com  Static resources like images (optional; can also be merged into api)

“Adding a subdomain for every new feature” is the most common planning mistake. It leads to: configuration changes for every addition, re-signing certificates, and continuously rising maintenance costs.

2. Certificate Selection

# Verify which domains the certificate covers (check SAN)
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

# A wildcard certificate should show something like: DNS:*.example.com

Selecting a wildcard certificate during the planning phase avoids the hassle of “re-signing certificates when adding subdomains later.” The cost difference is minimal, but it saves significant repetitive work downstream.

Note: Wildcard certificates only cover one level of subdomains. *.example.com covers api.example.com, but does NOT cover a.b.example.com.

3. Server-Side Configuration Essentials

server {
    listen 443 ssl http2;
    server_name api.example.com;

    # ① Must use fullchain
    ssl_certificate     /etc/nginx/ssl/api/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/api/privkey.pem;

    # ② Only allow TLS 1.2 / 1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # ③ Ciphers supporting forward secrecy
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 30s;      # ④ Timeout must be set
    }
}

# Verification (must return 0)
openssl s_client -connect api.example.com:443 -servername api.example.com 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

4. Content and Resources

• Data returned by APIs must not contain HTTP resources
• Static resources like images must also use HTTPS
• Do not use self-signed certificates

# Check if the API response contains any http addresses
curl -s https://api.example.com/list | grep -oE 'http://[^"]+' | sort -u

5. CDN and Origin Fetching

If there is a CDN in front of the API:

• Origin fetching must also use HTTPS to avoid protocol mismatch issues causing redirects
• API responses should NOT be cached (results are user-specific)
• The CDN’s certificate must also be valid and have a complete chain

# Verify the CDN node's certificate
curl -I https://api.example.com/ | grep -iE 'server|x-cache'
openssl s_client -connect api.example.com:443 -servername api.example.com 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

6. Long-term Maintenance

# Check certificate expiry (include in routine inspections)
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -enddate

The last point, “keeping old API versions during upgrades,” is very practical: Older versions of mini program clients won’t update immediately. Changing the API structure abruptly renders these users unable to use the service.

Decision Tree

API HTTPS Practice
├─ Domain Planning (Most valuable in early stages)
│  ├─ Minimize domains (unified API domain)
│  └─ Reserve for expansion → Choose wildcard certificates
├─ Certificates
│  ├─ Multiple subdomains → Wildcard (note: only covers one level)
│  └─ Use fullchain, not single cert
├─ Server Side
│  ├─ TLS 1.2/1.3 + Forward Secrecy Ciphers
│  └─ Timeout must be set
├─ Content
│  └─ API responses must not contain http resources
├─ CDN
│  ├─ Origin fetch must also use HTTPS
│  └─ APIs must not be cached
└─ Long Term
   ├─ Monitor certificate expiry
   └─ Keep old API versions during upgrades

Scenario Simulation: Incorrect API Domain Planning from the Start

Symptom: In the early stages of a mini program project, to save effort, the API reused the main site’s domain.
Later, as the business expanded and the API needed independent scaling or separate policy adjustments, it was found that changing one thing affected everything.

1. First, list the specific limitations caused by sharing the domain →
   Cache policies cannot be configured separately, acceleration nodes cannot be adjusted independently,
   and issues cannot be isolated separately—sharing means sharing the same rules.
2. Also consider certificate issues →
   Sharing a domain means sharing the same certificate; any change or adjustment on either end affects the other.
3. Determine the granularity of separation →
   Divide based on “frequency of change” and “isolation needs”: APIs, static resources, and admin backends should be independent.
4. Configure certificates for each separated domain →
   Good planning allows fewer certificates to cover more domains, but be mindful of coverage limits.
5. Handle list configurations synchronously during migration →
   Domain changes must be synced to the platform’s allowlist; this step is often overlooked in development environments.
6. Verify consistency on both sides → Confirm protocol, port, and chain for each domain meet requirements.

# Verify certificate coverage for each domain after separation
for h in api.example.com static.example.com www.example.com; do
  printf '%-28s ' "$h"
  echo | openssl s_client -connect $h:443 -servername $h -verify_return_error 2>&1 
    | grep -o 'Verify return code: [0-9]*'
done

# Confirm if the API domain is in the platform's allowlist
grep -rIn 'legitimate domain|request legitimate domain' /project/dir/app.json 2>/dev/null | head

# Verify protocol version and port for each
echo | openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 2>&1 
  | grep -E 'Protocol|Cipher'

Root Cause: Sharing domains initially to save effort binds cache policies, certificate management, and fault isolation together. As scale increases, the cost of adjusting each item is magnified.

Two key takeaways:

• Separate domain planning by “frequency of change”: APIs, static resources, and backends should be independent.
  The cost of sharing domains doesn’t appear initially; it explodes when you need to adjust one item independently.
• Certificates must be designed alongside domain planning.
  Good planning allows fewer certificates to cover more domains; poor planning means every change might affect unrelated services.

8 Common Pitfalls

1. One subdomain per feature: Change limits are exhausted quickly.
2. Using single-domain certificates when subdomain expansion is needed: Requires re-signing every time.
3. Assuming wildcards cover multi-level subdomains: They only cover one level.
4. Using cert instead of fullchain: Mini programs will definitely fail.
5. Not setting timeouts in proxies: Backend hangs drag down the API.
6. API responses containing http resources: Loading fails.
7. CDN origin fetch using HTTP: Protocol mismatches cause issues.
8. Not keeping old API versions during upgrades: Old clients become unusable.

Real Customer Feedback (From Similar Product Reviews and Consultations on Cloud Marketplaces)

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and peers, provided solely for reference of real feedback, not fictional tickets from this site):

a****8 Rating: 5.0 Aug 22, 2025 14:43 r****8 Rating: 5.0 May 22, 2025 15:34 t****c Rating: 5.0 Apr 18, 2025 13:58 Cai****Kang Rating: 5.0 Aug 31, 2024 12:05 2****2 Rating: 5.0 Feb 21, 2024 11:08

s****2 Rating: 5.0 Feb 28, 2023 11:04 Mai****8 Rating: 5.0 Jun 29, 2020 17:44 4****6 Rating: 5.0 Jan 07, 2019 14:56