A digital signature is the cryptographic result attached to an electronic record: it helps verify that the record was signed with a particular private key and whether it changed after signing. A digital certificate is the CA-signed credential linking the corresponding public key to a verified subscriber or system. The signature is the act; the certificate supports identity and trust. Neither alone proves commercial authority or factual truth. Use the exact certificate type or approved eSign route required by the relying application.
The most expensive mistake is buying a certificate before identifying the relying application. A valid certificate can still be wrong for a tender, filing, website, software release or encrypted exchange because its purpose, key usage, subscriber identity or storage model does not match the transaction.
Start with the act you need to perform. Signing proves a relationship between a private key and a specific electronic record. A certificate helps others trust the corresponding public key. A portal then applies its own acceptance rules. Keeping these three layers separate makes procurement, verification and incident response much clearer.
The core difference in one view
A signature is the sealed act. A certificate is the identity card for the verification key. The relying party still decides whether the identity card, act and transaction authority are acceptable.
How a digital signature works
The system prepares the electronic record
The file, form or message to be signed is fixed in a defined format. Signing a different version later produces a different result.
A hash function creates a digest
The algorithm maps the record to a shorter hash result. A material change to the record should change that digest.
The private key creates the signature
The signing algorithm uses the subscriber-controlled private key to transform the digest into the digital signature value.
The signature and certificate travel with the record
The signature package commonly includes the signer's certificate and information needed by the receiving application.
The relying party verifies
Verification uses the public key, recalculates the record digest, validates the certificate chain and checks status, key usage and policy.
Successful cryptographic verification supports two limited conclusions: the signature corresponds to the relevant private key, and the signed content has not changed since the signature was created. It does not prove that the statement inside the record is true, that the private key was never misused, or that the signer had authority for that transaction.
What a digital certificate contains
A public-key certificate is structured data signed by its issuer. In India, the CCA certificate policy and licensed CA certification practice statements control the profile used for regulated certificates. Typical fields include:
- Subject
- The person, organisation, role or system identity to which the certificate was issued. Read the actual fields; a display name alone may be ambiguous.
- Public key
- The verification or encryption key paired with the protected private key. The private key is not placed in the public certificate.
- Issuer and serial number
- The CA that issued the certificate and a unique serial reference used for identification and status management.
- Validity period
- The not-before and not-after dates. A certificate outside this window is not currently valid for new signing.
- Key usage and policy
- Technical extensions limiting what the key is intended to do, such as signing, encryption, server authentication or code signing.
- Issuer signature
- The CA's signature over the certificate, allowing a verifier to build a chain to a trusted root and detect certificate alteration.
- Status references
- Locations or mechanisms used to check whether the certificate was suspended or revoked. A valid date alone is not enough.
The TargoLegal Digital Trust Test
This is an editorial decision framework, not a statutory or statistically validated scoring model. A “no” at any stage should pause procurement or signing until the gap is resolved.
- 1. Transaction requirement
- Ask: What exactly must be signed, encrypted or authenticated? Evidence of yes: a current portal manual, tender clause or counterparty specification. Warning: buying “a DSC” from a generic price list. First step: capture the live requirement and deadline.
- 2. Identity and authority
- Ask: Who must act, and in which capacity? Evidence of yes: matching PAN/name/organisation details plus a board resolution, engagement or authorisation where needed. Warning: sharing one signatory's token among staff. First step: map subscriber, organisation and portal role.
- 3. Certificate purpose
- Ask: Does the certificate's key usage match the act? Evidence of yes: the certificate profile permits the required signing, encryption, TLS or code-signing purpose. Warning: assuming all certificates with a public key are interchangeable. First step: compare the application requirement with the certificate fields.
- 4. Key custody
- Ask: Who controls the private key? Evidence of yes: approved token, HSM or eSign workflow with subscriber authentication and access controls. Warning: an agent retains the token, PIN or remote access. First step: document custody and recovery procedures.
- 5. Chain and status
- Ask: Can the recipient validate the issuer chain and revocation status? Evidence of yes: trusted roots/intermediates, current status information and an application that validates them. Warning: relying only on the visible name or a PDF tick. First step: perform an independent test verification.
- 6. Evidence retention
- Ask: What must still be provable after certificate expiry? Evidence of yes: signed original, trusted timestamp where appropriate, status evidence, audit log and authority records. Warning: printing the signed PDF and deleting the electronic original. First step: set a retention rule before signing.
Common certificate types are not substitutes
- Signing certificate
- Used to verify a signature on an electronic record. Common applications include regulated filings, tenders and business documents. The certificate must match the individual or organisational signing model required by the portal.
- Encryption certificate
- Used to protect data for a recipient holding the corresponding private decryption key. Some procurement systems require both signing and encryption functions. A signing-only certificate cannot be assumed to satisfy this requirement.
- TLS certificate
- Authenticates a web server or domain and enables HTTPS transport security. It does not identify the human who approved a contract and is not a substitute for a statutory filing DSC.
- Code-signing certificate
- Associates released software with a publisher and helps detect code alteration. Platform rules, hardware protection and certificate profiles differ from document-signing requirements.
- S/MIME or client certificate
- May sign or encrypt email, or authenticate a user to a private system. Acceptance depends on the recipient's trust store and the certificate's extensions.
“Digital certificate” is a broad technical category. “DSC” in Indian filing practice usually means a subscriber certificate used to create or verify a digital signature. Ask for the exact certificate profile, not the generic label.
Token-based DSC and online eSign
A token DSC and CCA-framework eSign can both produce digital signatures, but the key lifecycle and user experience differ.
The Second Schedule framework permits notified e-authentication using Aadhaar or other approved eKYC services. This means “eSign” should not be reduced to a scanned mark or to a single universal identity route. The relevant provider must operate through the CCA's licensed framework.
Legal recognition has conditions and exclusions
Section 3 of the Information Technology Act, 2000 describes digital-signature authentication using an asymmetric cryptosystem and hash function. Section 3A recognises reliable electronic-signature or electronic-authentication techniques specified in the Second Schedule. Section 5 gives legal recognition where a signature requirement is met by a prescribed electronic signature.
The Act's definitions also distinguish the objects: an electronic signature authenticates an electronic record, while an Electronic Signature Certificate is issued under section 35 and includes a Digital Signature Certificate. CCA licenses Certifying Authorities; end subscribers obtain certificates through those licensed CAs, not directly from the CCA.
Section 1(4) and the First Schedule exclude a negotiable instrument other than a cheque, a power of attorney, a trust, a will or other testamentary disposition, and a contract for sale or conveyance of immovable property or an interest in it. Other sector laws, registration rules and evidentiary requirements can also control the transaction.
Electronic signature is the broader statutory term
The Act defines “electronic signature” to include a digital signature. A typed name, pasted image or click can show intent in some commercial settings, but it is not automatically a section 3 digital signature or a notified section 3A technique. Contract validity, evidence and regulatory acceptance must be assessed for the specific transaction.
A valid signature is not proof of corporate authority
Before relying on a signed record, verify the signer's capacity. A certificate may identify an individual or organisation, but authority may come from the articles, LLP agreement, board resolution, power delegated by contract, portal role or employment mandate. Preserve that authority evidence alongside the signed record.
Expiry, revocation and timestamping
Expiry
A certificate's end date prevents it from being treated as currently valid for new signing. It does not mechanically erase every earlier signature. Long-term validation asks whether the signature existed while the certificate was valid and not revoked, whether the algorithms remain acceptable, and whether reliable evidence was preserved.
Revocation and compromise
Revocation can occur before scheduled expiry. If a token, private key or PIN may be compromised, stop signing and contact the issuing CA immediately. Section 42 places a duty on the subscriber to exercise reasonable care over the private key and notify the CA without delay when compromise occurs. Reissue does not repair records signed by an unauthorised person.
Trusted timestamp
A trusted timestamp links a record or signature reference to time from a recognised source. It can materially improve evidence that a signature existed at a particular time, especially for long-term validation. But a timestamp is not a cure for every defect: it does not create signer authority, correct an invalid certificate or prove the underlying statement.
Preserve verification material
- Keep the original signed electronic file, not only a printout or screenshot.
- Retain certificate-chain, timestamp and revocation-status evidence required by the signature profile.
- Keep the board resolution, engagement, tender authority or other capacity evidence.
- Record the relying application's submission receipt and audit trail.
- Apply a retention period based on the underlying law, contract and dispute risk.
Security controls that matter in practice
- Obtain subscriber certificates only through a CA listed as licensed by the CCA.
- Make the named subscriber complete the applicable identity and consent process.
- Do not let a consultant, employee or filing agent retain the token, PIN or unattended remote access.
- Verify the exact record and filing data before applying the signature.
- Use separate approval and signing roles for high-impact payments, tenders and statutory filings where feasible.
- Maintain an asset register for tokens, certificate serial numbers, holders, expiry dates and associated portals.
- Revoke promptly when a key is lost, exposed, misused or no longer controlled by the subscriber.
- Test the replacement certificate and update portal associations before a filing deadline.
Common mistakes
- Buying by price alone
- The lowest-cost certificate may have the wrong purpose, subject type, validity, hardware or portal compatibility.
- Treating the PDF tick as final
- A viewer's symbol may not show current revocation status, trusted roots, timestamp quality or signer authority. Inspect the verification details.
- Sharing credentials
- Convenience destroys evidence about who controlled the private key. It can also expose the subscriber and organisation to unauthorised acts.
- Confusing signing and encryption
- A signature supports integrity and authentication; it does not make the document confidential. Encryption has a different objective and key usage.
- Ignoring role changes
- When an authorised signatory leaves or authority changes, update internal mandates and portal roles and assess revocation without delay.
Digital signature and certificate FAQs
Are a digital signature and a digital certificate the same thing?
No. A digital signature is the cryptographic result attached to an electronic record using a private key. A digital certificate is a certifying authority's signed credential that links the corresponding public key to a subscriber or system. The certificate helps a verifier decide whose key it is and whether the trust chain is acceptable.
Can a digital signature be verified without a digital certificate?
A signature can be checked mathematically if the verifier already has the correct public key. In normal regulated or commercial use, a certificate and its trust chain supply the identity binding, issuer information, key usage, validity and status references needed for meaningful verification.
Is a scanned handwritten signature a digital signature under the IT Act?
A scanned signature image is not a section 3 digital signature because it does not use the subscriber's asymmetric key pair and hash-based verification process. It may form part of another electronic-signing process, but its enforceability and evidence depend on the applicable law, authentication method, intent and transaction.
What does DSC mean in India?
DSC commonly means Digital Signature Certificate: a certificate issued through a Certifying Authority licensed by India's Controller of Certifying Authorities. The Information Technology Act's broader current term is Electronic Signature Certificate, which includes a Digital Signature Certificate.
Is online eSign the same as a USB-token DSC?
Both can produce legally recognised electronic signatures when used through the approved framework, but the operating model differs. A token DSC keeps a subscriber's longer-lived signing key in approved hardware. CCA's eSign framework supports an online, authenticated one-time signing service using a short-lived certificate issued for that transaction.
Does certificate expiry invalidate every earlier signature?
Not automatically. Historical verification depends on whether the signature was made while the certificate was valid, whether it was revoked, whether a trusted timestamp and status evidence are available, the signature profile and the relying system's validation policy. Preserve the signed original and verification evidence; do not rely on a current green tick alone.
Which digital certificate should a business obtain?
Start with the relying application's current specification. Confirm whether the task needs signing, encryption, TLS server authentication, code signing, email security or online eSign; then confirm subscriber type, identity fields, key usage, assurance class, key storage and portal registration. Similar-looking certificates are not interchangeable.
Primary material used
- India Code: Information Technology Act, 2000 — definitions, sections 3, 3A, 5, 35, 38 and 42, and the First Schedule.
- Controller of Certifying Authorities: current guidelines — current policy, identity verification, interoperability and signature-profile materials.
- CCA X.509 Certificate Policy for India PKI — certificate classes, profiles, key usage and lifecycle controls.
- CCA Identity Verification Guidelines — current subscriber identity-verification requirements.
- CCA Interoperability Guidelines — relying-application and certificate acceptance guidance.
- CCA eSign service information and eSign framework — licensed online electronic-signature model.
- Second Schedule electronic authentication procedure — notified eKYC-based electronic-signature framework.
- CCA timestamping service guidance — trusted time references and timestamp use.
- CCA list of licensed Certifying Authorities — verify the issuer before applying.
Legal note: This guide explains general Indian digital-signature and certificate concepts as checked on 17 July 2026. Portal specifications, certificate profiles, trust stores and sector requirements can change. It is not a substitute for advice on a particular contract, filing, tender, evidence issue or security incident. Verify the live portal and obtain legal, compliance or information-security review where the consequence is material.
Corrections: To report a factual or source issue, email info@targolegal.com with the page title and the official material supporting the correction.
