It includes the public key, owner identity, issuing authority, serial number, and expiration date. It may also include usage details and a digital signature from the issuing authority.
A digital certificate is an electronic credential that verifies the identity of a person, organization, device, or website in digital communications. Issued by a trusted Certificate Authority (CA), it cryptographically binds a public key to a verified identity — allowing any party to confirm who they are communicating with and trust that the information has not been tampered with.
In simple terms: a digital certificate is a digital passport. It proves identity, carries verifiable information, and is issued by a recognized authority that others already trust.
Every digital certificate is a structured data file built on the X.509 international standard. Regardless of the certificate type, the core contents are consistent:
| Field | What It Means |
|
Subject |
The identity the certificate belongs to — a person, organization, server, or device |
|
Public Key |
The cryptographic key linked to the certificate holder, used to verify their signatures |
|
Issuer |
The Certificate Authority (CA) that reviewed, approved, and issued the certificate |
|
Serial Number |
A unique identifier assigned by the CA to distinguish each certificate |
|
Validity Period |
The start and expiry dates during which the certificate is considered active |
|
CA's Digital Signature |
Cryptographic proof that the CA verified and endorsed the certificate's contents |
When a browser, email client, or document platform encounters a digital certificate, it reads this data automatically — verifying the chain of trust before allowing the interaction to proceed.
Digital certificates operate within a system called Public Key Infrastructure (PKI) — a framework of trusted CAs, cryptographic key pairs, and verification protocols that makes identity validation scalable across the internet.
Here is the complete lifecycle of a digital certificate:
Step 1 — Key Pair Generation The certificate applicant generates a mathematically linked pair: a private key (kept secret, never shared) and a public key (shared openly). Data signed with the private key can only be verified using the corresponding public key.
Step 2 — Certificate Signing Request (CSR) The applicant submits a CSR to a Certificate Authority — including the public key and identity details — requesting that the CA vouch for the binding between the two.
Step 3 — Identity Verification The CA independently verifies the applicant's identity. The level of verification depends on the certificate type requested (see certificate types below).
Step 4 — Certificate Issuance Once verified, the CA digitally signs the certificate using its own private key. This signature is what allows browsers, operating systems, and applications to automatically trust certificates from that CA.
Step 5 — Deployment The certificate is deployed — on a web server, within an email client, or in an electronic signature workflow. Anyone who interacts with the certificate holder can validate it by checking the CA's signature.
Step 6 — Verification in Use At the point of interaction — opening a signed document, visiting a secure website, receiving a signed email — the software automatically checks the certificate chain, confirms the CA's signature is valid, and verifies the certificate has not expired or been revoked. This happens in milliseconds, invisibly to the end user.
Digital certificates are purpose-built. The type used depends on what needs to be verified and in what context.
SSL/TLS Certificates Secure the connection between a web browser and a web server. The padlock icon in a browser address bar indicates an active SSL/TLS certificate. It verifies that you are communicating with the legitimate server — not an impersonator — and encrypts all data in transit.
Document Signing Certificates Used to apply legally binding digital signatures to contracts, agreements, and regulated documents. A document signing certificate binds the signer's verified identity to the document at the moment of signing, creating a tamper-evident, court-admissible record. This is the certificate type most relevant to electronic signature workflows.
Code Signing Certificates Used by software developers to sign applications and executables. Confirms the software came from a verified publisher and has not been modified since it was signed — protecting users from tampered or counterfeit software.
Email Signing Certificates (S/MIME) Used with the Secure Multipurpose Internet Mail Extensions (S/MIME) protocol to sign and encrypt email messages. Allows recipients to verify sender identity and confirm the message content was not altered in transit.
Client Authentication Certificates Used to authenticate users or devices accessing secure systems and networks. Common in zero-trust architectures and enterprise VPN environments where password-only authentication is insufficient.
A Certificate Authority (CA) is a trusted third-party organization responsible for verifying applicant identity and issuing certificates. CAs are the trust anchors of the PKI system. Operating systems and browsers maintain a built-in list of trusted root CAs — any certificate issued by a CA on that list is automatically recognized.
CAs issue certificates at three validation levels, each with a different degree of identity scrutiny:
Domain Validation (DV) Confirms only that the applicant controls the domain name. Fast to obtain; lowest assurance. Appropriate for basic HTTPS on low-risk websites.
Organization Validation (OV) Verifies both domain control and the legal existence of the organization. Medium assurance. Appropriate for business-facing services where identity matters.
Extended Validation (EV) Involves rigorous verification of the organization's legal, physical, and operational existence. Highest assurance. Used in banking, legal services, and enterprise environments where trust is critical.
For regulated-industry document signing — particularly under eIDAS (EU) — certificates must be issued by an accredited qualified trust service provider to meet qualified electronic signature (QES) standards.
Yes — in most jurisdictions, digital signatures backed by valid certificates are legally binding and court-admissible. The applicable standard depends on the legal framework in use:
United States (ESIGN Act / UETA) Electronically signed documents are legally enforceable when the parties intended to sign and the signature can be attributed to the signer. Certificate-backed signatures provide the strongest evidentiary attribution.
European Union (eIDAS Regulation) Defines three tiers of electronic signature. Qualified Electronic Signatures (QES) — backed by qualified certificates from accredited CAs — carry the same legal weight as handwritten signatures across all EU member states.
United Kingdom (Electronic Communications Act 2000) Digital signatures backed by valid certificates are recognized as valid evidence of identity and intent.
Healthcare and Life Sciences (HIPAA / 21 CFR Part 11) Certificate-backed digital signatures satisfy FDA and HIPAA requirements for electronic records in regulated clinical and pharmaceutical environments.
For cross-border agreements, regulated submissions, or any scenario where the signature may be challenged in litigation, certificate-backed signing is the appropriate standard.
Verification is typically automatic — handled by software at the point of interaction. Understanding the process is useful for compliance, audit, and troubleshooting.
On a signed document: Open the document in a PDF reader (such as Adobe Acrobat) and navigate to the signature panel. The reader displays the signer's certificate details — issuing CA, validity period, and whether the document has been altered since signing. A valid certificate with no modifications shows a confirmed signature status.
On a website: Click the padlock icon in the browser address bar and select certificate details. The browser shows the certificate's subject, issuing CA, and validity period, and displays the full certificate chain back to the trusted root CA.
For revocation status: Applications check revocation using OCSP (Online Certificate Status Protocol) or by downloading a Certificate Revocation List (CRL) from the CA. A revoked certificate will be rejected, even if it has not yet expired.
Digital certificates introduce management complexity, particularly at scale. Awareness of common failure points helps organizations avoid avoidable risks.
Certificate expiration Certificates have finite validity periods. Untracked expiry causes website warnings, signature validation failures, and compliance gaps. Automated alerting and renewal workflows are essential in any organization managing multiple certificates.
Private key compromise If a private key is exposed or stolen, the corresponding certificate must be revoked immediately. The attacker could otherwise impersonate the certificate holder or forge signatures. Key storage in Hardware Security Modules (HSMs) significantly reduces this risk.
Revocation checking gaps Not all applications consistently check revocation status. A revoked certificate that passes unchecked may still appear valid. Organizations should verify that their signing and verification systems perform active revocation checks.
User adoption friction Requiring individual signers to obtain and manage their own certificates creates technical barriers. Enterprise signing platforms address this by managing certificates on behalf of users, making certificate-level assurance accessible without requiring signers to handle the underlying infrastructure.
RSign, RPost's enterprise electronic signature platform, builds certificate-level assurance into every signing transaction — without adding complexity for senders or signers.
The RSign eSign Certificate
At the core of RSign's approach is its patented eSign Certificate — a self-authenticating, cryptographically sealed record generated at the completion of each signing transaction. It contains:
Any post-signature alteration to the document invalidates this binding — making tampering immediately detectable.
Legal Recognition
RSign eSign Certificates are recognized as legally valid and court-admissible under the US ESIGN Act and UETA (all 50 states), the EU eIDAS Regulation (Simple, Advanced, and Qualified signatures), the UK Electronic Communications Act 2000, HIPAA, 21 CFR Part 11, and GDPR.
Certificate Management in Practice
RSign handles the certificate infrastructure on behalf of users:
Signer identity is further reinforced through multi-factor authentication (SMS OTP), Microsoft Azure AD SSO, and knowledge-based authentication — all recorded in the electronic signature audit trail as part of the eSign Certificate.
It includes the public key, owner identity, issuing authority, serial number, and expiration date. It may also include usage details and a digital signature from the issuing authority.
Certificates are issued by Certificate Authorities (CAs). These are trusted entities that verify identities before issuing certificates.
Yes, in many regions. Laws like ESIGN and eIDAS recognize digital signatures backed by certificates as legally valid when properly implemented.
Browsers and software automatically check validity by verifying the issuing authority, expiration date, and whether it’s been revoked.
It can be revoked by the issuing authority. Systems checking the certificate will then reject it, preventing misuse.
