Uit https://www.security.nl/posting/607628/Firefox-extensies+uitgeschakeld+vanwege+verlopen+certificaat#posting607681:
Ik kan het fout hebben, maar zo te zien werkte het zoals ik in de eerstvolgende bijdrage hieronder schrijf.

Voor belangstellenden licht ik eerst toe hoe certificaten, asymmetrische sleutelparen, cryptografische hashes en digitale handtekeningen werken. Om het verhaal niet al te lang te maken ga ik niet in op alle details.

Hash
Een hash (het resultaat van versnijden) is een karakteristieke afgeleide van een of meer bits (meestal een reeks bytes). Die reeks bytes kan vanalles "bevatten", zoals een getal of een PDF document - wat je maar wilt.

Een checksum (optelsom) zou je kunnen zien als een eenvoudig soort hash. Checksums en hashes zijn bedoeld om onbedoelde fouten in data te signaleren. Enkele voorbeelden:
1) Het pariteitsbit in wat duurdere (server-) geheugenmodules. In 1 extra geheugenbit per byte wordt opgeslagen of de som van de 8 bits data even is of oneven. Als daar 1 bit in "omvalt" wordt dat gedetecteerd (meestal leidt dit onder Windows tot een BSOD = Blue Screen Of Death).
2) De "elfproef" in bijvoorbeeld ons BSN (zie https://nl.wikipedia.org/wiki/Burgerservicenummer#11-proef).
3) De twee cijfers tussen de landcode en de bankcode in onze IBAN nummers (zie https://nl.wikipedia.org/wiki/International_Bank_Account_Number#Controlegetal)
Zie https://nl.wikipedia.org/wiki/Controlegetal voor meer voorbeelden.

Cryptografische Hash
Checksums, hashes en gebroken cryptografische hashes zijn uitsluitend geschikt om onopzettelijke wijzigingen of onbedoelde typfouten te detecteren. Bij een niet-gebroken cryptografische hash hoort het onmogelijk te zijn om, gegeven zo'n hash van een reeks bytes, een (iets of totaal) andere reeks bytes te vinden die dezelfde cryptografische hash oplevert. Met onmogelijk wordt bedoeld dat dit niet kan binnen afzienbare tijd met gigantische rekenkracht tot je beschikking.

Digitale handtekening
Een digitale handtekening zou je kunnen "zetten" door een kopie van een bestand te versleutelen en zowel het origineel als de versleutelde versie op je website te plaatsen. Als iemand wil controleren of het bestand niet gewijzigd is, stuur je haar de sleutel. Zij kan dan de versleutelde versie ontsleutelen en vergelijken met het origineel.

Er zijn meerdere problemen met deze aanpak:
1) Iedereen die genoemde sleutel heeft, kan het origineel wijzigen, opnieuw versleutelen en claimen dat dat het origineel is en jij het document op jouw website hebt gewijzigd;
2) Iedereen die "jouw" sleutel heeft kan ook andere documenten namens jou ondertekeken;
3) Een versleutelde kopie van een document kost minstens evenveel opslagruimte en, tijdens transport, bandbreedte. Het ligt dus meer voor de hand om, in plaats van een kopie van het document, een cryptografische hash te gebruiken. Een ontvanger van een document en bijbehorende versleutelde cryptografische hash doet dan het volgende:
a) Bepaalt zelf de cryptografische hash van het document;
b) Ontsleutelt de meegestuurde versleutelde cryptografische hash en vergelijkt deze met het resultaat van a).

Asymmetrische sleutelparen
De in de paragraaf hierboven genoemde sleutel is een symmetrische sleutel, d.w.z. je gebruikt dezelfde sleutel voor versleutelen als ontsleutelen. Denk bijv. aan de sleutel van jouw voordeur of van een geldkistje.

Stel dat een geldkistje twee sloten zou hebben: de eerste om het te vergrendelen en de tweede om het te ontgrendelen - met als eis dat je die sleutels niet kunt verwisselen (elke sleutel past maar in één slot omdat ze een ander baardprofiel hebben). Dit is exact hoe asymmetrische encryptie werkt.

En daar bestaan twee verschillende toepassingen voor:
1) Veilig (versleuteld) ontvangen;
2) Jij kunt de integriteit (ongeschondenheid) van data, bijvoorbeeld een contract, aantonen.

1) Om veilig geld te kunnen ontvangen (ervan uitgaande dat de postbode de geldkist niet kan openbreken) stuur je de ontgrendelde geldkist plus vergrendelsleutel naar degene van wie jij geld tegoed hebt. Als jij de ontgrendelsleutel nooit uit handen gegeven hebt, ben jij immers de enige die het geldkistje kan openmaken. Dus kan de andere partij met een gerust hart het verschuldigde bedrag in het geldkistje stoppen, dit op slot draaien en naar jou terugsturen. De vergrendelsleutel, die we -in dit geval- de public key noemen, kan hij desgewenst bewaren voor een volgende keer.

2) Hier keren we de zaak om en gaan we juist de ontgrendelsleutel weggeven. Daarom noemen we bij deze toepassing die ontgrendelsleutel de public key. Naast dat je het originele document naar een belanghebbende stuurt, stop je een kopie ervan in het geldkistje, of een afdruk van de cryptografische hash van het document. Het kistje doe je op slot met de vergrendelsleutel (die we, in dit geval, de geheime sleutel of private key noemen). Het kistje stuur je, samen met de public key (ontgrendelsleutel), mee naar de belanghebbende. Als die laatste zeker weet dat jij jouw private key (hier de vergrendelsleutel) nooit uit handen geeft, moet jij degene zijn die dit document als laatste gewijzigd kan hebben.

Kortom:
- Als je wilt versleutelen is de vergrendelsleutel jouw public key;
- Als je wilt signeren is de ontgrendelsleutel jouw public key.

Van wie is die public key?
De vraag moet feitelijk luiden: wie is de (enige!) bezitter van de private key horende bij een gegeven public key?

Dat wil je weten omdat in geval 1) hierboven, tijdens verzending door jou, op het postkantoor iemand jouw geldkistje + public key (vergrendelsleutel in dit geval) kan vervangen door haar geldkistje plus haar vergrendelsleutel, en op de terugweg het geld daaruit kan halen (en desgewenst jouw geldkistje, voorzien van een briefje "ik ben jou niks verschuldigd", afgesloten naar jou kan "terug" sturen.

Voor toepassing 2) geldt ook dat een MITM (Man In The Middle) jouw geldkistje + publieke ontgrendelsleutel kan vervangen door haar geldkistje plus haar publieke ontgrendelsleutel, met gewijzigde inhoud natuurlijk.

Voor dit probleem bestaan twee oplossingen:
A) Public keys via een betrouwbare methode overdragen, bijvoorbeeld door elkaar op te zoeken;
B) Een derde partij, die door beide partijen wordt vertrouwd, te laten vaststellen dat een public key van persoon X is (daarmee bedoelen we dat alleen X toegang heeft tot de private key waar bedoelde public key complementair mee is).

Digitale certificaten
Omdat methode A) hierboven "niet schaalt" zijn digitale certificaten, uitgegeven door TTP's (Trusted Third Parties), bedacht:

Een digitaal certificaat koppelt een public key aan een identiteit en is digitaal ondertekend door de certificaatuitgever.

In die zin kun je een digitaal certificaat vergelijken met een kopie van een paspoort, waarbij de verstrekker van die kopie op de een of andere manier aantoont daadwerkelijk over het origineel te beschikken (dat laatste gebeurt niet als je een kopie van je paspoort via mail of post op moet sturen, en is dus geen authenticatie - want iedereen die zo'n kopie heeft, kan dat doen). Het handige van een private key is dat je kunt aantonen daarover te beschikken, zonder deze zelf ooit prijs te geven.

Nb. de public key in een certificaat kan ofwel een ontgrendelsleutel (voor signing toepassingen), ofwel een vergrendelsleutel zijn.

Er staan meestal veel meer gegevens in digitale certificaten (die allen binnen de handtekening vallen), zoals de uiterste geldigheidsdatum, maar wat hierboven staat vormt de basis.

Helaas kennen digitale certificaten ook weer problemen:
1) Hoe zeker weet je dat de private key, gebruikt door de certificaatuitgever voor het ondertekenen van een certificaat, daadwerkelijk van die certificaatuitgever is?
2) Als elke CSP (Certificate Service Provider) over dezelfde private key moet beschikken om certificaten mee te kunnen ondertekenen, wordt de kans op uitlekken van die private key erg groot - waarmee in één klap veel certificaten als ongeldig zouden moeten worden beschouwd.
3) En hoe zeker weet je dat die certificaatuitgever betrouwbaar is, d.w.z. zorgvuldig nagaat dat een aanvrager van een certificaat is wie zij zegt dat zij is, en rechtmatig over de bij de public key horende private key beschikt? En zich niet laat omkopen, anderzins dwingen of er geen problemen mee heeft om valse certificaten uit te geven?

Certificaat-ketens

1) Het direct hierboven genoemde probleem 1) wordt opgelost doordat besturingssystemen, sommige webbrowsers (in elk geval Firefox) en bijv. Java zogenaamde rootcertificaten meeleveren. Een rootcertificaat is altijd een self-signed certificaat, wat wil zeggen dat het is ondertekend gebruik makend van de private key horend bij de public key in het certificaat. Oftewel: dat zegt helemaal niets. Verspreiders van rootcertificaten zullen dus op een andere manier de authenticiteit van die certificaten moeten vaststellen, voordat zij deze verspreiden. Je kunt alleen maar hopen dat dit goed gaat, welke protocollen hiervoor in de praktij gebruikt worden, weet ik niet.

2) Om dit probleem op te lossen worden intermediate (tussenliggende) certificaten gebruikt.

3) Hier bestaat (nog) geen goede oplossing voor, anders dan dat rootcertificaatverspreiders kunnen stoppen met het verspreiden van een rootcertificaat van een onbetrouwbare uitgever (ik ga hier nu verder niet op in).

Er is dus sprake van certificaatketens:
Het intermediate certificaat is hierbij ondertekend met de private key horend bij de public key in genoemd rootcertificaat, en op haar beurt is het webservercertificaat van security.nl ondertekend met de de private key horend bij de public key van genoemd intermediate certificaat.

Als jouw webbroser verbinding maakt met https://www.security.nl/, zal de server daarvan zowel het webservercertificaat als het intermediate certificaat naar jouw browser sturen. Intermediate certificaten worden namelijk in principe niet meegeleverd met besturingssystemen, webbrowsers en Java. Wel worden ze meestal gecached (oneindig lang bewaard) door de webbrowser.

Met andere woorden, als je GlobalSign en haar onderuitgevers vertrouwt,en Mozilla erop vertrouwt dat zij het juiste rootcertificaat meeleveren, weet je met flinke zekerheid dat je nu naar een pagina op de echte www.security.nl kijkt.

Tot zover de toelichting ;-)