Wat is een SSL-certificaatketen? Hoe het werkt

Een SSL-certificaatketen helpt browsers en andere clients te verifiëren dat het digitale certificaat van een website kan worden vertrouwd. Wanneer u een website via HTTPS bezoekt, controleert uw browser het TLS-certificaat om te bevestigen dat het het aangevraagde domein identificeert en kan worden gevalideerd via een vertrouwde certificeringsinstantie (CA). Deze verificatie is vaak afhankelijk van een keten van certificaten die het certificaat van de website verbindt met een vertrouwd basiscertificaat. Als een tussencertificaat ontbreekt of de keten niet kan worden gevalideerd, kunnen gebruikers beveiligingswaarschuwingen of verbindingsfouten tegenkomen. Als u begrijpt hoe een SSL-certificaatketen werkt, kunnen website-eigenaren, systeembeheerders en beveiligingsprofessionals certificaatproblemen oplossen en betrouwbare HTTPS-verbindingen onderhouden.

Wat is een SSL-certificaatketen?

Een SSL-certificaatketen, ook wel een certificaatketen van vertrouwen genoemd, is een reeks digitale certificaten die een pad tot stand brengen van het certificaat van een website naar een vertrouwde basiscertificeringsinstantie. Hoewel SSL een veelgebruikte term blijft, maken moderne HTTPS-verbindingen gebruik van Transport Layer Security (TLS).

Een typische keten bevat drie soorten certificaten: het leaf-certificaat van de website, een of meer tussenliggende certificaten en een rootcertificaat. Het leaf-certificaat identificeert de website of server. Met tussenliggende certificaten kan de uitgifte van certificaten worden gedelegeerd, terwijl het basiscertificaat als vertrouwensanker dient wanneer het door de client wordt vertrouwd.

Wanneer een browser bijvoorbeeld verbinding maakt met een HTTPS-website, valideert deze het certificaat van de website en probeert hij een vertrouwd pad op te bouwen via de beschikbare tussenliggende certificaten naar een basiscertificaat in het vertrouwensarchief. Het controleert ook de hostnaam, geldigheidsdata, digitale handtekeningen en andere toepasselijke certificaatvereisten.

Een geldige certificaatketen helpt de identiteit van de server vast te stellen tijdens de TLS-handshake. Het bewijst echter niet dat een website legitiem is, vrij is van malware of wordt beheerd door een betrouwbare organisatie.

Hoe werkt de SSL-certificaatketen van vertrouwen?

Dankzij de vertrouwensketen van certificaten kunnen browsers en andere clients het certificaat van een website valideren met behulp van certificaten die zijn uitgegeven door vertrouwde autoriteiten. Elk certificaat is gekoppeld aan een uitgevende autoriteit, waardoor een pad ontstaat van het certificaat van de website naar een acceptabel vertrouwensanker.

Stap 1: De website presenteert zijn certificaat

Wanneer een browser via HTTPS verbinding maakt met een website, presenteert de server zijn leaf-certificaat tijdens de TLS-handshake. Dit certificaat bevat de openbare sleutel van de website, domeininformatie, gegevens van de uitgever, geldigheidsduur en digitale handtekening.

De browser controleert of de opgevraagde hostnaam overeenkomt met de Subject Alternative Name (SAN)-vermeldingen van het certificaat en of het certificaat voldoet aan de toepasselijke validatievereisten.

Stap 2: Het tussencertificaat brengt de volgende link tot stand

Het certificaat van de website wordt doorgaans uitgegeven door een tussenliggende CA in plaats van rechtstreeks door een root-CA. De client gebruikt de openbare sleutel van het tussenliggende certificaat om de handtekening op het bladcertificaat te verifiëren.

Sommige ketens bevatten meerdere tussencertificaten. Elke link moet voldoen aan de relevante certificaatvalidatieregels zodat de client een vertrouwd pad kan opbouwen.

Stap 3: De keten bereikt een vertrouwde wortel

Een rootcertificaat behoort toe aan een rootcertificeringsinstantie en is doorgaans zelfondertekend. Browsers en besturingssystemen onderhouden vertrouwde rootcertificaten volgens hun eigen vertrouwensbeleid.

De client probeert het bladcertificaat via de vereiste tussenliggende certificaten te verbinden met een vertrouwde root. Normaal gesproken hoeft de server het rootcertificaat niet te verzenden, omdat de client al over zijn vertrouwensinformatie beschikt.

Stap 4: De klant valideert de keten

De client controleert de certificaathandtekeningen, geldigheidsperioden, hostnaam, certificaatbeperkingen en andere toepasselijke vereisten. Afhankelijk van de configuratie kan het ook certificaatintrekkingsinformatie controleren.

Als de client een geldig pad opbouwt en de vereiste controles slagen, kan deze het certificaat van de server accepteren. Anders kan de verbinding een certificaatwaarschuwing geven of mislukken.

Basiscertificaat versus tussencertificaat versus bladcertificaat

Elk certificaat in de keten heeft een specifiek doel. Door deze verschillen te begrijpen, kunnen beheerders HTTPS correct configureren en certificaatfouten oplossen.

1. Bladcertificaat

Een leaf-certificaat, ook wel een eindentiteitscertificaat genoemd, identificeert een website of server. Het bevat de publieke sleutel, domeininformatie, uitgever, geldigheidsdata en digitale handtekening.

De server presenteert dit certificaat aan de client tijdens de TLS-handshake. De client controleert zijn identiteit en geldigheid voordat hij deze accepteert voor de verbinding.

2. Tussencertificaat

Een tussenliggend certificaat behoort toe aan een ondergeschikte certificeringsinstantie die certificaten uitgeeft of de uitgifte ervan delegeert aan een andere autoriteit. Het verbindt het certificaat van de website met een vertrouwd rootcertificaat.

Met tussenliggende CA's kunnen root-CA's hun privésleutels beter geïsoleerd houden terwijl ze de uitgifte van certificaten delegeren. Als een vereist tussencertificaat ontbreekt en niet kan worden verkregen via een ander beschikbaar mechanisme, kan de client de keten mogelijk niet valideren.

3. Basiscertificaat

Een rootcertificaat behoort toe aan een rootcertificeringsinstantie en fungeert als vertrouwensanker wanneer het wordt geaccepteerd door de vertrouwensopslag van een klant. Het is doorgaans zelfondertekend, maar zelfondertekend betekent niet automatisch dat een certificaat vertrouwd wordt.

De client moet de root herkennen als vertrouwd onder het geconfigureerde vertrouwensbeleid.

Een typische keten volgt daarom dit pad:

Websitecertificaat → Intermediair CA-certificaat → Vertrouwd rootcertificaat

De exacte keten is afhankelijk van de certificeringsinstantie, de serverconfiguratie en de certificaten die beschikbaar zijn voor de client.

Hoe browsers een SSL-certificaatketen valideren

Browsers valideren certificaatketens tijdens de TLS-handshake om te bepalen of de identiteit van de server kan worden vertrouwd.

Hostnaamverificatie

De browser controleert of het aangevraagde domein overeenkomt met de SAN-vermeldingen van het certificaat. Een certificaat uitgegeven voorvoorbeeld.commagniet dekken winkel.voorbeeld.comtenzij de extra hostnaam of een passend jokerteken is opgenomen.

Als de hostnaam niet overeenkomt, kan dit een browserwaarschuwing activeren of ervoor zorgen dat de verbinding wordt afgewezen.

Verificatie van digitale handtekeningen

Digitale handtekeningen helpen klanten de certificaatintegriteit en authenticiteit binnen het certificeringspad te verifiëren. De client gebruikt de openbare sleutel van het uitgevende certificaat om de handtekening op het onderzochte certificaat te verifiëren.

Cryptografische operaties staan ​​centraal in dit proces. Voor een gerelateerde uitleg, lees CyberLad's handleiding voorhashing in cyberbeveiliging.

Certificaat verlopen

Certificaten hebben een geldigheidsperiode die wordt gedefinieerd door hunNiet eerderenNiet daarnavelden. De opdrachtgever controleert of de betreffende certificaten geldig zijn op het moment van verificatie.

Een verlopen leaf- of intermediair certificaat kan een succesvolle validatie in de weg staan. Beheerders moeten de vervaldata controleren en bevestigen dat vernieuwde certificaten correct zijn geïnstalleerd.

Vertrouwensopslag en certificaatpad

De client probeert een geldig pad op te bouwen van het bladcertificaat via de tussenliggende certificaten naar een acceptabel vertrouwensanker. Het controleert ook de toepasselijke certificaatbeperkingen en vereisten voor sleutelgebruik.

Truststores variëren per besturingssysteem, browser en applicatie. Een certificaat dat in de ene omgeving wordt vertrouwd, wordt in een andere omgeving mogelijk niet vertrouwd.

Certificaatintrekking

Certificaten kunnen vóór hun vervaldatum worden ingetrokken als hun privésleutels zijn aangetast of als andere omstandigheden intrekking vereisen. Certificaatautoriteiten kunnen intrekkingsinformatie publiceren via Certificate Revocation Lists (CRL's) of het Online Certificate Status Protocol (OCSP).

Het gedrag bij het controleren van intrekkingen varieert per klant. Sommigen gebruiken in de cache opgeslagen informatie of alternatieve mechanismen, dus succesvolle ketenvalidatie betekent niet altijd dat elke client identieke intrekkingscontroles heeft uitgevoerd.

Veelvoorkomende fouten in de SSL-certificaatketen en hun oorzaken

Certificaatketenfouten treden op wanneer een client het door een server gepresenteerde certificaat niet kan valideren. Het identificeren van de specifieke fout is essentieel omdat elk probleem een ​​andere oplossing vereist.

1. Onvolledige certificaatketen

Er is sprake van een onvolledige keten wanneer de server niet het vereiste tussenliggende certificaat levert en de client geen vertrouwd pad kan bouwen met behulp van andere beschikbare certificaten.

Veelvoorkomende oorzaken zijn ontbrekende tussenliggende certificaten, onjuiste certificaatbundels en configuratiewijzigingen na een servermigratie.

Hoe dit te verhelpen:Verkrijg de juiste tussenliggende certificaten van uw certificeringsinstantie en configureer de server om het bladcertificaat te presenteren, gevolgd door de vereiste tussenliggende certificaten.

2. Niet-vertrouwde certificeringsinstantie

Een client kan een keten afwijzen als hij het certificaat niet kan verbinden met een acceptabel vertrouwensanker. Dit kan gebeuren met zelfondertekende certificaten of privé-CA-certificaten die niet in het vertrouwensarchief van de client zijn geïnstalleerd.

Hoe dit te verhelpen:Gebruik een publiekelijk vertrouwde CA voor openbare websites. Voor interne toepassingen distribueert u het basiscertificaat van de organisatie via een goedgekeurd vertrouwensbeheerproces. Installeer nooit een onbekend rootcertificaat alleen maar om een ​​waarschuwing te omzeilen.

3. Verlopen certificaat

Een verlopen leaf- of intermediair certificaat kan een succesvolle validatie in de weg staan.

Hoe het te repareren:Controleer de geldigheidsdata, vernieuw of vervang het getroffen certificaat en zorg ervoor dat de bijgewerkte certificaatketen op elk relevant TLS-eindpunt is geïnstalleerd.

4. Hostnaam komt niet overeen

Een hostnaam komt niet overeen wanneer het aangevraagde domein niet wordt gedekt door de SAN-vermeldingen van het certificaat.

Hoe dit te verhelpen:Installeer een certificaat dat de aangevraagde hostnaam dekt. Controleer de instellingen voor de virtuele host, de servernaamindicatie (SNI) en de load-balancer-certificaatbindingen.

5. Onjuiste certificaatbundel

Het kan zijn dat een server het verkeerde tussencertificaat of een verkeerd bestelde certificaatbundel presenteert.

Hoe het te repareren:Vergelijk de uitgever van het leaf-certificaat met de geconfigureerde tussenliggende certificaten. Corrigeer de bundel en test de serverconfiguratie voordat u de service opnieuw laadt.

6. Intrekking of andere validatiefout

Het kan zijn dat een certificaat niet wordt gevalideerd omdat het is ingetrokken of niet voldoet aan een andere toepasselijke certificaatvereiste.

Hoe dit te verhelpen:Controleer de status van het certificaat en raadpleeg de instructies van de uitgevende CA. Vervang een ingetrokken certificaat en onderzoek de oorzaak. Het uitschakelen van certificaatverificatie is geen veilige oplossing.

Hoe u een SSL-certificaatketen kunt controleren

U kunt de certificaatketen van een openbare website inspecteren met behulp van een online testservice of opdrachtregelprogramma's.

Methode 1: Gebruik SSL Labs

Qualys SSL Labs SSL Server Test analyseert publiek toegankelijke TLS-servers en rapporteert certificaat- en configuratieproblemen.

1. Open de SSL Labs-testpagina.

2. Voer het domein in dat u wilt inspecteren.

3. Voer de test uit en wacht op de analyse.

4. Bekijk de certificaatgegevens en keteninformatie.

5. Onderzoek waarschuwingen over vertrouwen, vervaldatum, ontbrekende tussenproducten of validatie van de hostnaam.

SSL Labs is handig voor extern testen zonder extra software te installeren. Vermijd het indienen van gevoelige interne hostnamen of systemen, tenzij het beleid van uw organisatie het gebruik van een externe service toestaat.

Methode 2: Certificaten inspecteren met OpenSSL

OpenSSL kan certificaten weergeven die door een server worden gepresenteerd tijdens een TLS-verbinding. Uitvoeren:

openssl s_client -connect voorbeeld.com:443 \
  -servernaam voorbeeld.com \
  -showcertificaten

Vervangvoorbeeld.commet het doeldomein.

De-verbindoptie specificeert de bestemming en poort. De-servernaamoptie verzendt de hostnaam via SNI, terwijl-showcertificatentoont de certificaten die door de server zijn verzonden.

Belangrijk:Het weergeven van certificaten bewijst niet dat de keten vertrouwd is. Gebruik verificatieopties om het certificaatpad en de hostnaam te controleren.

Methode 3: Controleer de keten en hostnaam

Voer de volgende opdracht uit om certificaatverificatie en controle van de hostnaam aan te vragen:

openssl s_client \
  -connect voorbeeld.com:443 \
  -servernaam voorbeeld.com \
  -verify_return_error \
  -verify_hostnaam voorbeeld.com

Zoek naar een succesvol verificatieresultaat, zoalsControleer de retourcode: 0 (ok). De exacte uitvoer is afhankelijk van de OpenSSL-versie, vertrouwensopslag en verificatie-instellingen.

De-verify_return_erroroptie zorgt ervoor dat verificatiefouten worden geretourneerd in plaats van dat de opdracht daarna wordt voortgezet. Zie deofficiële OpenSSL s_client documentatie.

Methode 4: Inspecteer de uitgever en vervaldatum

Als u het leaf-certificaat als een PEM-bestand hebt opgeslagen, voert u het volgende uit:

openssl x509 -in certificaat.pem -noout \
  -onderwerp -uitgever -data

Hier worden het onderwerp, de uitgever en de geldigheidsdatum van het certificaat weergegeven. Gebruik de uitvoer om te controleren of de uitgever overeenkomt met de verwachte CA en of het certificaat binnen de geldigheidsperiode valt.

Hoe u een onvolledige SSL-certificaatketen kunt repareren

Het repareren van een onvolledige keten omvat doorgaans het identificeren van het ontbrekende tussenproduct, het verkrijgen van de juiste certificaatbundel, het configureren van het TLS-eindpunt en het testen van het resultaat.

Stap 1: Identificeer het ontbrekende tussenproduct

Voer de OpenSSL-opdracht hierboven uit of gebruik SSL Labs om de keten te onderzoeken. Controleer welke certificaten de server verzendt en of de client een vertrouwd pad kan opbouwen.

Een mislukte verificatie betekent niet altijd dat er een tussenproduct ontbreekt. Onderzoek ook de vervaldatum, niet-overeenkomende hostnamen en problemen met de vertrouwensopslag.

Stap 2: Verkrijg de juiste certificaatbundel

Download de vereiste tussentijdse certificaten van de officiële website van uw certificeringsinstantie of het certificaatbeheerportaal. Bevestig dat de certificaten overeenkomen met de uitgever van uw leaf-certificaat.

Het rootcertificaat is normaal gesproken al beschikbaar in het trustarchief van de client en hoeft doorgaans niet te worden opgenomen in de certificaatbundel van de server.

Stap 3: Configureer Nginx

Voor Nginx moet het certificaatbestand eerst het bladcertificaat bevatten, gevolgd door de vereiste tussenliggende certificaten.

server {
    luister 443 ssl;
    servernaam voorbeeld.com;

    ssl_certificate /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
}

De paden zijn voorbeelden. Gebruik de juiste locaties voor uw omgeving en zorg ervoor dat de privésleutel wordt beschermd door de juiste machtigingen.

Test de configuratie voordat u Nginx opnieuw laadt:

sudo nginx -t

Stap 4: Controleer Apache en andere TLS-eindpunten

Apache-configuraties kunnengebruiken SSLCertificaatBestandhet verstrekken van het bladcertificaat en de benodigde tussencertificaten. Volg de documentatie voor uw Apache-versie en -implementatie.

Als HTTPS eindigt bij een reverse proxy, content delivery network, webapplicatiefirewall of load balancer, controleer dan het certificaat dat op die laag is geïnstalleerd. Als u alleen de oorspronkelijke server bijwerkt, wordt een onjuist certificaat dat door een afzonderlijke proxy wordt aangeboden niet hersteld.

Stap 5: Controleer de oplossing

Nadat u de wijzigingen hebt aangebracht, voert u OpenSSL en SSL Labs opnieuw uit. Bevestig dat de server de verwachte certificaten presenteert en dat de client de keten en hostnaam kan valideren.

Voor omgevingen met meerdere servers of TLS-eindpunten test u elk relevant eindpunt. Een succesvol resultaat op één server garandeert niet dat alle eindpunten dezelfde configuratie hebben.

Best practices voor SSL-certificaatketens

Gebruik vertrouwde certificeringsinstanties

Gebruik publiekelijk vertrouwde CA's voor openbare websites. Voor interne toepassingen kunt u privé-CA-vertrouwen veilig distribueren naar geautoriseerde clients.

Automatiseer verlenging en monitoring

Gebruik hulpmiddelen voor certificaatbeheer waar ondersteund, en waarschuw beheerders voordat certificaten verlopen. Controleer of vernieuwde certificaten daadwerkelijk worden geïmplementeerd en bediend door de relevante eindpunten.

Bescherm privésleutels

Beperk de toegang tot privésleutels van certificaten, sla ze veilig op en voorkom dat ze in logboeken of openbare opslagplaatsen worden weergegeven. Als een sleutel gecompromitteerd is, vervangt u het betrokken certificaat en volgt u de juiste incident-respons- en intrekkingsprocedures.

Valideren na configuratiewijzigingen

Test de certificaatketen na verlengingen, servermigraties, wijzigingen in de load balancer of reverse-proxy-updates. Controleer hostnaammatching, vervaldatum, ketenconstructie en verificatiefouten.

Houd een certificaatinventaris bij

Registreer certificaateigenaren, domeinen, uitgevende CA's, vervaldata, implementatielocaties en verlengingsmethoden. Dankzij een gecentraliseerde inventarisatie kunnen teams getroffen services snel vinden tijdens storingen.

Certificaten van derden controleren

Certificaatproblemen kunnen van invloed zijn op de services waarvan uw organisatie afhankelijk is, en niet alleen op uw eigen website. Bewaak belangrijke externe TLS-eindpunten, waaronder identiteitsproviders, betalingsgateways en API's. CyberLad legt dit bredere risico uit inVijf risico's van derden die uw kwetsbaarheidsscanner niet kan zien.

Gebruik veilige TLS-configuraties

Een geldige certificaatketen is slechts een onderdeel van HTTPS-beveiliging. Gebruik ondersteunde TLS-versies, geschikte cryptografische instellingen en veilige sleutelbeheerpraktijken. Een vertrouwd certificaat garandeert niet dat een applicatie vrij is van kwetsbaarheden.

Conclusie

Een SSL-certificaatketen is een essentieel onderdeel van HTTPS-beveiliging, omdat browsers en andere clients hierdoor het certificaat van een website kunnen valideren via een pad naar een vertrouwde certificeringsinstantie. Door inzicht te krijgen in leaf-, intermediair- en rootcertificaten kunnen beheerders problemen met onvolledige ketens, verlopen certificaten en vertrouwensfouten oplossen. Regelmatige monitoring, correcte serverconfiguratie, veilig beheer van privésleutels en verificatie na de implementatie helpen betrouwbare TLS-verbindingen te behouden. Door deze praktijken te volgen, kunnen website-eigenaren en beveiligingsprofessionals certificaatgerelateerde verstoringen verminderen en de betrouwbaarheid van hun HTTPS-infrastructuur verbeteren.

Veelgestelde vragen

Wat is een SSL-certificaatketen?

Een SSL-certificaatketen is een reeks digitale certificaten die een pad vormen van het certificaat van een website naar een vertrouwde basiscertificeringsinstantie. Het omvat gewoonlijk het bladcertificaat en een of meer tussenliggende certificaten.

Wat is het verschil tussen een root- en een tussencertificaat?

Een rootcertificaat fungeert als vertrouwensanker wanneer het door de klant wordt geaccepteerd. Een tussenliggend certificaat delegeert de certificaatuitgifte en verbindt het bladcertificaat met de vertrouwde root.

Moet een webserver het rootcertificaat verzenden?

Meestal niet. Normaal gesproken verzendt de server het bladcertificaat en de vereiste tussencertificaten. De client heeft doorgaans al een vertrouwd basiscertificaat in zijn vertrouwensarchief.

Hoe kan ik een SSL-certificaatketen controleren?

GebruikSSL-labsom een ​​openbare website te inspecteren, ofuit te voeren openssl s_clientom de certificaten te onderzoeken die door een server worden gepresenteerd. Neem hostnaam- en certificaatverificatieopties op wanneer u controleert of de keten kan worden vertrouwd.

Wat veroorzaakt een onvolledige SSL-certificaatketen?

De meest voorkomende oorzaak is een ontbrekend tussencertificaat. Onjuiste certificaatbundels, verouderde configuraties en inconsistente TLS-instellingen op verschillende servers kunnen er ook voor zorgen dat clients geen geldig certificeringspad opbouwen.

Hoe herstel ik een onvolledige certificaatketen?

Verkrijg de juiste tussenliggende certificaten van de CA, configureer de server om het bladcertificaat te presenteren, gevolgd door de benodigde tussenliggende certificaten, en test de bijgewerkte configuratie. De precieze stappen zijn afhankelijk van de serversoftware en het TLS-aansluitpunt.

Is een SSL-certificaatketen hetzelfde als een SSL-certificaat?

Nee. Een certificaat bevat informatie over de identiteit van een website en de publieke sleutel. De keten is de reeks certificaten die wordt gebruikt om een ​​vertrouwd pad van dat certificaat naar een acceptabel vertrouwensanker tot stand te brengen.

Betekent een geldige certificaatketen dat een website veilig is?

Nee. Een geldige keten helpt bij het verifiëren van de gecertificeerde identiteit van een website volgens het vertrouwensbeleid van de klant. Het garandeert niet dat de website legitiem is, vrij is van malware of beschermd is tegen kwetsbaarheden in de applicatie.