Et TLS-certifikat alene beviser intet. Tillid kommer fra en kæde af signaturer der forbinder jeres certifikat op igennem mellemliggende CA'er til en rod som browsere allerede stoler på. Når kæden mangler et led, er fejlkonfigureret eller bruger et forældet mellemcertifikat, fejler forbindelser — ofte på måder der er vanskelige at diagnosticere fordi de virker i nogle klienter men ikke andre.

Når en browser forbinder til dit site og validerer dit certifikat, tjekker den ikke blot dit certifikat isoleret. Den går en tillidskæde fra dit certifikat op til en Certificate Authority som browseren allerede kender til. Hvert led i kæden er et certifikat signeret af det oven over. Kæden ender ved et rodcertifikat der er forudinstalleret i browserens eller operativsystemets tillidslagere.

Strukturen i en certifikatkæde

En typisk certifikatkæde har tre niveauer:

  1. Dit end-entity certifikat — certifikatet udstedt til dit domæne. Det er signeret af en mellemliggende CA.
  2. Det mellemliggende CA-certifikat — signeret af rod-CA'en. CA'er bruger mellemcertifikater frem for at signere end-entity certifikater direkte fra roden, så rodcertifikatets private nøgle kan opbevares offline og beskyttes.
  3. Rodcertifikatet — selvsigneret og forudinstalleret i tillidslagere. Browseren stoler på rodcertifikater på grund af deres inkludering i operativsystemet eller browsertillidslageret. (For baggrund om de organisationer der driver disse rødder, se hvad en certificate authority er.)

Når din server sender sit certifikat under TLS-håndtrykket, bør det også sende det eller de mellemliggende certifikater — den fulde kæde ned til (men ikke inklusive) roden. Roden er allerede i browserens tillidslager; den behøver ikke sendes. For en forklaring af den tillidsstruktur certifikaterne udstedes inden for, se Certificate Transparency forklaret.

Hvad en ufuldstændig kæde forårsager

Det mest almindelige kædeproblem er et manglende mellemcertifikat — serveren sender kun end-entity certifikatet uden at inkludere det mellemliggende CA-certifikat.

Forskellige klienter håndterer dette forskelligt, hvilket er grunden til at ufuldstændige kædeproblemer er notorisk inkonsistente:

  • Desktop-browsere — Chrome, Firefox og Safari implementerer alle en mekanisme kaldet AIA-hentning. Hvis mellemcertifikatet mangler fra håndtrykket, vil browseren forsøge at downloade den fra en URL i end-entity certifikatet. Dette virker ofte — hvilket er grunden til at udviklere der tester i desktop-browsere måske slet ikke bemærker en ufuldstændig kæde.
  • Mobile operativsystemer — Android og iOS cacher mellemcertifikater stødt i tidligere forbindelser. En Android-enhed der aldrig har set et bestemt mellemcertifikat kan afvise forbindelsen; en enhed der har cachet den vil acceptere den. Dette producerer den pinlige situation hvor forbindelsen virker for de fleste brugere men fejler for nogle.
  • API-klienter og server-til-server forbindelser — de fleste implementerer ikke AIA-hentning og har ikke mellemcertifikat-caches. Javas TLS-stack, Pythons requests-bibliotek og mange andre almindelige klienter vil afvise forbindelser med ufuldstændige kæder direkte.

Hvad der sker når et mellemcertifikat udløber

Mellemomsætninger har deres egne gyldighedsperioder — typisk flere år. Når et mellemcertifikat udløber, bliver hvert certifikat signeret af det mellemcertifikat uvaliderbart, selv hvis end-entity certifikatet selv stadig er inden sin gyldighedsperiode.

Let's Encrypts ISRG Root X1 krydssignaturudløb i september 2021 er det mest kendte eksempel på denne type problem. DST Root CA X3 krydssignaturen udløb, og klienter der validerede kæder til den rod (primært ældre Android-enheder) begyndte at afvise Let's Encrypt-certifikater. Nyere klienter der validerede til ISRG Root X1 var upåvirkede.

Krydssignerede certifikater og tillidslagerkompleksitet

Moderne PKI involverer krydssignerede certifikater — hvor den samme nøgle er certificeret af flere CA'er, hvilket skaber flere gyldige kædestier til forskellige rødder. Klienter der stoler på rod A kan validere via én kæde; klienter der kun stoler på rod B kan validere via en anden.

Sådan overvåger CertControl kædesundhed kontinuerligt

CertControl validerer den fulde certifikatkæde for alle overvågede endepunkter — kontrollerer at kæden er komplet, at alle certifikater i kæden er inden deres gyldighedsperioder, at kæden validerer til en betroet rod, og at de algoritmer og nøglelængder der bruges i hele kæden opfylder aktuelle standarder. Certifikatkædeproblemer er et af de hyppigste findings i ISO 27001-revisioner der berører TLS-konfiguration.

Kædeproblemer vises som findings med specifikke diagnostik: manglende mellemcertifikat, udløbet mellemcertifikat, forældet algoritme i kæden, kædevalideringsfejl for specifik tillidslager. Detaljeniveauet gør diagnose hurtigere — i stedet for "TLS-fejl" fortæller finding dig præcis hvad der er galt og hvad der skal ændres.

Ofte stillede spørgsmål

Hvad er en certifikatkæde?

Det er rækken af certifikater der forbinder jeres end-entity certifikat op gennem en eller flere mellemliggende CA-certifikater til en rod-CA som browsere og operativsystemer allerede stoler på. Hvert led er signeret af det oven over.

Hvorfor fejler ufuldstændige kæder i nogle klienter men ikke andre?

Desktop-browsere kan hente et manglende mellemcertifikat via AIA, og mobile enheder kan have cachet den, så de virker ofte. API-klienter, server-til-server stakke og IoT-enheder henter typisk ikke mellemcertifikater og afviser ufuldstændige kæder direkte.

Hvad sker der når et mellemcertifikat udløber?

Hvert certifikat signeret af det mellemcertifikat bliver uvaliderbart, selv hvis end-entity certifikatet stadig er gyldigt. Berørte certifikater skal genudstedes fra et aktuelt mellemcertifikat, som ved Let's Encrypts DST Root CA X3-udløb i 2021.

Hvorfor bør rodcertifikatet ikke sendes i håndtrykket?

Roden findes allerede i klientens tillidslager og er betroet ved inkludering, ikke ved signatur. Serveren bør sende end-entity certifikatet og eventuelle mellemcertifikater ned til, men ikke inklusive, roden.

Hvordan relaterer CAA-records til kædeintegritet?

CAA DNS-records begrænser hvilke CA'er der må udstede for jeres domæne og forhindrer uventede udstedelser der kunne introducere andre kædestrukturer. Kombineret med CT-overvågning er et certifikat fra en uautoriseret CA straks identificerbart.

Se platformen Book demo