De fleste certifikatovervågningsfokus er på webservere. Det giver mening — webservere er de mest synlige, de mest dokumenterede og de mest direkte forbundet med TLS i de fleste teams mentale modeller. Men certifikatrisikoen der forårsager de største nedbrud er sjældent på origin-serveren. Den er på laget foran den.
CDN-edge-noder, load balancers, reverse proxies, API-gateways og WAF'er sidder mellem brugere og alle tjenester bag dem. Et enkelt certifikat på en af disse komponenter kan være TLS-termineringspunktet for snesevis eller hundreder af backend-tjenester. Når det certifikat udløber, fejler de alle simultant fra brugerens perspektiv — selv hvis hver individuel backend-tjeneste har sit eget gyldige, aktuelle certifikat.
Blast-radius problemet
Overvej en typisk arkitektur: et CDN håndterer TLS-terminering for en organisations hele offentlige overflade. Trafik rutes baseret på sti eller host header til forskellige backend-tjenester — hovedwebsitet, API'en, kundeportalen, admin-grænsefladen. Hvert backend kan have sit eget certifikat til intern kommunikation, men det certifikat brugerens browser ser er CDN edge-certifikatet.
Hvis det CDN-certifikat udløber, modtager browseren en ugyldig certifikatfejl inden forespørgslen overhovedet når en backend. Alle tjenester bag CDN er effektivt nede — ikke fordi noget er galt med tjenesterne selv, men fordi hoveddøren er i stykker.
Det samme mønster gælder for:
- Hardware load balancers (F5 BIG-IP, Citrix ADC, Kemp) der terminerer TLS for flere virtuelle servere
- Reverse proxies (NGINX, HAProxy, Envoy) konfigureret som TLS-endepunkt for et service mesh eller microservices-arkitektur
- API-gateways (Kong, Apigee, AWS API Gateway) der håndterer autentificering og routing for al API-trafik
- Web Application Firewalls der sidder foran applikationsservere
- Cloud-managed certifikattjenester hvor certifikater er knyttet til ressourcer som Application Load Balancers i AWS eller Front Door i Azure
Hvorfor edge-certifikater overses
Flere faktorer kombinerer til at gøre edge-certifikater systematisk underovervågede i mange organisationer:
Forskelligt ejerskab. CDN og load balancer-certifikater styres ofte af et netværks- eller infrastrukturteam, mens applikationscertifikater styres af udviklings- eller DevOps-teams. Certifikatovervågningsprocesser der udviklede sig omkring applikationscertifikater er måske aldrig blevet udvidet til at dække infrastrukturkomponenter styret af en anden gruppe.
Forskelligt værktøj. Certifikater på hardware load balancers og CDN-platforme kan ofte ikke styres gennem det samme værktøj som servercertifikater. De lever i managementkonsoller, udbyderportaler eller proprietære API'er. Dette gør det nemt for dem at falde uden for ethvert certifikatsporingssystem der eksisterer.
Falsk tillid fra scanning. Eksterne certifikatscannere forbinder typisk til det endepunkt som brugere forbinder til — hvilket betyder at de ser edge-certifikatet, ikke origin-certifikatet. Hvis scanning er sat op til at kontrollere origin-serverens IP direkte, ser den origin-certifikatet og misser edge-certifikatet fuldstændigt. Hvis den kontrollerer det brugervendte domæne, ser den edge-certifikatet — men kun hvis den scanning faktisk sker for alle domæner, inklusiv domæner der kun betjenes via CDN.
Managed service-antagelse. Teams antager undertiden at fordi et CDN eller cloud load balancer er en managed tjeneste, håndteres certifikatstyring automatisk. Nogle udbydere gør dette — AWS Certificate Manager fornyer automatisk certifikater knyttet til CloudFront — men mange gør det ikke, og skellet er ikke altid klart inden noget går i stykker.
Almindelige fejlscenarier
CDN-certifikatet fornyet, origin opdaterede ikke. Nogle CDN-konfigurationer kræver at kunden uploader det fornyet certifikat manuelt. CDN'et sender fornyelsespåmindelser til en e-mailadresse som ingen læser, deadlineen passerer, og edge-certifikatet udløber mens origin-certifikatet er aktuelt og sundt.
Wildcard-certifikatet udløb og ingen bemærkede det inden en tjeneste fejlede. Wildcard-certifikater der dækker *.ditdomæne.dk er effektive men uigennemsigtige. Når wildcard-certifikatet udløber, bryder alle tjenester der bruger det simultant. Omfanget af et wildcard gør det nemt at miste overblikket over hvad der afhænger af det — og gør nedbruddet tilsvarende større når det udløber.
Det tredjepartsCDN-certifikat var ikke i nogen inventar. Organisationer bruger ofte flere CDN-udbydere — én til hovedsitet, én anden til videoleverance, en tredje til en specifik geografisk region. Certifikater hos hver af disse udbydere er separate, styret via separate portaler og ofte sporet af ingen.
Hvad overvågning bør dække
Effektiv certifikatovervågning til edge-infrastruktur kræver kontrol af certifikater der hvor brugere faktisk forbinder — ikke kun på origin. Det betyder:
- Overvågning af det brugervendte domæne og port-kombination, ikke backend IP-adressen. Det certifikat der betyder noget er det som brugerens browser validerer.
- Dækning af alle domæner og underdomæner betjent via edge-infrastruktur, inklusiv domæner der kan være på et CDN men ikke i den primære domænefortegnelse.
- Kontrol på tværs af CDN-udbydere — hvis trafik er opdelt på tværs af flere CDN'er, skal hvert udbyders edge-certifikat være i omfang.
- Inkludering af ikke-standardporte — ikke alle tjenester bruger port 443. API'er på ikke-standardporte, interne tjenester eksponeret til partnerintegrationer og udviklingsmiljøer betjent på alternative porte har alle certifikater der skal overvåges.
- Advarselsvinduet skal være langt nok til at tage fornyelsesprocessen i betragtning. Erstatning af et certifikat på en hardware load balancer kan kræve en change management-proces, vedligeholdelsesvindue og godkendelse. Et 30-dages advarselsvindue der er passende for et automatiseret servercertifikat kan være utilstrækkeligt for et infrastrukturcertifikat med en to-ugers change management-proces.
Hvordan CertControl håndterer edge-certifikater
CertControl overvåger certifikater ved forbindelses punktet — det domæne og den port som brugere faktisk forbinder til. Det betyder at edge-certifikatet er det der kontrolleres, uanset om trafik betjenes fra et CDN, load balancer eller origin-server direkte.
Den eksterne scanner opdager certifikater på tværs af alle underdomæner fundet i CT-logs, inklusiv domæner betjent via CDN-udbydere der måske ikke er i en manuelt vedligeholdt inventar. Til interne load balancers og reverse proxies der ikke kan nås fra internet, dækker on-premise agenten den samme overvågning inden for dit netværksperimeter.
Risikoscoring-systemet vægter certifikater der dækker mange tjenester højere, så edge-certifikater med bred blast-radius dukker op øverst på prioritetslister frem for at sidde stille ved siden af individuelle tjenestecertifikater.