Pre-Launch Checklist for Mini Program Certificates and Domains: Verify Before Submission

Most rejections or post-launch issues with mini programs stem from domain names and certificates. These problems share a common trait: they cannot be detected in the development tools—because the “Do not verify valid domain names” setting allows everything to pass.

Therefore, before launching, use this checklist to verify each item under conditions as close to real-world as possible.

Self-Inspection Checklist

Step-by-Step Verification

① First, Disable “Do Not Verify”

This is the prerequisite for the entire checklist. If you do not disable this option, all subsequent checks are meaningless—because the tool will ignore all errors.

1. WeChat Developer Tools → Details → Local Settings
2. Uncheck “Do not verify valid domain names, web-view, TLS versions, and HTTPS certificates”
3. Recompile and test all APIs

② Ensure Complete Domain List

# Extract all requested domains from code to ensure none are missed
grep -rhoE "https://[a-zA-Z0-9.-]+" ./miniprogram --include='*.js' | sort -u

Common omissions: image/file domains, statistics SDK domains, third-party API domains. These are often not in the main API list but still need to be registered.

③ Certificate Check (Server-Side)

# Validity period
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -dates

# Chain completeness (Critical: 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'

# TLS Version
openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 </dev/null

# Domain Match (Check SAN, not CN)
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

④ Check Mixed Content

# Check if API responses contain http resources
curl -s https://api.example.com/list | grep -oE 'http://[^"]+' | sort -u

# Image URLs in pages (web-view scenario)
curl -s https://example.com/page | grep -oE 'src="http://[^"]+"'

⑤ Real Device Testing

Simulators and dev tools cannot replace real devices. Test at least one iOS and one Android device, as certificate requirements differ between platforms.

• Use the Trial Version (not the Dev Version)
• Cover main workflows, not just the homepage
• Pay attention to performance in weak network environments

⑥ Certificate Expiration Monitoring

# Continue checking after launch (add to routine inspections)
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -enddate

This item is often mistakenly thought to be irrelevant before launch, yet it is precisely the issue that surfaces after launch. A certificate being valid during review does not guarantee it remains valid three months later.

Post-Launch Actions

• Configuration changes require republishing to take effect: Saving without publishing means no change
• There is a limit on domain configuration modifications: Plan carefully to fill all fields at once and avoid frequent changes
• Keep a rollback version available: Allows quick restoration if issues arise

Decision Tree

Pre-Launch Self-Inspection
├─ Prerequisite: Disable "Do not verify valid domain names"
├─ Domain Layer
│  ├─ Are all request domains registered (including images/SDKs/third-parties)?
│  ├─ Is the domain ICP filed?
│  └─ Use only domain names, no ports or paths
├─ Certificate Layer
│  ├─ Chain is complete (-verify_return_error returns 0)
│  ├─ TLS ≥ 1.2
│  ├─ Domain matches (Check SAN)
│  └─ Not self-signed
├─ Content Layer
│  └─ No http resources in APIs or pages
├─ Real Devices
│  └─ One iOS + One Android, run main flows using Trial Version
└─ Post-Launch
   ├─ Monitor certificate expiration
   └─ Republish after changing configurations

Scenario Simulation: Rejection Due to Domain Not in List

Symptom: The mini program submission was rejected because “the domain is not in the allowed list.” Developers have added all conceivable domains, yet it is still rejected.

1. Don’t guess; list all actual requests → Capture all requests in a real runtime environment. Often, the actual number of requests exceeds expectations (statistics, images, fonts, shared API domains, etc.).
2. Compare line by line against the list → Identify overlooked addresses that appear to be resources but count as requests, as well as third-party service endpoints.
3. Confirm protocol and port requirements for each → Must use standard encrypted ports. Custom ports and self-signed certificates are not accepted.
4. Validate certificate compliance individually → Strictly check chain completeness, domain coverage, and protocol version.
5. Update the list and re-verify → Run all functional paths completely on real devices with official configurations, not just the main flow.
6. Add these steps to the launch checklist permanently → For future iterations involving domain changes, repeat this process.

# List all requests in the real environment (do not rely on memory)
# Group by domain in Developer Tools Network Panel and export for comparison

# Validate certificates one by one: Check all three items
for h in api.example.com img.example.com static.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

# Must be standard 443; custom ports are not accepted
for h in api.example.com; do
  curl -sS -o /dev/null -w "%{http_code}n" https://$h/
done

# Protocol version must meet standards
echo | openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_2 2>&1 
  | grep -E 'Protocol|Cipher'

Root Cause: The actual number of requests exceeds what is “remembered,” so the list does not cover everything. Such omissions do not surface in the development environment but become apparent in the strict review environment.

Two Key Takeaways:

• Configure the domain list based on “actually captured requests,” not memory. Third-party services, static resources, and statistics endpoints are easily missed, yet they are also validated.
• Each item must pass three checks: standard port, complete certificate chain, and compliant protocol version. Failure in any single check leads to the same rejection. Individual verification is far more efficient than repeated guessing.

8 Common Pitfalls

1. Submitting for review without disabling “Do Not Verify”: All issues are ignored.
2. Omitting third-party domains: Statistics SDKs and image CDNs are frequently forgotten.
3. Incomplete certificate chain: Works in browsers, fails in mini programs.
4. Testing only simulators, not real devices: Requirements differ between platforms.
5. Testing only iOS or only Android: You must test both.
6. Ignoring certificate expiration: Expiring after launch causes greater trouble.
7. Changing configurations without republishing: Saves but does not take effect.
8. Frequently modifying domain configurations: Subject to modification limits.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations and maintenance services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud cloud markets (service providers include our store and peers, provided here for reference only, not fictional tickets from this site):

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

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