What are Digital Certificates?

What is a digital certificate?

The term digital certificate generally refers to a public-key certificate. It is a set of data that uniquely identifies an entity, contains the entity’s public key and possibly other information, and is digitally signed by a trusted party. That signature binds the public key to the identified entity. Additional certificate information can specify how the key may be used and the certificate’s validity period.1

The central purpose is therefore a verifiable binding: a relying party can obtain a public key together with an asserted identity and then evaluate whether the assertion is acceptable under its validation rules. A certificate does not, by itself, guarantee that every statement about a subject is true in every context. Its usefulness depends on the issuing authority, the applicable certificate policy, the validation time, the intended use, and the relying party’s trust configuration.432

What information does a certificate contain?

At a conceptual level, a certificate has a subject, an issuer, a public key, a validity period, identifying information, extensions, and a digital signature. The subject is the entity whose public key is being bound. The issuer is the certification authority or other issuing entity that signs the certificate. In an X.509 certification path, the issuer of one certificate is expected to correspond to the subject of the certificate that issued it.3

The subject may be represented by a distinguished name or a subject alternative name, depending on the certificate and application. RFC 5280 describes path validation as verifying the binding between a subject distinguished name or subject alternative name and the subject public key in the target certificate, based on the trust anchor’s public key.3

The public key is the openly distributable part of an asymmetric key pair. Depending on the algorithm and use, a public key can verify a signature made with the corresponding private key, encrypt key material that the private key can decrypt, or help compute a shared secret during key agreement. The certificate carries the public key; it does not replace or reveal the corresponding private key.12

Extensions add application or policy information. For example, TLS 1.3 describes certificate-entry extensions and identifies certificate-related extensions such as an OCSP status extension and a signed-certificate-timestamp extension. Which extensions matter depends on the certificate profile and application.4

A certificate also has a signature made by the issuer or signing authority. Verifying that signature tests whether the certificate data was signed by the public key associated with the issuer. It does not, standing alone, prove that the certificate is currently valid, that the name is the one an application intended to contact, that the key is authorized for a particular purpose, or that the certificate has not been revoked.432

Certificates, private keys, and encryption are not the same thing

A frequent source of confusion is treating a certificate as if it were a private key. In public-key cryptography, the public key and private key are related, but determining the private key from the public key is intended to be computationally infeasible. The public key may be shared; the private key is the secret needed for operations such as producing a signature corresponding to that public key.12

A certificate distributes and authenticates the public key’s association with a subject. It does not provide secrecy for the private key and does not prove that the holder has possession of the private key unless the application performs a separate proof-of-possession operation. TLS 1.3 illustrates this distinction: the certificate message carries the endpoint certificate, while the CertificateVerify message contains a signature over the handshake made with the private key corresponding to the public key in the certificate.4

A certificate is also not the same as encryption. Encryption transforms data to protect confidentiality; certificates primarily support public-key identity binding and related authentication decisions. NIST describes digital signatures as providing assurance of origin authentication and data integrity, while AES is a block cipher used for cryptographic services such as confidentiality and authentication in appropriate modes.56

How certificate validation works

Certificate validation normally evaluates a certification path: a sequence of certificates connecting a target certificate to a trust anchor. RFC 5280 states that the path-validation input includes a trust anchor and that the primary goal is to verify the binding between the target certificate’s subject name and public key on the basis of the trust anchor’s public key.3

For a prospective path, each certificate except the target is related to the next certificate through issuer and subject fields; the first certificate is issued by the trust anchor; the last certificate is the target; and every certificate in the path must be valid at the time in question. A certificate must not appear more than once in the prospective path.3

A trust anchor is an authoritative entity for which trust is assumed. In a PKI, it is represented by a certificate used to verify the signature on a certificate issued by that trust anchor. Trust-anchor certificates are often self-signed and may be distributed with operating systems or applications. Because the validation process depends on the authenticity and integrity of the trust anchor, choosing and protecting the trust-anchor set is a significant security decision.1

Validation is contextual rather than universal. RFC 5280 permits validation with respect to the current date and time and may support validation at a point in the past, but mechanisms are not available for validating a certificate at a time outside its validity period. TLS guidance also says that implementations are responsible for verifying certificate integrity, should generally support certificate-revocation messages, and should verify proper signing by a trusted CA absent a specific application-profile indication.432

Validity, revocation, and the certificate lifecycle

The validity period is the time from notBefore through notAfter, inclusive. Certificates may be renewed, including by issuing a new certificate containing the same public key. Some device certificates may be intended for the lifetime of a device and therefore may not have an ordinary expiration date; RFC 5280 describes a special generalized-time value for a certificate with no well-defined expiration date, together with requirements concerning continued status maintenance.31

Expiration is not the only lifecycle event. A certificate can become unsuitable before notAfter because of a name change, a change in the relationship between the subject and the CA, or compromise or suspected compromise of the corresponding private key. In those circumstances, the CA may revoke the certificate.3

One X.509 revocation method is the certificate revocation list, or CRL. A CRL is a timestamped list of revoked certificates signed by a CA or CRL issuer and made available in a public repository. Each revoked certificate is identified by its serial number. A certificate-using system checks the certificate’s signature and validity and then obtains a suitably recent CRL to determine whether the certificate serial number appears on it. What counts as suitably recent can vary with local policy.3

NIST also describes online status mechanisms, such as OCSP, as a way to communicate revocation status to an appropriate status server. If a private key is compromised, the corresponding public-key certificate should be revoked as soon as possible because the binding between the owner and the key can no longer be trusted.1

Operationally, certificate lifecycle management includes issuance, deployment, monitoring, renewal, replacement, and revocation. NIST notes that a certificate inventory can identify certificates approaching expiration, help avoid service outages by enabling replacement before expiration, detect algorithms or key lengths that are no longer secure, support response to incidents such as a CA compromise, and record certificate-maintenance contacts.2

Common uses: TLS and signed data

In TLS, a server can send its endpoint certificate and additional certificates in a certificate message. TLS 1.3 states that the sender’s certificate appears in the first certificate entry and that each following certificate should directly certify the one immediately preceding it. A trust anchor may be omitted from the transmitted chain when peers are expected to possess it independently.4

The certificate supports authentication of the endpoint’s public key, while CertificateVerify demonstrates use of the corresponding private key by signing the handshake. Certificate-based client authentication is optional: the server sends a CertificateRequest when it wants the client to authenticate with a certificate, and the client’s certificate message is omitted when client authentication is not desired.4

Certificates can also support authentication and integrity for signed data, including software or code-signing workflows, when the relevant application profile defines that use. The cited NIST material establishes the general role of digital signatures in origin authentication and data integrity, while certificate information can specify how a key is used. Acceptance still requires the relying party to apply the relevant purpose and policy checks rather than treating every validly signed certificate as suitable for every application.56432

Why policy and configuration matter

A certificate is evaluated within a PKI and its policy framework. NIST describes a certificate policy as a named set of rules indicating the applicability of a certificate to a particular community or class of applications with common security requirements. A certification practice statement describes how a specific CA issues and manages public-key certificates. These documents can address key generation and storage, certificate generation, certificate-status services, CRL generation and distribution, system management, audits, configuration management, and archiving.2

Consequently, two certificates with similar fields may not be interchangeable. A relying party can require a particular trust anchor, policy, name form, key usage, algorithm strength, validity time, or revocation-status method. TLS guidance specifically says trust-anchor selection should be done carefully, users should be able to view certificate and trust-anchor information, and applications should enforce minimum and maximum key sizes.4

The practical lesson is to treat certificate validation as a decision process, not a single Boolean signature test. The decision asks whether this certificate, for this subject and public key, issued through this path, is acceptable for this purpose, at this time, under this policy, and with the available status information.432

A practical certificate review checklist

1. Identify the certificate’s subject and the name or identifier the application intends to authenticate.
2. Inspect the issuer and determine whether a valid path can be built to an appropriate trust anchor.
3. Check notBefore and notAfter against the relevant validation time.
4. Confirm that the public key and certificate are being used for an authorized purpose under the applicable policy.
5. Verify the issuer’s signature and the required path relationships.
6. Evaluate revocation or other certificate-status information according to local policy and the application profile.
7. Confirm that the endpoint or signer can demonstrate control of the corresponding private key when the protocol requires proof of possession.
8. Record the certificate in an inventory and plan renewal, replacement, and incident response.

Conclusion

Digital certificates are signed public-key identity bindings. They identify a subject, carry that subject’s public key, and provide issuer, validity, identifier, extension, and signature information that a relying party can evaluate. The certificate is distinct from the private key and from encryption. Reliable use requires more than checking a signature: the relying party must consider the certification path, trust anchor, names, intended purpose, time, policy, and revocation context. TLS demonstrates the division of responsibilities clearly: the certificate communicates the public-key binding, while a private-key signature proves control of the key during the handshake. Lifecycle management then keeps certificates current through inventory, renewal, replacement, and revocation. claim-011432