Study Guide
Public Key Infrastructure and Digital Certificates
How anyone knows whose public key is whose: certificate authorities, what an X.509 certificate contains, root, intermediate and leaf certificates, trust anchors, how a browser validates a chain, self-signed certificates, certificate signing requests, the Common Name and the Subject Alternative Name, and what the DigiNotar compromise showed.
Lesson 6.5 Cryptography & PKI
Asymmetric encryption works only if you know that a public key really belongs to the person or website you mean. This lesson works out how that is established, how browsers check it, and where the system can fail.
Stage: Think
A stranger at the door
Think it through
A stranger at your door says they are from the gas company and shows an identity card. You have never met them. What makes the card worth trusting, if anything?
- Hint 1: Who made the card?
- Hint 2: Could anyone make one like it?
Show what happens
Only that you trust whoever issued it, that it is hard to forge, and that you check it properly. A website proves who it is in the same way: a trusted organisation vouches for it.
Think it through
Show the answer
Answer: C. A trusted party vouches.
That someone you already trust has signed a statement saying the key belongs to the bank.
Stage: Explain
The idea
A digital certificate is a document that binds a public key to an identity, signed by an organisation that others trust.
It says, in effect: “This public key belongs to www.harbourbank.example. Signed, Example Issuing CA.” The organisation that signs is a certificate authority (CA). Because the statement is digitally signed, anyone can check that it really came from that CA and has not been altered.
A passport is a fair comparison. You do not know the traveller, but you trust the government that issued the passport, and the passport is hard to forge. The passport binds a face to a name; a certificate binds a public key to a name.
Check your understanding
Show the answer
Answer: B. A public key and a name
A public key and an identity, such as a website’s name, signed by a certificate authority.
Where the comparison stops. A passport office checks a person’s identity thoroughly. For the most common kind of web certificate, the CA checks only that the applicant controls the domain name. And a certificate is not secret: the server gives a copy to everyone who connects. Holding a copy proves nothing. What proves identity is holding the matching private key.
Stage: Predict
What is inside a certificate
Think it through
If you were designing a certificate, what would you put on it so that a browser could decide whether to trust it?
- Hint 1: What does a passport show, and what would a website need instead of a photograph?
Show what happens
Who it is for and which names, who issued it, when it is valid, the public key itself, a serial number, what the key may be used for, and the issuer’s signature over all of it.
Certificates follow a standard format called X.509. The main fields:
| Field | What it holds |
|---|---|
| Subject | Who the certificate was issued to. |
| Subject Alternative Name (SAN) | The names the certificate is valid for, such as www.harbourbank.example. |
| Issuer | The CA that signed it. |
| Validity | A “not before” and a “not after” date. Outside them, the certificate is not accepted. |
| Public key | The subject’s public key, and the algorithm it is for. |
| Serial number | A number unique within that CA, used to identify the certificate if it is revoked. |
| Permitted uses | What the key may be used for, such as proving a web server’s identity, and whether it may sign other certificates. |
| Signature | The issuing CA’s digital signature over everything above. |
The private key is not in the certificate and is never sent to anyone.
Check your understanding
Show the answer
Answer: C. No: it is never sent.
No. The certificate holds the public key; the private key stays with its owner and is never sent.
Stage: Predict
Certificate authorities
Think it through
What two things must a certificate authority get right, one before issuing and one at all times?
- Hint 1: What could go wrong at the moment of issuing, and afterwards?
Show what happens
Before issuing, check that the applicant is entitled to the name; at all times, protect its own signing key, because whoever can use it can issue certificates for anything.
A CA has two duties. Before issuing, it must check that the applicant is entitled to the name. Afterwards, it must protect its own signing key, because anyone who can use that key can issue certificates in the CA’s name.
Public and private CAs
- A public CA (the Security+ objectives say third-party) is one whose root certificate is already trusted by operating systems and browsers. Its certificates work for any visitor in the world. Public CAs must follow published industry rules and are audited.
- A private CA is one an organisation runs for itself, to issue certificates for internal servers, staff and devices. It costs little and the organisation controls it, but only devices configured to trust it will accept its certificates. A visitor’s or contractor’s unmanaged laptop will show warnings.
Check your understanding
Show the answer
Answer: A. Not by default.
Not by default: only devices configured with the company’s root certificate trust what its private CA issues.
Stage: Predict
Root, intermediate and leaf certificates
Certificates come in chains. A certificate chain, also called a chain of trust, runs from a website’s own certificate up to a root, and each certificate in it is signed by the one above.
Think it through
The bank’s certificate is signed by a CA. Who vouches for that CA? And who vouches for them?
- Hint 1: Can the chain go on for ever?
Show what happens
Each is signed by the one above, up to a root that signs itself. The chain has to stop somewhere, and the diagram shows where.
Read from the top. Trust starts in the device’s own trust store and passes down through signatures. All names are fictional.
Trust store on Alice’s device
A list of root certificates installed with the operating system or browser. Each one is a trust anchor.
Root certificate
Example Root CA
The top of the chain. Used rarely, and only to sign intermediate CA certificates.
Signed by: itself (self-signed)
Private key kept: offline, in a hardware security module
Intermediate CA certificate
Example Issuing CA 1
Signs the certificates issued to customers, day to day.
Signed by: Example Root CA
Private key kept: online, in a hardware security module
Leaf certificate (end-entity)
www.harbourbank.example
Sent by the web server to every visitor. It cannot sign other certificates.
Signed by: Example Issuing CA 1
Private key kept: on the web server
A chain may contain more than one intermediate. The idea is the same: each certificate is signed by the one above.
Why the root is trusted
Follow the signatures upwards and you reach the root, which is signed by itself. A self-signature proves nothing: anyone can create a certificate that vouches for itself.
A root certificate is trusted for one reason only: it is already in the device’s trust store. A certificate held there is called a trust anchor. The Security+ objectives call it the root of trust. The makers of operating systems and browsers decide which roots go into their stores, through published programmes with audit requirements, and they can remove one.
So the trust in a chain does not come from mathematics alone. It comes from a configuration decision: somebody put that root in that store.
Check your understanding
Show the answer
Answer: B. It is in the trust store.
Because it is already in the device’s trust store. A self-signature on its own proves nothing.
Why intermediates exist
A root key is extraordinarily valuable. If it were stolen, every certificate beneath it would be worthless, and replacing a root on billions of devices takes years. So the root’s private key is kept offline, in secure hardware, and is brought out only to sign a few intermediate CA certificates. The intermediates do the daily work. If an intermediate’s key is compromised, that intermediate can be revoked and replaced without touching the root.
Stage: Predict
How a certificate is validated
Think it through
Before sending anything private, what should Alice’s browser check about the bank’s certificate?
- Hint 1: Think about the name, the dates and the signatures.
Show what happens
That the name matches, that it is in date, that each signature up the chain is valid back to a root in the trust store, that the server holds the private key, and that it has not been revoked.
Alice types https://www.harbourbank.example into her browser. Before any private data is sent, the browser checks the server’s certificate.
Eight checks, made in a fraction of a second. If any one fails, the browser shows a warning instead of the page. The bank is fictional.
Server
Step 1 of 8: Send the certificates
The server sends its leaf certificate and the intermediate CA certificate that signed it.
Browser
Step 2 of 8: Build the chain
The leaf names its issuer; the intermediate names its issuer. The browser looks in its trust store for that root. If no path ends at a trust anchor, the certificate is not trusted.
Browser
Step 3 of 8: Verify each signature
The intermediate’s public key must verify the signature on the leaf. The root’s public key must verify the signature on the intermediate. A forged or altered certificate fails here.
Browser
Step 4 of 8: Check the dates
Every certificate in the chain must be inside its validity period today.
Browser
Step 5 of 8: Check the name
The name Alice asked for, www.harbourbank.example, must appear in the leaf certificate’s Subject Alternative Name. A valid certificate for a different name is no use.
Browser
Step 6 of 8: Check the permitted uses
The leaf must be allowed to identify a web server, and the intermediate must be allowed to act as a certificate authority.
Technical detail: Without this check, the holder of any ordinary leaf certificate could sign certificates for other sites.
Browser
Step 7 of 8: Check for revocation
Where the browser checks, it confirms that the CA has not withdrawn the certificate early.
Technical detail: Revocation checking has practical limits, described in the next lesson.
Browser and server
Step 8 of 8: Confirm the server holds the private key
A certificate is public and can be copied. During the connection handshake the server must prove, with a signature, that it holds the private key matching the certificate.
When every check passes, the browser knows it is talking to a server entitled to that name. It knows nothing else about the site.
Stage: Predict
Self-signed certificates
A self-signed certificate is signed with its own private key instead of a CA’s. No third party vouches for it.
Think it through
Show the answer
Answer: B. Encrypts; proves nothing.
It can still encrypt, but nothing proves the site’s identity, because nobody vouches for it.
- Every root certificate is self-signed. It is trusted because it is in the trust store.
- A leaf certificate, such as a website’s own, that is self-signed has no chain to follow, so browsers warn. It still allows encryption; what it cannot do is prove identity.
Self-signed certificates are reasonable for testing and for some closed systems where the certificate is installed by hand. The danger is habit: staff who are taught to click through certificate warnings for an internal tool will click through the same warning when it is caused by an attacker.
Stage: Predict
Requesting a certificate: the CSR
A certificate signing request (CSR) is how an applicant asks a CA for a certificate.
Think it through
Show the answer
Answer: C. No, never.
No. The request carries the public key and the names; the CA signs with its own key.
- Generate a key pair on the server that will use it. The private key stays there.
- Create the CSR. It contains the public key and the names requested, and it is signed with the private key, which shows that the applicant holds it.
- Send the CSR to the CA. The private key is not sent.
- The CA validates the request, for example by asking the applicant to prove control of the domain.
- The CA issues the certificate, signed with its intermediate CA key.
- Install the certificate on the server, together with the intermediate CA certificate.
The important point is step 3. The CA never needs the applicant’s private key and should never be given it.
Stage: Explain
Common Name and Subject Alternative Name
Older certificates put the website’s name in a field of the Subject called the Common Name (CN). It could hold only one name and was free text, which made it ambiguous.
The Subject Alternative Name (SAN) is an extension that holds a list of names, each with a stated type, such as a DNS name.
Modern browsers match the requested name against the SAN and ignore the Common Name. A certificate whose name appears only in the CN is rejected. The current internet standard for this check says the Common Name must not be used to identify a service.
Check your understanding
Show the answer
Answer: B. No: only names one level down.
No. A wildcard covers names one level down, such as www and payments, but not the bare domain or deeper names.
- A SAN can list several names, such as
harbourbank.exampleandwww.harbourbank.example. - A wildcard name such as
*.harbourbank.examplecovers any name one level down:www.harbourbank.exampleandpayments.harbourbank.example, but notharbourbank.exampleitself and nota.b.harbourbank.example. Wildcards are convenient, and they mean one stolen private key exposes every covered name.
Do not confuse: Common Name and Subject Alternative Name
- Common Name (CN)
- An older, single, free-text field in the Subject. Still present in many certificates; no longer used to match a website’s name.
- Subject Alternative Name (SAN)
- The extension that lists every name the certificate is valid for. This is what clients check.
Stage: Predict
What a certificate does not tell you
Think it through
Show the answer
Answer: B. Yes.
Yes. The criminal controls that domain, so the certificate is valid and the padlock appears.
A certificate authority does not certify that a website is safe.
A valid certificate tells you that the server controls the private key for a certificate issued to that name. That is all. It does not tell you that the site is honest, that its owner is who you assume, or that its pages are free of malware.
An attacker who registers harbourbnak.example controls that domain, can obtain a perfectly valid certificate for it, and will show the same padlock as the real bank. Social Engineering and Phishing describes how such lookalike names are used.
Go deeper Domain, organisation and extended validation
Public CAs issue three levels of certificate, which differ in how much the CA checks.
- Domain validated (DV): the CA confirms control of the domain name only. Issued in minutes, often automatically and free. The great majority of web certificates.
- Organisation validated (OV): the CA also confirms that the named organisation exists.
- Extended validation (EV): the CA follows a stricter, documented process to confirm the organisation’s legal identity.
All three give the same encryption. Browsers no longer display EV certificates differently in the address bar, so most visitors cannot tell the levels apart. None of the three is a statement about whether the organisation can be trusted.
Stage: Predict
When a certificate authority fails: DigiNotar
Browsers accept any certificate that chains to any trusted root. That makes every trusted CA a single point of failure for the whole web.
DigiNotar was a Dutch certificate authority, trusted by all major browsers and used by the Dutch government. In 2011 an intruder gained control of its certificate-issuing systems and issued fraudulent certificates for domains the intruder did not own, including Google’s. The investigation commissioned by the Dutch government identified more than 500 fraudulent certificates. A fraudulent certificate for Google was used to intercept the connections of a very large number of internet users, most of them in Iran: their browsers showed a valid padlock while someone in the middle read their traffic.
Think it through
A trusted CA has issued fraudulent certificates for famous websites. What could browser makers do about it?
- Hint 1: What made the CA trusted in the first place?
Show what happens
Remove that CA’s roots from their trust stores, so that nothing it issued is trusted any more, including its legitimate certificates.
Once the fraud was discovered, browser and operating system makers removed DigiNotar’s roots from their trust stores. Every certificate DigiNotar had ever issued stopped working, including legitimate ones used by Dutch government services. The company was declared bankrupt within weeks.
What the case shows:
- A certificate is only as trustworthy as the least careful CA in the trust store.
- A CA’s signing systems are among the most valuable targets there are, which is why their keys belong in hardware security modules.
- The remedy was a trust-anchor decision: removing a root from the store. That is the same mechanism that made the root trusted in the first place.
It also led to stronger defences, including public, append-only logs of every certificate that public CAs issue, so that a certificate issued without a domain owner’s knowledge can be spotted.
Certificates are visible on any computer. On Windows, the Certificate Manager tool (certmgr.msc) shows the stores for the signed-in user, including the Trusted Root Certification Authorities store. In a browser, selecting the padlock or site-information icon shows the certificate for the current site, its chain and its dates. Looking is harmless. Adding a root certificate to a trust store is not: it tells the device to trust everything that root signs, so it should happen only through an organisation’s managed process.
Stage: Explain
Security+ terminology
The CompTIA Security+ SY0-701 exam objectives (objective 1.4) list under Certificates: certificate authorities, certificate revocation lists (CRLs), Online Certificate Status Protocol (OCSP), self-signed, third-party, root of trust, certificate signing request (CSR) generation and wildcard.
“Third-party” is the objectives’ word for a certificate from a public CA, and “root of trust” for the trust anchor at the top of a chain. The objectives do not name X.509, intermediate CAs, the SAN or DigiNotar.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: B. The habit hides real attacks.
They will click through a real interception warning in the same way. Fix the certificate, for example with the company’s own CA.
Apply it
Show the answer
Answer: C. A lost root is hard to replace.
A stolen root key would make everything beneath it worthless, and replacing a root takes years; an intermediate can be replaced far more easily.
Apply it
Show the answer
Answer: C. Reject it.
Reject it: modern browsers match the name against the Subject Alternative Name and ignore the Common Name.
Stage: Check
Check your understanding
These questions come from the approved revision bank. They were approved under owner-authorised delegated review: the site owner authorised the review and did not read each question individually.
Show answer
Answer: A public key and the identity of its subject
A certificate binds a public key to a subject identity and is signed by a certificate authority. A certificate is public and holds no private key, it carries no judgement about a site’s safety, and it does not contain the symmetric keys used to protect a session.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: Leaf, intermediate CA, root
A chain runs from the leaf, or end-entity, certificate through one or more intermediate CA certificates to a root certificate. The root signs the intermediate and the intermediate signs the leaf, so that the root’s key can be kept offline and used rarely.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: It is already in the trust store that the browser relies on
A root is self-signed and is trusted because it has been placed in the relying party’s trust store as a trust anchor, not because of its own signature. Nothing sits above a root to sign it, a self-signature proves nothing about its owner, and a root arriving from a website would not be trusted for that reason.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: The validity dates of the certificate; That the requested name matches the certificate; Each signature in the chain, up to a trust anchor
A client checks each signature in the chain up to a trust anchor, the validity dates, that the certificate is permitted for the purpose, that the requested name matches, and revocation status where it is checked. Validation says nothing about a site’s content, and a server proves that it holds its private key without ever sharing it.
Revision sources: Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: It is self-signed, so nothing the browser already trusts vouches for it
A self-signed certificate is signed with its own key, so nothing outside it vouches for the identity, and a browser has no chain to a trust anchor to follow. Expiry and revocation are different conditions with different warnings, and being self-signed does not make a certificate a trusted root: a root is trusted because it is in the trust store.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: The laptop’s trust store does not contain the company’s root
A private CA is trusted only by devices configured to trust it, and a root is trusted because it is in the trust store. The company’s managed devices have its root installed; the contractor’s laptop does not, so no chain reaches a trust anchor. A private CA exists to serve internal names, and every root is self-signed.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: A certificate issued by a public, third-party CA
A public CA is trusted by default in operating systems and browsers, while a private CA is trusted only by devices configured to trust it, and nothing outside a self-signed certificate vouches for the identity. Parents’ own devices already trust public CAs, which are also called third-party CAs, so only that certificate is accepted without setup. A certificate signing request is an application for a certificate, not a certificate.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: The applicant’s private key
A certificate signing request (CSR) contains the applicant’s public key and requested identity and is signed with the applicant’s private key, which never leaves the applicant. The certificate authority therefore never needs, and should never receive, the private key.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: A name-mismatch warning: the requested name is not in the SAN
Modern clients match a website’s name against the Subject Alternative Name (SAN) extension, and validation includes checking that the requested name matches. The name requested is not listed, and a listed name does not cover its subdomains, so the browser warns even though the chain is sound. Expiry depends on dates, not on how many names are listed.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: payments.harbourbank.example
A wildcard name covers any name one level down, so *.harbourbank.example covers payments.harbourbank.example. It does not cover the bare domain harbourbank.example, which has nothing in the wildcard’s place, and it does not cover a name two levels down such as a.payments.harbourbank.example. A name under a different domain is not covered at all.
Revision sources: Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: False
False. A certificate shows control of a name and a key, not that a website or its operator is safe. A fraudulent site can obtain a valid certificate for a domain it controls, so the padlock describes the connection and the name, not the intentions of whoever runs the site.
Revision sources: Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Show answer
Answer: Obtain certificates that browsers accept for sites the attacker does not control
Because clients accept any certificate that chains to a trust anchor, a compromised CA can be used to issue fraudulent certificates for names its attacker does not control, as happened to DigiNotar in 2011. A CA never receives its customers’ private keys, since a CSR does not contain one, so it cannot leak them or decrypt their traffic; and trust stores are changed by browser and operating system vendors, who removed DigiNotar.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Public Key Infrastructure and Digital Certificates (Supplementary Study Guide explanation)
Study and revision
Practise through the Cryptography & Data Protection topic. Questions cover what a certificate binds, the order of a chain, why a root is trusted, the checks in validation, self-signed certificates, private and third-party CAs, what a CSR contains, name matching in the SAN, which names a wildcard covers, what a certificate does not show, and what a compromised CA allows; eight flashcards recall the main points. Most are learning-only. The questions that have been verified against CompTIA Security+ SY0-701 objective 1.4 are also in the Security+ practice track; that does not mean the lesson covers the whole of an objective, and the lesson does not establish practical experience.
Stage: Consolidate
What to remember
- A certificate binds a public key to a name, signed by a certificate authority; the private key is never in it.
- Chains run from a leaf through intermediates to a root; a root is trusted only because it is in the trust store.
- Browsers check the name, the dates, every signature up to a trusted root, and revocation.
- A CSR carries the public key and names; the private key never leaves the server.
- A valid certificate proves control of a name, not honesty; every trusted CA is a single point of failure.
Key terms
- PKI (Public key infrastructure)
The certificate authorities, certificates, software and policies that bind public keys to identities and manage certificates through their lives.
- Certificate authority (CA)
An organisation that issues digital certificates, signing each one to vouch that a public key belongs to the named subject.
- Digital certificate
A document, signed by a certificate authority, that binds a public key to the identity of its subject. The standard format is X.509.
- Trust anchor
A root certificate already held in a device’s trust store, from which trust in a certificate chain starts.
- Certificate chain
The sequence of certificates from a leaf, through one or more intermediate CAs, to a root, each signed by the one above it.
- CSR (Certificate signing request)
A request sent to a certificate authority, containing the applicant’s public key and requested identity and signed with the applicant’s private key.
Common misunderstandings
It means the connection is encrypted and the certificate matches the name in the address bar. Fraudulent sites have padlocks too.
Nothing is above a root. It signs itself, and it is trusted because it is in the device’s trust store.
A CSR contains only the public key. The private key should never leave the system that generated it.
Clients check the Subject Alternative Name. A name that appears only in the Common Name is not accepted.
Further reading
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile: the certificate format and how a chain is validated.
- RFC 9525: Service Identity in TLS: why the name is checked in the Subject Alternative Name.
- NCSC: Design and build a privately hosted Public Key Infrastructure: principles for running a private CA.
- Google Online Security Blog: An update on attempted man-in-the-middle attacks: Google’s 2011 statement on the fraudulent DigiNotar certificate.
- Microsoft Learn: How to view certificates with the MMC snap-in: viewing the Windows certificate stores.
- CompTIA Security+ SY0-701 exam objectives (PDF): objective 1.4.
Lesson sources and acknowledgements
Sources and scope
- Covered in Session 9 (see the Session 9 Learning Log): PKI and certificate authorities, public and private CAs and the DigiNotar compromise; digital certificates and X.509, public keys and subject identities; root certificates and trust anchors, root, intermediate and leaf certificates, and certificate chains and their verification; self-signed certificates and certificate signing requests; and the Common Name and the Subject Alternative Name. Windows Certificate Manager and the Microsoft Edge certificate store were among the tutor’s demonstrations; what was shown is not recorded.
- Accuracy qualifications: a root certificate is trusted through trust-anchor configuration, not through its own signature; a CA does not certify that a website is safe; the SAN, not the Common Name, is the field used to match a website’s name.
- Independently checked: certificate contents and path validation against RFC 5280; name matching against RFC 9525; the DigiNotar account against the browser makers’ statements of 2011 and the report of the investigation commissioned by the Dutch government; and the Security+ wording against the published SY0-701 objectives. These are external references, not course evidence.
- Supplementary explanation: every definition, the passport comparison and its limits, the field table, the chain diagram, the reasons for intermediates, the eight validation checks, the CSR steps, wildcard matching, the validation levels, the account and lessons of DigiNotar, the practical note and the misunderstandings. These were developed afterwards and are my explanations, not the tutor’s words. The diagrams are original.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the opening questions about a stranger’s identity card, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. The bank and the certificate authorities in the examples are fictional, and DigiNotar is a real, documented case. I have not issued, installed or validated certificates as part of this lesson.
Cryptography that uses a mathematically related pair of keys: a public key that can be shared and a private key that is kept secret.
The sequence of certificates from a leaf, through one or more intermediate CAs, to a root, each signed by the one above it.
A certificate authority withdrawing a certificate before its expiry date, for example because its private key was compromised.
An older, single, free-text field in a certificate’s Subject that used to hold a website’s name.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
A signed list, published periodically by a certificate authority, of the serial numbers of certificates it has revoked.
A request sent to a certificate authority, containing the applicant’s public key and requested identity and signed with the applicant’s private key.
A document, signed by a certificate authority, that binds a public key to the identity of its subject. The standard format is X.509.
A value produced with a private key that only the signer should hold, which anyone can check with the matching public key to confirm who signed some content and that it has not changed since.
The system that translates domain names into IP addresses. It commonly uses port 53 over UDP and TCP.
Transforming data with a cipher and a key so that it cannot be read without the right key. Decryption reverses it.
A certificate authority whose certificate is signed by a root, and which signs the certificates issued to end users.
The two related keys used in asymmetric cryptography: a public key and a private key. What one does, only the other can undo.
The certificate at the end of a chain, issued to a server, person or device. It cannot sign other certificates.
Malicious software designed to disrupt, damage or gain unauthorised access to devices, networks or data. Ransomware is one type.
A protocol that lets a client ask a certificate authority’s responder for the current status of one certificate.
The software that runs a computer and lets other programs use it. Windows, macOS, Linux, Android and iOS are operating systems.
The certificate authorities, certificates, software and policies that bind public keys to identities and manage certificates through their lives.
A document that sets organisational rules and expectations, defining what is and is not permitted.
A certificate authority that an organisation runs for itself. Only devices configured to trust its root accept the certificates it issues.
The half of a key pair that its owner keeps secret. It decrypts data sent to the owner and creates the owner’s signatures.
A certificate authority whose root certificate is already trusted by operating systems and browsers, so that its certificates are accepted by any visitor.
The half of a key pair that can be given to anyone. It encrypts data for the key’s owner and verifies the owner’s signatures.
The self-signed certificate at the top of a certificate chain.
The certificate extension that lists every name the certificate is valid for. It is the field clients check against the name requested.
A certificate signed with its own private key, so that no third party vouches for the identity in it.
A root certificate already held in a device’s trust store, from which trust in a certificate chain starts.
The list of root certificates that a device, operating system or browser has been set up to trust. A certificate chain is accepted only if it ends at one of them.
A certificate whose name begins with an asterisk, covering any name one level below a domain.
The standard format for digital certificates. It sets out fields such as the subject, the issuer, the validity dates, the public key and the issuer’s signature.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.