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 tillidslagre.

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 mellemomsætninger 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 tillidslagre. Browseren stoler på rodcertifikater på grund af deres inkludering i operativsystemet eller browsertillidslagret.

Når din server sender sit certifikat under TLS-håndtryket, 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 tillidslagr; den behøver ikke sendes.

Hvad en ufuldstændig kæde forårsager

Det mest almindelige kædeproblem er et manglende mellemomsætning — 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 mellemomsætningen mangler fra håndtryket, 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 mellemomsætninger stødt i tidligere forbindelser. En Android-enhed der aldrig har set en bestemt mellemomsætning 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 mellemomsætningscaches. Javas TLS-stack, Pythons requests-bibliotek og mange andre almindelige klienter vil afvise forbindelser med ufuldstændige kæder direkte.

Problemet med udløbne mellemomsætninger

Mellemomsætninger har deres egne gyldighedsperioder — typisk flere år. Når en mellemomsætning udløber, bliver hvert certifikat signeret af den mellemomsætning 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.

Hvordan CertControl overvåger kædesundhed

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.

Kædeproblemer vises som findings med specifikke diagnostik: manglende mellemomsætning, udløbet mellemomsætning, forældet algoritme i kæden, kædevalideringsfejl for specifik tillidslagr. 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.