Filing and Certificate Requirements for Mini Program Launch: Both Are Mandatory

Launching a mini program requires satisfying two sets of requirements simultaneously: domain filing (ICP) (compliance) and interface certificate (technical). They are not interchangeable—even if the filing is complete, non-compliant certificates will still prevent launch.

This article explains the relationship between the two and the inspection sequence. Specific requirements are subject to regulations from competent authorities and platform rules.

Two Sets of Requirements

Handle Filing First

Filing must be initiated in advance because it has a processing cycle, unlike certificates which can be obtained instantly.

# Verify domain accessibility (indirect verification of completed filing)
curl -I https://api.example.com/ -m 10 | head -3
# If blocked due to filing-related issues, filing is incomplete

A Common Oversight: Subdomains

# List all domains used and verify each one
grep -rhoE "https://[a-zA-Z0-9.-]+" ./miniprogram --include='*.js' | sort -u

“Switching to a new interface domain” is the most common oversight—the main domain is filed, but the newly purchased domain is not.

Then Handle Certificates

# Check multiple interface domains at once
for d in api.example.com img.example.com; do
  echo "=== $d"
  openssl s_client -connect $d:443 -servername $d 
    -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'
  openssl s_client -connect $d:443 -servername $d </dev/null 2>/dev/null 
    | openssl x509 -noout -enddate
done

Configuration After Both Are Satisfied

1. Configure request legitimate domains in the official public platform
2. Ensure the development tool has disabled “Do Not Verify”
3. Test on real devices (one iOS and one Android)

Configuration Key Points:
- Enter only the domain name, without port or path
- Port is fixed at 443
- IP addresses are not supported
- Changes take effect only after republishing

Suggested Sequence

Recommended Timeline:
① Determine interface domains (planning phase; keep them minimal and scalable)
② Submit filing            ← Longest cycle, start first
③ Deploy certificates (can run parallel to filing)
④ Configure legitimate domains after filing approval
⑤ Real-device testing
⑥ Submit for review

Filing must start first as it is the only step with a waiting period. Certificates can be obtained quickly and do not need to wait.

Synchronize During Changes

# Re-verify after switching domains
curl -I https://new-domain/ -m 10 | head -3
openssl s_client -connect new-domain:443 -servername new-domain 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

Decision Tree

Preparation for Mini Program Launch
├─ Filing (Start first, long cycle)
│  ├─ Interface domain must be filed
│  ├─ New main domain → Must also be filed      ← Most easily missed
│  └─ Real-name info must match the entity
├─ Certificate (Can run parallel)
│  ├─ Valid + Complete Chain + TLS 1.2+
│  ├─ Domain Match + Not Self-Signed
│  └─ Add expiration monitoring
├─ Configuration
│  ├─ Request legitimate domains (domain only, port 443)
│  └─ Retest after disabling "Do Not Verify" in dev tools
└─ Post-Change
   └─ Re-verify when changing domain/certificate/server

Scenario Analysis: Mini Program Review Rejected Due to Missing Filing Info

Symptom: A mini program’s certificates, domains, and interfaces are configured correctly per HTTPS requirements,
yet the submission is rejected due to incomplete domain qualification information.

1. Identify which checkpoint failed →
   The transport layer check passed; the bottleneck is domain qualifications.
   These are completely independent requirements; passing one does not imply the other is met.
2. Verify if this specific domain completed the process →
   Often, filing is attached to another domain, while the dedicated interface domain was not filed separately.
3. Determine the relationship with the filed domain →
   Direct pointing vs. being a subdomain affects recognition levels differently.
4. Re-check consistency after remediation →
   The filing entity, domain real-name registration, and actual service provider must all match.
5. Do not ignore platform-side registration →
   In some cases, registration on the corresponding platform is also required; completing just one side is insufficient.
6. Run a full checklist before resubmission →
   Separate verification of qualifications and transport layer requirements; both must pass.

# Transport Layer Section (Already passed, but re-confirm before resubmission)
for h in api.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

# Verify actual DNS resolution matches the provider
dig +short example.com A
dig +short example.com NS

# Standard ports are mandatory; custom ports are not accepted
curl -sS -o /dev/null -w '%{http_code}n' https://api.example.com/

Root Cause: Confusing “technical conditions met” with “ready for launch”.
Qualification requirements and transport layer requirements are two independent lines;
no matter how standard the latter is configured, it cannot replace the former.

Two Key Takeaways:

• Review includes two independent lines: Qualifications + Transport Layer.
  If qualifications are missing, even perfect transport configuration will result in rejection, often with vague error messages.
• Dedicated interface domains are easily overlooked.
  Having qualifications for the main domain does not automatically extend to other domains under it.

Combination Matrix: Filing Status vs. Certificate Status

The purpose of this matrix is to separate the diagnosis of these two types of issues.
When interface requests fail, the most common misjudgment is focusing solely on certificates (due to explicit errors),
while the actual cause might be incomplete filing—both cause request failures, but the troubleshooting directions are entirely different.

# 1. Confirm domain resolution and connectivity (exclude filing/blocking issues)
dig +short domain
curl -sS -o /dev/null -w '%{http_code}n' https://domain/

# 2. Strictly validate certificate chain (return code must be 0)
echo | openssl s_client -connect domain:443 -servername domain -verify_return_error 2>&1 
  | grep -E 'Verify return code'

# 3. Confirm certificate covers the actual domain in use
echo | openssl s_client -connect domain:443 -servername domain 2>/dev/null 
  | openssl x509 -noout -ext subjectAltName

# 4. Confirm TLS version is not lower than 1.2
echo | openssl s_client -connect domain:443 -servername domain -tls1_2 2>&1 | grep -E 'Protocol'

Following steps 1→4 allows you to isolate four categories of issues: “Resolution/Filing”, “Certificate Chain”, “Domain Coverage”, and “Protocol Version”.
The order matters: If the domain cannot be resolved or access is blocked,
the results of subsequent certificate checks are meaningless.

Pre-Launch Synchronization Checklist

1. Filing completed and consistent with reality: Entity, domain, and access info.
2. Certificate covers all actual domains: Including interface domains and subdomains.
3. Certificate chain is complete: Verified via strict check returning code 0.
4. Protocol version meets requirements: Not lower than 1.2.
5. Renewal is monitored: Alerts received before expiration.

Item 5 is often overlooked, yet it determines how long items 1-4 remain valid.
Certificates have validity periods, and filing info changes—
one-time compliance does not guarantee long-term adherence; integrating “synchronized checks during changes” into the workflow closes the loop.

8 Common Pitfalls

1. Filing only, ignoring certificates: Both are required.
2. New domain without filing: Most commonly missed.
3. Incomplete certificate chain: Masked by browser compatibility.
4. Using self-signed certificates: Not trusted.
5. Legitimate domains include ports or paths: Configuration invalid.
6. Testing without disabling “Do Not Verify”: Issues ignored.
7. Switching servers without confirming filing access: May cause blocking.
8. No monitoring for certificate expiration: Expiry discovered post-launch causes trouble.

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

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided for reference only, 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