Guomi HTTPS Deployment Guide: TLCP Protocol, SM2 Dual Certificates, and nginx with Tongsuo

Why regular HTTPS fails the assessment

Let's Encrypt, DigiCert and the usual certificates run an international algorithm stack: RSA/ECDHE key exchange, SHA-256 digests. The Chinese commercial-cryptography application security assessment (miping) and MLPS level-3 crypto requirements mandate national algorithms on the transport path — which cascades into three demands: SM2 certificates, TLCP handshakes, SM3 digests. Walk into an assessment with an RSA certificate and that line item loses points outright.

TLCP: the guomi TLS

TLCP (Transport Layer Cryptographic Protocol, GB/T 38636-2020) is not a TLS cipher suite — it is an independent protocol line, the guomi counterpart to TLS 1.2. It runs parallel to RFC 8998 (which binds SM2/SM3/SM4 into TLS 1.3 for IETF interop): the former is what domestic compliance asks for, the latter targets international interoperability. Assessments recognize TLCP.

Dual certificates: signing + encryption

The most common conceptual trap in TLCP is two certificates:

Certificate authorities (CFCA, iTrustAsia and others) issue both together. Ordering is sensitive in nginx — ssl_certificate lists the signing pair first, then the encryption pair; swap them and the handshake fails.

Building a TLCP-capable nginx with Tongsuo

OpenSSL mainline has no TLCP; the community standard is Tongsuo (formerly BabaSSL), Ant Group's OpenSSL branch. The mainline flow:

# 1. Build Tongsuo (enable-ntls is the key switch)
./config enable-ntls
make && make install

# 2. Point nginx at Tongsuo with ntls
./configure --with-openssl=../tongsuo \
  --with-openssl-opt="enable-ntls no-shared"
make && make install

The essential nginx lines:

ssl_certificate      sign.crt;    # signing certificate
ssl_certificate_key  sign.key;
ssl_certificate      enc.crt;     # encryption certificate (second pair)
ssl_certificate_key  enc.key;
ssl_ciphers ECC-SM2-SM4-SM3:ECC-SM2-SM4-SM3-SHA256;

With the enable_ntls on; directive (newer Tongsuo nginx patches), one port 443 carries both guomi dual certificates and an international certificate — guomi browsers negotiate TLCP while regular Chrome negotiates TLS 1.2/1.3. Dual stack, no second port.

The browser reality

Stock Chrome, Firefox and Safari still cannot speak TLCP. Clients that complete the guomi handshake:

• 360 Secure Browser (guomi mode; huge in government/enterprise procurement)
• MeSignEdge, Lotus Browser (dedicated guomi browsers)
• Java: BouncyCastle, or Tongsuo via JNI — the most mature path for server-to-server

This dictates the typical topology: a dual-stack entry point for government/enterprise traffic, an international-certificate entry for the general public — coexistence, not replacement.

Three failure modes assessors hit

1. Certificate order swapped: guomi branch works with curl, browsers report handshake failure — check the dual-certificate order first.
2. Suite-name mismatch: server enables only ECC-SM2-SM4-SM3 while the client negotiates ECC-SM4-SM3-SHA256 — align the lists on both ends.
3. Certificates swapped but protocol unchanged: SM2 certs on an international TLS handshake still count as "algorithms not guomi end-to-end" — TLCP is an all-or-nothing switch.

Implementer's note

Our guomi tool family (SM2 encrypt/decrypt, SM3 digest, SM4 encrypt/decrypt) runs entirely in the browser, and one detail from this article is unavoidable there: the Web Crypto API ships no national algorithms, so the implementation is pure JavaScript via sm-crypto — which is why those pages target small payloads and integration testing rather than bulk encryption. The standard SM2 ciphertext order (C1C3C2) versus legacy (C1C2C3) is the single most frequent pitfall we see in interop scenarios; key formats likewise: an uncompressed public key is 130 hex chars with an 04 prefix, a different representation from the DER inside certificates. For how the standard numbers map across generations (GM/T, GB/T, ISO/IEC), we keep a dedicated quick-reference table.