Know and understand digital certificate including its purpose and contents

Safety and Security – Digital Certificates

1. How Digital Certificates Fit into the Wider Safety & Security Unit

Digital certificates are one of the technical safeguards listed in Cambridge IGCSE ICT (0417) – Section 8 Safety & Security. They work together with the other controls covered in the unit:

• Physical safety: safe use of equipment, avoiding electrocution.
• E‑safety: responsible Internet use, avoiding phishing and ransomware.
• Data‑protection principles: confidentiality, integrity, availability.
• Password security & two‑factor authentication: certificates provide the cryptographic proof of identity that passwords alone cannot.
• Encryption, firewalls, anti‑malware: certificates supply the public keys used for encryption and for verifying digital signatures.

Understanding certificates therefore helps learners see how trust is established when data is encrypted, signed or exchanged over the Internet.

2. What Is a Digital Certificate?

A digital certificate is an electronic document that binds a public key to the verified identity of a person, organisation or device. It is issued by a trusted third‑party called a Certificate Authority (CA) and is used in security protocols such as SSL/TLS (HTTPS), S/MIME (secure e‑mail), VPNs and code‑signing.

3. Purpose of a Digital Certificate

• Authentication: proves the identity of the holder.
• Encryption: supplies a public key that others can use to encrypt data for the holder.
• Integrity & Digital Signatures: together with a private key, enables creation of a digital signature that guarantees data has not been altered.
• Non‑repudiation: the holder cannot deny having signed a message or transaction.

4. Key Components of an X.509 Digital Certificate

5. How Certificates Enable Encryption & Digital Signatures

• Encryption: A sender encrypts data with the recipient’s public key (found in the certificate). Only the recipient’s private key can decrypt it.
• Digital signatures: The sender creates a hash of the message, encrypts the hash with their private key, and attaches the signature. The receiver uses the sender’s public key (from the sender’s certificate) to verify the signature and thus the integrity of the message.

Example – S/MIME e‑mail:

1. Sender signs the e‑mail with their private key.
2. Recipient’s mail client checks the signature using the sender’s public key from the sender’s certificate.
3. If the signature is valid, the e‑mail is both authentic and untampered.

6. Certificate Lifecycle

1. Key‑pair generation – Applicant creates a public‑private key pair.
2. Certificate Signing Request (CSR) – Public key + identity details are packaged into a CSR and sent to a CA.
3. Verification – CA checks the applicant’s identity (documents, domain ownership, etc.).
4. Issuance – CA creates the certificate, signs it, and returns it.
5. Deployment – Certificate is installed on a server, e‑mail client, VPN gateway, etc.
6. Renewal – Before expiry, a new CSR is generated and the process repeats.
7. Revocation – If the private key is compromised or the holder leaves the organisation, the CA adds the certificate to a Certificate Revocation List (CRL) or marks it as revoked via OCSP (Online Certificate Status Protocol).
8. Expiration – After the validity period ends, the certificate is no longer trusted.

7. Trust Hierarchy (Certificate Chain)

Clients do not trust a leaf certificate directly. They verify a chain of trust:

• Root CA: Self‑signed certificate pre‑installed in operating systems and browsers.
• Intermediate CA(s): Issued by the root; they issue leaf certificates and allow flexible management.
• Leaf (Server/Client) Certificate: The certificate presented to users.

8. Trust Stores – How Clients Know Which CAs to Trust

• Browser/OS trust store: A list of root CA certificates that come pre‑installed (e.g., Microsoft Trusted Root Program, Mozilla Root Store).
• Adding a private CA: In an enterprise, the administrator manually imports the private CA’s root certificate into the devices’ trust store.
• Removing/Updating: Trust stores are updated via OS or browser updates; outdated or compromised roots are removed.

9. Algorithms Used in Certificates & Deprecation

Algorithm deprecation: SHA‑1 and MD5 are no longer trusted for signatures because of collisions. Modern certificates must use SHA‑256 or stronger.

10. Types of Certificate Authorities

• Public CA: Commercial or non‑profit organisations (e.g., DigiCert, Let’s Encrypt) whose root certificates are pre‑installed in browsers.
• Private/Enterprise CA: Operated within a company or institution for internal services. Trust is established by manually adding the private CA’s root certificate to the organisation’s devices.

11. Typical Uses of Digital Certificates

• HTTPS (SSL/TLS): Secures web browsing – the server presents its certificate, the browser validates the chain, then a secure session is created.
• S/MIME e‑mail: Provides confidentiality (encryption) and authenticity (digital signatures) for e‑mail messages.
• VPN & SSH: Certificates replace passwords for strong, mutual authentication.
• Code‑signing: Developers sign software; users can verify the signature to ensure the code has not been tampered with.
• IoT devices: Certificates authenticate devices to cloud services.

12. Common Issues & How to Recognise Them

• Expired certificate: Browser shows “certificate has expired”.
• Domain mismatch: Certificate’s subject does not match the website’s URL.
• Untrusted CA: Issuing CA is not in the client’s trust store (common with self‑signed certificates).
• Revoked certificate: OCSP/CRL indicates the certificate is no longer valid.
• Mixed‑content warning: Secure page loads insecure (HTTP) resources; browsers may block them.
• Weak algorithm: Use of SHA‑1 or RSA 1024 triggers security warnings.

13. Evaluation Checklist – Deciding Whether a Certificate Is Suitable

1. Is the certificate within its validity period?
2. Does the issuer

3. Are the key size and signature algorithm

4. Do the subject name and any subject‑alternative‑names match the service being accessed?
5. Has the certificate been revoked (check CRL or OCSP)?
6. Are the required key‑usage and extended‑key‑usage extensions present (e.g., “TLS Web Server Authentication” for HTTPS)?
7. Is the certificate type appropriate (root, intermediate, leaf, or self‑signed) for the scenario?

14. Exam‑Style Questions (IGCSE Level)

1. Recall (AO1): List four fields that appear in an X.509 digital certificate and state the purpose of each.
2. Application (AO2): Explain, step by step, how a web browser verifies the authenticity of a website’s certificate when a user visits https://www.example.com.
3. Evaluation (AO3): A school wants to secure its internal file‑sharing server. The administrator proposes using a self‑signed certificate. Using the checklist above, evaluate whether this is an appropriate solution and suggest any improvements.

15. Summary

Digital certificates are essential tools for establishing trust on the Internet. By binding a public key to a verified identity, they provide authentication, encryption, integrity, digital signatures and non‑repudiation. Understanding the certificate’s contents, its lifecycle, the chain of trust, trust‑store management, algorithm choices and common pitfalls equips ICT learners to assess and maintain secure digital communications – a key outcome of the Cambridge IGCSE ICT Safety & Security syllabus.