Digital Certificate vs Digital Signature: What's the Difference?

July 16, 2026 ·Gustav Poola ·

digital-certificatedigital-signaturex509pkixadeseidascertificate-authorityidentity-bindingglobal-digital-identityauthentication

A digital certificate is a signed statement about a public key and its holder's identity, issued by a Certificate Authority. A digital signature is a cryptographic operation produced by the corresponding private key over document data. The certificate proves who the signer is; the signature proves the document is intact and was signed by that signer. Different objects, complementary purposes, and the confusion between them is where most eIDAS audit findings actually land.

Digital Certificate vs Digital Signature: What's the Difference?

A Zurich-based e-signing platform's chief architect walked me through an audit finding last month that read, verbatim: "the audit could not link the presented certificate to the individual described in the enclosed identity document." Her engineering reaction was that the certificate was fine — issued by a recognised CA, in date, cryptographically valid. The regulator's finding was not about the certificate as a cryptographic object. It was about the relationship between the certificate, the signature that used it, and the identity primitive under both. Two objects in the same event, one confused conversation, and a very specific audit outcome. This post is the difference.

What exactly is a digital certificate?

A cryptographic assertion about a public key and its holder's identity, structured as a data object, signed by a Certificate Authority whose trust chain the verifier already accepts.

The canonical structure is X.509 as defined by ITU-T Recommendation X.509 and profiled for internet PKI in IETF RFC 5280. A certificate is a small binary or PEM-encoded object that names the subject (who the certificate is about), carries the subject's public key, and is signed by an issuer (the Certificate Authority). It has a validity period, an algorithm identifier, and — depending on the certificate profile — additional attributes: an intended usage (signing, encryption, TLS server authentication), a certificate revocation distribution point, an OCSP responder location, and any subject alternative names. The signature at the bottom of the certificate is the CA's own private key over a hash of everything else in the certificate. That signature is what makes the certificate a trusted statement rather than an assertion you type at a keyboard.

The identity part of the certificate — the subject's distinguished name, the organisation attributes, the email addresses or other identifiers — is only as strong as the identity-verification the CA performed before issuing the certificate. This is where the ETSI EN 319 411-1 requirements for Trust Service Providers issuing certificates come in. The standard specifies what proofing steps a TSP must perform before binding an identity to a certificate — including which evidence, which validation, and which retention obligations apply. Under eIDAS Article 24, a Qualified Trust Service Provider issuing qualified certificates has to verify the applicant's identity through physical presence, notified eID schemes at substantial or high assurance, or equivalent means. The certificate is, in that sense, the cryptographic packaging of a proofing event that happened before the certificate existed.

The certificate itself does not sign anything. It is inert data. It sits in the signer's environment (on a smart card, in a HSM, in a browser keystore, in a software token) and is presented to verifiers along with signatures produced by the certificate's private key. What signs is the private key. What identifies is the certificate. Two roles, two objects.

What exactly is a digital signature?

The output of a cryptographic operation performed by a private key over a hash of the document being signed — a small binary artefact that can be verified against the corresponding public key and document.

The mathematical primitive is straightforward. The signer computes a cryptographic hash of the document (typically SHA-256, or SHA-384 / SHA-512 for higher assurance contexts), then applies a signing algorithm (RSA-PSS under RFC 8017, ECDSA under RFC 6979, or Ed25519 under RFC 8032) with the private key over the hash. The output is the signature — a bounded-size binary that, when combined with the corresponding public key and the original document, can be verified independently by anyone.

The signature is bound to the document through the hash. Any modification of the document produces a different hash, which no longer matches what the signature covers, and the verification fails. The signature is bound to the signer's private key through the mathematics — only that key can produce that signature over that hash, assuming the algorithm's security assumptions hold. The signature is not, by itself, bound to an identity. It is bound to a key. The identity binding comes from the certificate that names the key's holder.

This is the point most vendor documentation glosses over. The signature is a mathematical operation; the identity claim is separate; the two are stitched together at verification time by resolving the certificate that names the key, walking that certificate's chain to a trust root, and confirming that both objects — signature and certificate — point at the same key with the same trust anchor. That resolution is what our verification-chain post walked through in five stages under ETSI EN 319 102-1.

For eIDAS Article 26 AdES, the signature has to be "uniquely linked to the signatory" and "capable of identifying the signatory". Both of those requirements depend on the certificate's identity binding, not on the signature's cryptographic primitive. A signature can be mathematically perfect over the wrong identity — and that is the situation the Zurich audit finding described.

How do the two work together in a real signing event?

The certificate is presented to identify the signer; the signature is produced to bind the document to that identified signer. Verification walks the reverse: read the signature, resolve the certificate, validate the chain, confirm both point at the same key.

The choreography at signing time. The signer's environment holds the private key, protected by whatever key-container the deployment uses — a smart card, a Hardware Security Module, a cloud-based signing service with authenticated access, a mobile-signing app with device-bound key material. The signing platform requests a signature over the document hash. The private-key holder performs the signing operation. The platform packages the signature together with the certificate — usually in a signature format specified by the AdES profile (PAdES-B-B / PAdES-B-T / PAdES-B-LT under ETSI EN 319 142 for PDF, XAdES for XML, CAdES for CMS). The output is a signed document that carries both objects: the certificate stating who the signer is claimed to be, and the signature demonstrating that the signer's private key operated on this specific document.

At verification time, a verifier retrieves the signature from the document, extracts the referenced certificate (or reads it from the certificate chain embedded in the signature format), walks the certificate's trust chain back to an anchor it recognises — typically the EU Trusted List for eIDAS-anchored signatures — validates the chain, checks revocation status of every certificate in the chain at the signing moment, and finally verifies the signature mathematically using the certificate's public key. If any step fails, the verification produces an indeterminate or invalid result and the specific stage failure is what a regulator's audit report will identify.

The design decision that matters at deployment time is where the identity proofing that supported certificate issuance actually happened, and what evidence of it the deployment retains. A certificate whose CA proofed the subject through a self-service form with an SMS OTP is a valid X.509 object but a weak identity anchor — NIST SP 800-63-4 rates that pattern at IAL1. A certificate whose CA proofed the subject through a chip-anchored proofing event under ICAO 9303 with biometric matching is the same X.509 object but a strong identity anchor at IAL2 or higher. The certificate's cryptographic structure looks identical; the audit-defensibility does not. Our earlier post on the proof-of-identity requirement across signature tiers walked through the assurance-level ladder that maps to this distinction.

Where does the confusion come from — and why does it matter for compliance?

From vendor marketing that uses "digital signature" as a single umbrella term, and from the fact that verifying a signature at surface level does not tell the verifier anything about the identity-proofing that stands behind the certificate.

The pattern I see across the audit findings in 2025 and 2026 is the same one every time. The integrator's platform sends the correct AdES headers, produces a mathematically valid signature, packages the certificate into the standard signature format, and the receiving system displays "Signed by [Name]". The receiver interprets this as identity confirmation. Neither the platform nor the receiver has evidence of what proofing event the CA relied on when it issued the certificate. The identity anchor is invisible at the signature-object level. The audit finding, when it lands, cites eIDAS Article 26(1)(a)(b) — "uniquely linked to the signatory", "capable of identifying the signatory" — and points at the layer under the certificate that the platform never had visibility of.

The way we architect around this at IdentiGate is by treating the identity proofing as its own primitive, with its own retained evidence, and its own binding to the certificate. The Identity Verification product produces a chip-anchored proofing record — passport NFC chip read for the 179 ICAO 9303 countries, or document authenticity plus biometric face match for every remaining country — AdES-bound under eIDAS Article 26, with the resulting proofing evidence retained alongside the certificate issuance. That produces global identity coverage — the same primitive works for a Colombian founder onboarding into a Berlin fintech and for a Ukrainian driver signing an eCMR consignment in Rotterdam. The Signatures product uses that identity-anchored certificate to produce AdES signatures where the identity binding is verifiable back to the proofing event. The Evidence Layer product retains the whole record — proofing event, certificate, signature, validation data — in the form a verifier in 2030 can actually read.

Said plainly: the certificate and the signature are two objects, and the compliance question at audit is not whether either object is mathematically valid but whether the identity-proofing event under the certificate holds up when the regulator walks the chain backward. A Warsaw-based cross-border insurance carrier we work with rebuilt their signing integration around that principle after their first cross-border reinsurance audit found that their previous provider's certificates were valid but not identity-anchored. The signing chain now retains, per signature, the certificate, the proofing record, and the AdES envelope. When the same audit team came back a year later, the finding was closed. The signatures had not changed; the identity anchor under them had.

Where I disagree with the loud vendor pitch is the framing that "AdES-compliant certificate" describes a complete offering. It describes the certificate. It says nothing about the proofing event, nothing about the retention, nothing about the identity anchor that the audit will actually ask about. The certificate and the signature are the visible objects; the identity-proofing primitive is the invisible one that makes both defensible. That is the layer we ship, and the layer the audit closes findings against.

Sources

Primary — eIDAS and signature framework

Primary — ETSI signature and TSP standards

Primary — IETF PKI and cryptographic standards

Primary — ITU-T certificate standard

ITU-T Recommendation X.509

Primary — NIST identity assurance and ICAO documents

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.