What is a Guomi Certificate: Scenarios, Requirements, and Deployment Considerations

A Guomi certificate refers to a certificate that uses national commercial cryptographic algorithms. The most typical example is the certificate based on the SM2 elliptic curve algorithm (paired with the SM3 hash algorithm). It operates as a separate system from standard certificates (RSA/ECC).

This article outlines its characteristics, applicable scenarios, and key considerations for deployment. Please note that specific requirements and compliance standards should be determined by relevant authorities and industry regulations.

Differences from Common Certificates

A Key Feature: Dual Certificates

In the Guomi system, signing and encryption use different certificates:

This differs from the RSA model where “one certificate does it all.” Deployment requires configuring two certificates. This is the most common source of errors in Guomi deployments—handshakes will fail if only one certificate is configured out of habit from RSA setups.

When to Consider Using Guomi

Important Reminder: Not all websites need Guomi certificates. Standard corporate websites and content sites can use regular certificates. The decision should be based on compliance requirements or explicit client mandates, not because “Guomi is more advanced.”

One Thing to Confirm Before Deployment

Does the client side (browser/client) support Guomi?

This is the biggest practical constraint for Guomi deployment:

• Standard browsers usually do not support the SM2 algorithm
• If you switch your site directly to Guomi certificates, regular users will be unable to access it

# Verify what algorithm the site is currently using
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -text | grep -iE 'public key algorithm|signature algorithm'

# Typical output:
#   Public Key Algorithm: id-ecPublicKey / rsaEncryption
#   In Guomi scenarios, SM2-related identifiers will appear (requires a Guomi-supported openssl to parse correctly)

The core of dual certificate deployment is “negotiation”: Clients supporting Guomi use Guomi cipher suites, while those that don’t fall back to standard suites. This satisfies compliance without affecting regular users.

Deployment Considerations

# Two types of verification are mandatory after deployment
# 1. Ensure Guomi-supporting clients can access normally (using Guomi suite)
# 2. Ensure standard browsers can access normally (falling back to standard suite)
curl -I https://example.com/

Management When Coexisting with Standard Certificates

# Both sets of certificates must be included in expiry monitoring
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -dates
# Note: This command shows the certificate actually used after negotiation

Expiry monitoring must cover all certificates, not just one. Since different clients use different certificates, the expiration of any single certificate will impact its corresponding user group.

Decision Tree

Should I use Guomi certificates?
├─ Is there a clear compliance requirement?
│  ├─ Yes (Government/Finance/MLPS Crypto Assessment) → Required
│  └─ No → Standard certificates suffice; no need to pursue Guomi
├─ Do clients support it?
│  ├─ Internal systems, controllable clients → Can use Guomi only
│  └─ Public-facing → Must deploy dual certificates (otherwise public users cannot access)
├─ Key Deployment Points
│  ├─ Configure both certificates (Signature + Encryption)
│  ├─ Web server must support Guomi
│  └─ Certificate chain must be complete
└─ Verification
   ├─ Guomi-supporting clients can access
   ├─ Standard browsers can access      ← Most easily overlooked
   └─ Monitor expiry for both sets of certificates

Scenario Walkthrough: Why Regular Users Might Lose Access After Switching to Guomi

Phenomenon: Guomi certificates were deployed to meet compliance requirements.
Internal checks according to regulations showed everything was normal, and the compliance conclusion was obtained.
However, feedback started coming in that regular browsers were experiencing issues accessing the site.

1. First, distinguish whether the two types of users are taking the same path →
   Guomi-supporting clients use the Guomi channel, while non-supporting ones fall back to standard certificates.
   Both paths must be verified separately.
2. Only the compliance side was verified, ignoring the fallback path →
   This is exactly the problem: regular users are traversing the fallback path.
3. Verify if the fallback path works using standard methods → Result: Handshake failure,
   indicating a configuration issue on the standard side.
4. Confirm if both sets of certificates are valid and issued →
   Dual certificate operations involve twice the workload; it’s easy to maintain only one set by mistake.
5. Fix the fallback path configuration → Adjust settings so non-Guomi clients can negotiate normally.
6. Test each type of client once → Stop testing only the type you care about.

# Fallback path (this is what regular users take)
echo | openssl s_client -connect example.com:443 -servername example.com 
  -verify_return_error 2>&1 | grep -E 'Verify return code|Protocol|Cipher'

# Force specify version to check again
echo | openssl s_client -connect example.com:443 -servername example.com -tls1_2 2>&1 
  | grep -E 'Protocol|Cipher'

# Check how many certificates the server actually issued (number increases when both sets coexist)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | grep -c 'BEGIN CERTIFICATE'

Root Cause: Only the side required for compliance was verified,
while ignoring the fallback path taken by the vast majority of regular clients.

Two points worth remembering:

• Dual certificate deployment requires verifying both paths separately, not just the compliance path.
  Regular users traverse the fallback path, which is easily overlooked.
• Two sets of certificates mean two sets of operations.
  Issuance, deployment, and expiry monitoring must be done for each. Missing one set will manifest as “partial user anomalies.”

Comparison of Dual Certificate Deployment

“Dual certificates” is the most critical concept to understand in Guomi deployment:
It is not replacing standard certificates with Guomi, but running both in parallel.
Guomi-supporting clients use Guomi suites, while non-supporting clients fall back to standard certificates.
The direct consequence is doubled operational workload—both sets of certificates require issuance, deployment, monitoring, and renewal.

# After deployment, verify both sets are usable separately
# Standard Suite
echo | openssl s_client -connect example.com:443 -servername example.com 
  -verify_return_error 2>&1 | grep -E 'Verify return code|Protocol|Cipher'

# Force TLS 1.2 to check again (confirm fallback path is normal)
echo | openssl s_client -connect example.com:443 -servername example.com -tls1_2 2>&1 
  | grep -E 'Protocol|Cipher'

# Check how many certificates the server actually issued (number increases with dual certificates)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
  | grep -c 'BEGIN CERTIFICATE'

A common pitfall during the verification phase: Testing only Guomi clients and ignoring the fallback path.
Regular users’ browsers take the fallback path. If it is misconfigured,
the symptom is “compliance check passed, but regular users cannot access.”
Therefore, both sets must be verified independently; checking only one set is insufficient.

Criteria for Deciding Whether to Adopt Guomi

1. Is there a clear compliance requirement?: If there is no explicit requirement, do not adopt proactively—operational costs are real.
2. Are clients controllable?: Guomi only adds value if visitors use specific, controllable clients.
3. Does middleware support it?: Web services and gateways must be able to handle both sets of certificates simultaneously.
4. Can renewals be managed?: Two sets of certificates mean two expiry dates; both must be included in monitoring.

Among these four conditions, item #1 is the prerequisite.
Guomi certificates solve compliance issues, not security issues—
understanding this prevents introducing double the operational complexity just for the sake of being “more secure.”

8 Common Pitfalls

1. Adopting Guomi without compliance requirements: Increases complexity with no benefit.
2. Configuring only one certificate: Guomi requires dual certificates (Signature + Encryption).
3. Deploying Guomi-only for public-facing sites: Regular users will be unable to access.
4. Failing to test standard browsers: Only tested environments supporting Guomi.
5. Monitoring expiry for only one set of certificates: Expiration of the other set affects another batch of users.
6. Web server does not support Guomi: Requires corresponding modules or versions.
7. Ignoring certificate chain integrity: Guomi also requires a complete chain.
8. Switching because Guomi is perceived as “more secure”: The decision basis should be compliance requirements.

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 operation and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and competitors, provided here for reference only, not fictional tickets from this site):

2****0 Rating: 5.0 stars 2023-11-06 18:05

1****1 Rating: 5.0 stars 2023-11-13 22:09 s****2 Rating: 5.0 stars 2023-02-28 11:04 a****7 Rating: 5.0 stars 2023-02-15 09:09 Jin****8 Rating: 5.0 stars 2020-06-17 10:25 Fast configuration. Timely service. Thank you 1

Xi****Gu Rating: 5.0 stars 2021-11-16 15:13 Handled well f****7 Rating: 5.0 stars 2018-11-20 14:04