หมายเลขดิจิตอลและสายความเชื่อถือการลงนาม

The top of the trust chain. Root CA certificates are self-signed and pre-installed in operating systems and browsers. They are the ultimate source of trust — if you trust the root, you trust everything issued under it.

Root CAs rarely issue end-user certificates directly. Instead, they issue intermediate CA certificates, which in turn issue end-user certificates. This adds a layer of security — if an intermediate is compromised, only it needs to be revoked, not the root.

The certificate issued to a person or organisation for signing or authentication. When validating a signature, the verifier follows the chain: end-user → intermediate → root. If all links are valid and the root is trusted, the signature is trusted.

RSA 2048-bit is the minimum accepted by NIST SP 800-131A for signatures beyond 2030. ECC P-256 provides equivalent security with smaller key sizes (256-bit) and faster signing — 3x faster than RSA 2048. eSign.AI uses ECC P-256 by default and RSA 3072 for regulatory environments that require RSA.

CA/Browser Forum baseline: 398 days max for TLS certificates. For eSignature certificates: EU QTSP certificates are typically valid 2-5 years. China CA certificates: 3 years. Singapore Netrust: 2-3 years. After expiry, the signature remains valid but LTV data must be embedded for independent verification.

Root CA → Intermediate CA → Signing certificate is the standard 3-level chain. Some QTSPs use 4 levels (Root → Country → CA → Signing). Verification requires all intermediate certificates to be available — if a chain certificate is missing, the signature shows as "not verified" in Adobe Reader.

OCSP (Online Certificate Status Protocol) checks revocation in real-time, typically 50-200 ms latency. CRL (Certificate Revocation List) downloads the full list (50 KB - 5 MB) and caches it. PAdES B-LT embeds both OCSP responses and CRLs at signing time, ensuring verification works even if the CA goes offline.

Certificate issuance follows a standard flow: the subscriber submits an application with identity documents, the CA verifies identity (in person, via eKYC, or through a trusted agent), the CA issues the certificate with a defined validity period, and the subscriber receives a private key stored on a secure medium (HSM, token, or cloud key vault). Under China's Electronic Signature Law Article 15, CA providers must obtain a licence from the SCA. Under eIDAS, QTSPs must be listed on the EU Trusted List and audited against ETSI standards.

Certificates may be revoked before expiry due to key compromise, CA compromise, subscriber identity fraud, or organisational change (merger, dissolution). Revocation information is published via CRL (Certificate Revocation List) and/or OCSP (Online Certificate Status Protocol). PAdES B-LT and B-LTA signatures embed revocation data at signing time, so verification works even years later when the CA may no longer operate. Without embedded revocation data, a signature becomes unverifiable after certificate expiry — a common failure in legacy eSignature implementations.

Enterprise signing programmes should plan certificate renewal 60-90 days before expiry. For sealed documents (regulatory filings, compliance certificates), renewal must happen before expiry to maintain a continuous chain of trust. China's SCA-licensed CAs typically issue 3-year certificates; EU QTSPs issue 2-5 year certificates. eSign.AI manages renewal automatically for cloud-based certificates and sends reminders for subscriber-managed certificates.