A digital certificate is an electronic credential that binds an identified person, organization, device, or system to a public cryptographic key. It allows software and other parties to evaluate who controls a public key and whether that association can be trusted.
Most digital certificates used for websites, email, software, and document signing follow the X.509 standard. The certificate contains the public key and identifying information, while the corresponding private key is kept separately and protected by its owner or a trusted service.
A digital certificate is not a visual signature, a signed document, or proof that every statement about its holder is true. It is a structured, digitally signed assertion about the relationship between an identity and a public key.
How a certificate binds identity to a public key
A digital certificate connects three elements:
- A subject, such as a person, business, server, or device
- A public key belonging to a public and private key pair
- An issuer that digitally signs the certificate
The issuer’s signature protects the certificate data from undetected modification. If someone changes the subject name, public key, validity dates, or another signed field, the issuer’s signature should no longer validate.
The strength of the identity binding depends on how the certificate was issued. A certificate authority may verify a domain name, an organization, an individual, or another identifier according to its policies. Different certificate types and providers can therefore offer different levels of identity assurance.
A certificate does not reveal the private key. The private key must remain under the control of its owner or an authorized signing service. If that key is stolen or misused, another party may be able to create signatures that appear to come from the certificate holder until the compromise is detected and the certificate is revoked.
Certificate authorities and chains of trust
A certificate authority, commonly called a CA, issues and digitally signs certificates. Before issuance, the CA or a registration authority typically checks the information associated with the certificate request. The exact checks depend on the certificate’s purpose and the issuer’s policy.
Certificates often form a chain:
- An end entity certificate identifies the person, organization, or system using the key.
- One or more intermediate CA certificates connect that certificate to a higher authority.
- A root certificate acts as the trust anchor.
A verifier does not trust a certificate simply because it contains a CA name. Software attempts to build a valid chain to a root that the software, organization, or user already trusts. This certificate lifecycle sits within public key infrastructure, which covers the policies, systems, people, and processes used to issue, maintain, validate, and revoke certificates.
A self-signed certificate signs itself instead of chaining to a separate CA. It can still provide encryption or cryptographic identification in a controlled environment, but other parties must establish trust in it through another reliable method.
What an X.509 certificate contains
An X.509 certificate commonly includes:
- Version: The X.509 certificate format version, often version 3.
- Serial number: A number assigned by the issuer to uniquely identify the certificate among that issuer’s certificates.
- Issuer: The CA or entity that signed and issued the certificate.
- Subject: The person, organization, device, or system associated with the public key.
- Validity period: The
notBeforeandnotAfterdates that define when the certificate is intended to be valid. - Subject public key information: The public key and the algorithm associated with it.
- Signature algorithm and issuer signature: The method and signature used by the issuer to protect the certificate.
- Extensions: Additional rules and identifiers, such as key usage, extended key usage, certificate policies, basic constraints, subject alternative names, and locations for status information.
Extensions help software determine how a certificate may be used. For example, key usage fields may indicate whether the key is intended for document signing, certificate signing, encryption, or another purpose. A technically intact certificate can still be unsuitable for a particular operation if its permitted uses do not match that operation.
How certificate validation works
Certificate validation is more than checking whether the certificate file opens. A validating application may examine whether:
- The issuer’s signature on each certificate is cryptographically valid
- The certificate chain leads to a trusted root
- The certificate was within its validity period at the relevant time
- The identity and intended use match the transaction
- Required certificate policies and constraints are satisfied
- The certificate has been revoked
- The cryptographic algorithms meet the application’s security requirements
Revocation allows an issuer to mark a certificate as no longer trustworthy before its scheduled expiration. This may happen after a private key compromise, an unauthorized issuance, or a change in the certificate holder’s relationship with the issuer. Status may be communicated through certificate revocation lists, known as CRLs, or an online status service such as OCSP.
Validation results depend partly on the verifier’s trust settings, available status information, software behavior, and the time being evaluated. A certificate that one system trusts may appear untrusted on another system that does not recognize the same root or cannot build the necessary chain.
Expiration does not automatically invalidate an earlier signature
Expiration means a certificate should no longer be used to create new signatures after its validity period ends. It does not necessarily mean every signature created with that certificate becomes invalid.
A certificate-based signature may remain verifiable if evidence shows that the signature was created while the certificate was valid and had not been revoked. Trusted timestamps and preserved validation information can help support that determination over time.
Without reliable time and status evidence, a verifier may only know that the signature is cryptographically correct, not whether it was created before the certificate expired or was revoked. Certificate expiration and document integrity are related but separate questions.
The certificate’s role in a digital signature
In a certificate-based digital signature, the signer uses a private key to create a cryptographic signature over document data. The associated digital certificate supplies the public key needed to verify that signature and provides information about the key holder.
This process can support two important findings:
- The corresponding private key created the signature.
- The signed data has not changed since the signature was applied.
The certificate does not, by itself, prove that the named person personally approved the document. That conclusion also depends on factors such as the certificate issuance process, control of the private key, signer authentication, timestamps, consent records, and the surrounding transaction evidence.
Likewise, a valid certificate does not automatically make an agreement legally enforceable. Legal effect depends on the jurisdiction, document type, parties’ intent, applicable formalities, and the complete evidence surrounding the transaction. This is general educational information, not legal advice.
Digital certificate, digital signature, and certificate of completion
| Concept | What it is | Primary purpose |
|---|---|---|
| Digital certificate | A credential binding an identity or system to a public key | Supports trust in the public key |
| Digital signature | Cryptographic data created with a private key and attached to specific content | Supports signer attribution and detection of changes |
| electronic signature platforms after a signing transaction is completed. It summarizes who">Certificate of completion | A platform-generated record summarizing a signing workflow | Documents events such as sending, viewing, authentication, and completion |
A certificate of completion is not a digital certificate. Despite the similar names, it generally contains workflow evidence rather than a CA-signed public key credential.
FAQ
Does a digital certificate contain the private key?
No. The certificate contains the public key. The corresponding private key is stored separately and should be protected from unauthorized access.
Can anyone issue a digital certificate?
Technically, an individual or organization can create a self-signed certificate. Whether other parties trust it depends on their policies and whether they independently trust the issuer or certificate.
What happens when a digital certificate expires?
It should no longer be used for new signatures. Earlier signatures may remain valid if reliable evidence establishes that they were created while the certificate was valid and not revoked.
Is a digital certificate the same as a digital signature?
No. A digital certificate binds an identity to a public key. A digital signature is created with the corresponding private key and applies to a particular document, message, or other data.
Does a valid certificate prove who signed a document?
It provides evidence connecting the signing key to the certificate’s subject. The overall identity conclusion also depends on certificate issuance, private key control, authentication, timestamps, and other transaction evidence.