Digital Signatures, Certificates and PKI

Introduction and Context

Digital communication depends on the ability to determine whether information is genuine, unchanged and associated with the claimed sender. Encryption protects confidentiality, but confidentiality alone does not prove who created a message or whether it was modified. Digital signatures, digital certificates and public key infrastructure (PKI) address these requirements.

A digital signature is a cryptographic mechanism that binds a message to a signer’s private key. A verifier uses the corresponding public key to test the signature. Certificates provide a trusted method for associating a public key with an identity. PKI is the broader system of technologies, policies, people and procedures used to create, distribute, validate, revoke and manage certificates and keys.

These technologies support secure web browsing, software updates, electronic contracts, virtual private networks, email security, identity management and enterprise access control.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the purpose and operation of digital signatures;
• distinguish integrity, authentication, confidentiality and non-repudiation;
• describe certificates and the roles of certificate authorities;
• interpret certificate fields and trust chains;
• explain certificate revocation and status checking;
• describe PKI components, lifecycle management and governance;
• identify practical, legal and operational limitations of digital signatures.

1. Security Services Supported by Digital Signatures

Four security objectives are commonly discussed in relation to digital signatures.

Integrity means that data has not been altered after signing. If even a small part of the signed data changes, verification should fail.

Authentication is the process of establishing the identity of an entity. A valid signature demonstrates control of a private key, but it identifies a person or organisation only when the public key has been reliably associated with that identity.

Non-repudiation refers to evidence that makes it difficult for a signer to deny a transaction. In practice, non-repudiation depends on cryptographic evidence, secure key custody, identity verification, reliable records and applicable law. A signature does not create absolute proof by itself.

Confidentiality is not provided by a digital signature. Encryption is required when the content must remain secret. A message may be both encrypted and signed, but these are separate operations.

2. How a Digital Signature Works

Most practical signature systems use a hash function together with a public-key signature algorithm.

A cryptographic hash function converts input data of arbitrary length into a fixed-length digest. If m is a message and H is a hash function, its digest is:

Here, h is the message digest. A secure hash function should make it computationally infeasible to find a different message with the same digest, and it should be infeasible to recover the message from the digest.

The signer computes the digest and uses a private key to generate a signature:

The verifier uses the public key and the received message to test the signature:

In this notation, sk is the private key, pk is the corresponding public key, m is the message and s is the signature. The verification result is meaningful only if the public key is trusted and correctly associated with the claimed signer.

The usual process is:

1. The signer prepares the message.
2. A secure hash of the message is calculated.
3. The signature algorithm signs the digest using the private key.
4. The message and signature are transmitted.
5. The recipient obtains the correct public key.
6. The recipient verifies the signature and independently hashes the received message.
7. Verification succeeds only if the signature, public key and message are consistent.

A signature normally does not contain the entire message. This improves efficiency, especially for large files. The security of the process depends on the signature algorithm, hash function, key protection, implementation and trust in the public key.

Common Signature Algorithms

• RSA signatures: Widely deployed and based on the difficulty of factoring large integers. Modern implementations require secure padding schemes such as RSA-PSS rather than obsolete textbook RSA signatures.
• DSA: Historically important, but generally not preferred for new systems.
• ECDSA: Uses elliptic-curve mathematics and provides strong security with smaller keys. Correct generation and protection of the per-signature nonce are essential.
• EdDSA, including Ed25519: Designed for efficient and robust signing, with deterministic nonce generation in common implementations.

Algorithms and key sizes must follow current standards and organisational policy. A mathematically strong algorithm can still fail if keys are reused incorrectly, randomness is weak or private keys are exposed.

3. Digital Signatures Compared with Electronic Signatures

An electronic signature is a broad legal or business concept: an electronic indication of a person’s intention to approve or sign something. It may be a typed name, a scanned signature, a click-to-accept action or a cryptographic signature.

A digital signature is a specific cryptographic technique using asymmetric keys and verification algorithms. Therefore, every digital signature may serve as an electronic signature, but not every electronic signature is a digital signature.

The legal effect varies by jurisdiction, transaction type and evidence quality. Organisations should not assume that cryptographic validity alone determines legal enforceability.

4. Digital Certificates

A digital certificate is a digitally signed data structure that binds a public key to an identity or defined subject. In widely used PKI systems, certificates commonly follow the X.509 standard.

A certificate does not contain a secret private key. It usually contains a public key, subject information, issuer information, validity dates, usage restrictions and the certificate authority’s signature.

Important certificate fields include:

The certificate’s validity period does not mean that the subject is continuously trustworthy. It means that the issuer intended the certificate to be valid during that interval, subject to revocation, policy and verification conditions.

Certificates and Trust

A certificate can be technically valid but operationally untrusted. A verifier must decide whether it trusts the issuing authority, whether the certificate is within its validity period, whether its name matches the intended service and whether its key usage is appropriate.

For example, a web browser checks whether:

• the certificate is issued for the requested domain name;
• the certificate chain leads to a trusted root;
• signatures in the chain are valid;
• the certificate is currently valid;
• the certificate is not known to be revoked;
• the certificate permits server authentication; and
• the negotiated protocol and cryptographic algorithms are acceptable.

5. Certificate Authorities and Trust Chains

A certificate authority (CA) is an entity trusted to issue and revoke certificates according to defined policies. A CA verifies information about a subject and signs the subject’s certificate with the CA’s private key.

PKI commonly uses a hierarchy:

• Root CA: The trust anchor. Its certificate is usually self-signed and installed in operating systems, browsers or organisational trust stores.
• Intermediate CA: Certified by a root or another intermediate CA. It normally issues end-entity certificates.
• End-entity certificate: Issued to a server, person, device, application or organisation. It is not normally authorised to issue further certificates.

A certificate path, or chain, might therefore be:

Server certificate → Intermediate CA certificate → Root CA certificate

The verifier checks each signature from the end entity toward a trusted root. The root is trusted because it is configured as a trust anchor, not merely because its self-signature proves its identity.

A CA must protect its signing keys extremely carefully. Root keys are often kept offline, while intermediate keys are used for routine issuance. This reduces the risk that compromise of an operational system will directly expose the root of trust.

6. Certificate Validation and Path Building

Certificate validation is more than checking one signature. A verifier performs path construction and policy checks. Important checks include:

1. Chain construction: Find a path from the presented certificate to a trusted root.
2. Signature verification: Verify each certificate using the issuer’s public key.
3. Validity time: Confirm that the relevant time falls within each certificate’s validity period.
4. Name validation: Confirm that the identity in the certificate matches the requested service or intended subject.
5. Basic constraints: Ensure that only authorised CA certificates issue subordinate certificates.
6. Key usage: Confirm that the certificate is being used for an allowed purpose.
7. Policy processing: Apply organisational or regulatory certificate policies where required.
8. Revocation status: Determine whether a certificate has been revoked.
9. Algorithm and key checks: Reject weak, prohibited or unsuitable cryptographic parameters.

A certificate chain may fail even when all individual signatures are mathematically correct. For example, an expired intermediate certificate, a hostname mismatch or an untrusted root can invalidate the result.

7. Certificate Revocation and Status

Certificates sometimes become invalid before their scheduled expiry. Reasons include private-key compromise, inaccurate identity information, misuse, organisational change or CA error.

Certificate Revocation Lists

A certificate revocation list (CRL) is a digitally signed list of revoked certificate serial numbers. A verifier downloads the list and checks whether the certificate appears on it. CRLs can become large and may not provide immediate status updates.

Online Certificate Status Protocol

The Online Certificate Status Protocol (OCSP) allows a verifier to query a responder about a certificate’s status. The response commonly indicates good, revoked or unknown, and is itself signed.

OCSP can reduce data transfer but introduces availability, privacy and dependency concerns. A CA may support OCSP stapling, in which the server periodically obtains a signed status response and sends it to the client during the secure connection. This reduces direct client queries to the CA.

Revocation checking has practical limitations. A verifier may be offline, a status service may be unavailable, or a system may be configured to continue despite an unsuccessful status check. Organisations must define fail-open and fail-closed behaviour according to risk.

8. Public Key Infrastructure Components

PKI is an operational ecosystem rather than a single product. Typical components include:

• Certification authority: Issues and revokes certificates.
• Registration authority (RA): Performs identity verification and approves requests, often on behalf of a CA.
• Certificate repository: Publishes certificates, CRLs and policy information.
• Validation service: Provides certificate status information.
• Key management system: Generates, stores, rotates, backs up and destroys keys.
• Hardware security module (HSM): A tamper-resistant device for protecting high-value private keys and performing cryptographic operations.
• Trust stores: Collections of trusted root certificates maintained by browsers, operating systems or organisations.
• Certificate management platform: Automates discovery, renewal, deployment and reporting.
• Policies and procedures: Define identity proofing, approved algorithms, responsibilities, audit requirements and incident response.

PKI governance should specify who may request certificates, what evidence is required, how long certificates remain valid, how keys are recovered or destroyed and what happens after compromise.

9. The Certificate and Key Lifecycle

A professional PKI treats keys and certificates as lifecycle objects.

Planning and Registration

The organisation defines certificate purposes, naming conventions, approval requirements, cryptographic standards and ownership. A subject generates a key pair or receives one through an approved provisioning process. The private key should be generated in a secure environment and should not be transmitted unnecessarily.

Issuance

The applicant submits a certificate signing request (CSR). The CSR normally contains the public key, requested subject information and a proof that the applicant controls the associated private key. The RA or CA validates the request before issuing the certificate.

Deployment and Use

The certificate is installed in the correct service, device or application. Administrators must ensure that private keys have restrictive permissions, appropriate backup protection and clear ownership. Certificate use should be monitored.

Renewal and Rotation

Certificates should be renewed before expiry. Keys may also be rotated, particularly when policy requires fresh key material or when risk changes. Automation reduces outages caused by forgotten renewal dates.

Suspension, Revocation and Recovery

Some environments support temporary suspension, although revocation is more common. If compromise is suspected, the certificate should be revoked promptly and a replacement key pair should normally be generated. Restoring a certificate without addressing a compromised private key does not solve the problem.

Destruction

At the end of the lifecycle, private keys, backups and copies must be securely destroyed or rendered unusable. Records should show when and why destruction occurred.

10. Worked Example: Verifying a Signed Document

Consider a procurement system that receives a signed purchase order.

The document is m, and the supplier sends signature s together with a certificate containing public key pk. The buyer’s system performs the following checks:

1. It parses the certificate and builds a chain to a trusted organisational or public root.
2. It verifies the issuer signatures in that chain.
3. It checks the certificate’s dates, subject identity and permitted key usage.
4. It checks revocation status according to organisational policy.
5. It computes H(m) from the received document.
6. It applies the signature verification operation using pk.
7. It accepts the signature only if verification succeeds and all certificate checks pass.

Suppose an attacker changes the quantity in the purchase order. The altered document produces a different digest, H(m'), where m' ≠ m. The original signature was created for H(m), so verification should fail. This example demonstrates integrity, but the business system must still verify that the certificate subject represents the correct supplier and that the signer was authorised to approve the order.

11. Applied Case: Certificate Failure in an Online Service

This is an illustrative case.

Background

A medium-sized online retailer operates several web servers. Its TLS certificates are issued by an intermediate CA and are renewed manually.

Problem

One certificate expires during a holiday sales period. Customers receive browser warnings, and some automated payment integrations reject the connection. The organisation also discovers that it cannot quickly determine which other certificates are close to expiry.

Analysis

The immediate failure is certificate expiration, but the deeper problem is weak lifecycle management. Certificate ownership was unclear, renewal dates were recorded in separate spreadsheets and no central monitoring existed. The incident also reveals that the organisation had not tested its intermediate certificate deployment and had no documented emergency renewal procedure.

Approach and Solution

The security team creates a certificate inventory containing the certificate subject, SANs, issuer, owner, system, expiry date, key type, purpose and renewal method. It deploys automated discovery and alerts well before expiry. Renewal is integrated with the change-management process, and certificates are installed through controlled automation. Private keys are stored with appropriate operating-system permissions or in an HSM where justified. The team tests complete certificate chains in staging and documents revocation procedures.

Outcome

The retailer restores service, reduces the likelihood of future expiry incidents and gains visibility into certificate ownership. Automation does not remove the need for governance: unusual certificates, high-risk keys and trust-store changes still require review.

Learning Points

• Certificate validity is an operational responsibility, not merely a cryptographic property.
• Inventory and ownership are essential PKI controls.
• Renewal, revocation and key rotation should be tested before an emergency.
• Monitoring should cover both certificates and the trust chains on which they depend.

12. Security, Ethical and Regulatory Considerations

Private-key compromise can allow an attacker to impersonate a subject until the certificate is revoked or expires. Key protection therefore requires least privilege, strong authentication, secure backups and audit logging.

CA operators have significant power. A dishonest, compromised or careless CA could issue a certificate for an unauthorised identity. Certificate transparency systems help detect publicly trusted certificates that may have been issued incorrectly. Organisations should monitor relevant transparency logs where appropriate.

Identity verification must be proportionate and lawful. Collecting excessive identity documents creates privacy risk. PKI programmes should follow data-protection principles, retention requirements and applicable electronic-signature legislation.

Digital signatures should not be used to conceal accountability or create misleading evidence. Audit logs must be protected from unauthorised alteration, and signing systems should clearly show what was signed, by whom, when and under which policy. Time evidence may require trusted timestamping, especially when certificates may later expire.

13. Contemporary Developments and Best Practices

Current practice increasingly emphasises:

• automated certificate discovery and renewal;
• short-lived certificates that reduce exposure when revocation is difficult;
• hardware-backed keys and cloud key-management services;
• certificate transparency and continuous monitoring;
• modern TLS configurations and removal of obsolete algorithms;
• machine identities for containers, workloads and Internet of Things devices;
• zero-trust architectures in which certificates support workload authentication;
• preparation for post-quantum cryptography.

Quantum computers capable of breaking widely used public-key systems are not yet a routine operational reality, but organisations should maintain cryptographic inventories and plan migration. Replacing algorithms in large PKI environments can take years.

Recommended practices include:

1. Use approved algorithms, key sizes and certificate profiles.
2. Protect private keys with hardware or hardened key stores where risk justifies it.
3. Maintain a complete, accurate certificate inventory.
4. Assign an owner and business purpose to every certificate.
5. Automate renewal while retaining approval and audit controls.
6. Monitor expiry, unexpected issuance and trust-store changes.
7. Define and test compromise, revocation and recovery procedures.
8. Separate root, intermediate and issuing CA duties.
9. Keep root CA keys offline whenever practical.
10. Train administrators to distinguish certificate validity from genuine identity and authorisation.

Challenges and Limitations

PKI can be complex to design and costly to operate. Errors in name fields, chain construction, clock settings, key permissions or renewal automation can interrupt services. Revocation is imperfect because status information may be delayed or inaccessible. Trust stores may contain outdated or inappropriate roots. A valid certificate also does not prove that a website is honest, that a person is authorised to act or that a signed document is accurate.

Digital signatures cannot compensate for poor endpoint security. If an attacker controls a user’s signing device or steals the private key, the attacker may create valid signatures. Strong authentication, secure platforms, separation of duties and human review remain necessary.

Chapter Summary

Digital signatures use private keys to sign data and public keys to verify it. Hash functions make signing efficient and provide a mechanism for detecting changes. Signatures support integrity and evidence of key possession, while authentication depends on trustworthy binding between a public key and an identity. Non-repudiation is a legal and evidential conclusion that depends on more than mathematics.

Digital certificates bind public keys to subjects and are commonly organised into chains from end-entity certificates through intermediate CAs to trusted roots. Certificate validation includes chain, time, name, key-usage, policy and revocation checks. PKI includes CAs, registration authorities, repositories, validation services, key-management systems, policies and operational procedures.

Effective PKI management covers the complete lifecycle: planning, issuance, deployment, monitoring, renewal, revocation, rotation and destruction. Secure key custody, automation, inventory, governance and incident response are essential. Certificates are powerful controls, but they must be integrated with identity management, authorisation, endpoint security, legal requirements and organisational accountability.

Key Terms

Digital signature: Cryptographic value used to verify a message and its signer’s private-key control.

Hash function: Algorithm that maps data to a fixed-length digest.

Message digest: Hash output representing the supplied data.

Public key: Key distributed for verification or encryption.

Private key: Secret key used for signing or decryption.

Digital certificate: Signed structure binding a public key to an identity or subject.

X.509: Standard format widely used for public-key certificates.

Certificate authority: Trusted entity that issues and revokes certificates.

Registration authority: Entity that validates certificate requests for a CA.

Root CA: Trust anchor at the top of a certificate hierarchy.

Intermediate CA: CA certified by a root or another CA.

Trust chain: Ordered path linking an end-entity certificate to a trusted root.

CRL: Signed list of revoked certificate serial numbers.

OCSP: Protocol for obtaining certificate status information.

HSM: Hardware security module that protects keys and performs cryptographic operations.

Key usage: Certificate extension specifying permitted cryptographic purposes.

Certificate lifecycle: Processes for certificate creation, use, renewal, revocation and destruction.

Certificate transparency: Public logging mechanism for monitoring issued certificates.

Non-repudiation: Evidence supporting the claim that a signer cannot plausibly deny an action.

Review Questions

5 Short Answer Questions

1. What security services can digital signatures support, and which major service do they not provide?
2. Why is a hash function used when signing a large document?
3. What is the role of an intermediate CA?
4. State two differences between a CRL and OCSP.
5. Why must a private key be protected throughout its lifecycle?

5 Long Answer Questions

1. Explain the complete process of creating and verifying a digital signature.
2. Describe the fields and validation checks commonly found in an X.509 certificate.
3. Explain how a certificate chain establishes trust from an end entity to a root CA.
4. Discuss the lifecycle controls required for enterprise certificate management.
5. Evaluate the claim that a valid digital signature automatically provides non-repudiation.

3 Analytical / Application Questions

1. A company discovers an unauthorised certificate for one of its public domains. Analyse the immediate technical, governance and incident-response actions it should take.
2. Design a PKI approach for an organisation with public web servers, employee identities and thousands of IoT devices. Justify your choices of hierarchy, key protection, validation and automation.
3. A signed contract verifies mathematically, but the signer’s private key was stolen two weeks earlier. Analyse what conclusions can and cannot be drawn about the contract’s authenticity and legal evidential value.

Multiple Choice Questions with Answers

Question 1

Which security property is directly supported when a recipient detects that a signed message was modified?

A. Confidentiality

B. Integrity

C. Availability

D. Data compression

Correct Answer: B. Integrity

Question 2

Which key is used to create a conventional digital signature?

A. The signer’s private key

B. The recipient’s private key

C. The signer’s public key

D. The CA’s public key

Correct Answer: A. The signer’s private key

Question 3

What is the primary purpose of a digital certificate?

A. To compress a message

B. To store a user’s password

C. To bind a public key to an identity or subject

D. To replace all access-control decisions

Correct Answer: C. To bind a public key to an identity or subject

Question 4

Which component normally acts as the trust anchor in a PKI hierarchy?

A. End-entity certificate

B. Root CA

C. OCSP response

D. Certificate repository

Correct Answer: B. Root CA

Question 5

What does OCSP commonly provide?

A. A certificate’s current status

B. A new private key for every message

C. A replacement for hashing

D. A method for encrypting hard drives

Correct Answer: A. A certificate’s current status

Question 6

A certificate contains a public key and is within its validity dates, but its subject name does not match the requested website. What should a browser normally do?

A. Accept it because the dates are valid

B. Accept it if the page is popular

C. Reject it for hostname mismatch

D. Convert it into a root certificate

Correct Answer: C. Reject it for hostname mismatch

Question 7

Which statement best describes a root CA certificate?

A. It is always issued by an end entity

B. It is commonly configured as a trust anchor

C. It can only be used for email encryption

D. It contains every user’s private key

Correct Answer: B. It is commonly configured as a trust anchor

Question 8

Why are private keys commonly protected using an HSM in high-value PKI environments?

A. To make certificates publicly searchable

B. To provide tamper-resistant key protection and cryptographic operations

C. To eliminate the need for certificate expiry

D. To make hashing reversible

Correct Answer: B. To provide tamper-resistant key protection and cryptographic operations

Question 9

What is a major operational benefit of automated certificate renewal?

A. It prevents all private-key compromises

B. It removes the need for trust stores

C. It reduces service outages caused by forgotten expiry dates

D. It makes certificate validation unnecessary

Correct Answer: C. It reduces service outages caused by forgotten expiry dates

Question 10

Which statement about digital signatures is most accurate?

A. They provide confidentiality automatically

B. They prove that the signed content is factually correct

C. They can support integrity and signer authentication when the public-key binding is trusted

D. They remain trustworthy even when the private key is known to be compromised

Correct Answer: C. They can support integrity and signer authentication when the public-key binding is trusted