Udfordringen med interne servercertifikater
Interne servercertifikater har altid krævet kompromisser: maskiner på private netværk, Windows-servere, load-balancere og interne API'er der har brug for TLS-certifikater, men ikke direkte kan nå en ekstern CA, ikke kører en fuld webstack til HTTP-01-challenges, eller opererer bag firewalls der gør DNS-01-automation vanskelig. Se vores komplette guide til TLS-overvågning for en forklaring af alle overvågningsdimensioner inklusive interne certifikater.
Standardsvaret har været en privat CA med manuelle processer, eller at pege hver server direkte mod en ekstern ACME CA. Begge tilgange har den samme svaghed: ingen central synlighed. Resultatet er spredte ACME-konti per server, ingen samlet fornyelseslog og ingen mekanisme til at koordinere når noget går galt. I takt med at CA/Browser Forums SC-081 reducerer den maksimale certifikatlevetid til 47 dage i 2029 bliver den tilgang stadig mindre holdbar. For en detaljeret gennemgang af hvad denne overgang kræver organisationsmæssigt, se vores artikel om 47-dages certifikatlevetider.
ACME Server (RFC 8555): CertControl som ACME-endpoint
CertControls ACME Server gør CertControl selv til et RFC 8555-kompatibelt ACME-endpoint og bygger oven på den samme model som når man automatiserer certifikater med ACME. Interne servere med certbot, acme.sh, win-acme eller Posh-ACME peger på CertControl i stedet for direkte mod Let's Encrypt eller en anden CA. CertControl videresender ordren til en konfigureret upstream CA (Let's Encrypt, ZeroSSL eller jeres private CA), håndterer challenge og sender det signerede certifikat tilbage til den anmodende server — inklusive automatisk installation, når certbot eller win-acme styrer tjenesten.
De konkrete fordele:
- Samlet kontostyring. Én upstream CA-konto i CertControl betjener alle interne servere. Ingen per-server ACME-kontoregistrering og ingen spredte credentials.
- Ingen direkte CA-adgang nødvendig. Interne servere behøver kun at kunne nå CertControl. CertControl håndterer den udgående CA-kommunikation, hvilket gør deployment bag strenge egress-firewalls ligetil.
- Fuld livscyklussynlighed. Enhver fornyelsesanmodning, udstedt certifikat og fejl vises i CertControls certifikatregister — ved siden af jeres eksternt overvågede certifikater. Intet separat værktøj at tjekke.
- Sikker nøglehåndtering. ACME-kontos private nøgler gemmes krypteret med AES-256-GCM og forlader aldrig CertControl. Serverne modtager signerede certifikater — ikke CA-credentials.
HTTP-01-challenges håndteres automatisk. DNS-01-validering understøttes for certifikater der kræver det — herunder wildcard-certifikater — via det standard to-trins flow.
ARI (RFC 9773): koordineret fleetfornyelse og øjeblikkelig revokering
ACME Server løser hvordan interne certifikater fornyes. ARI løser hvornår.
Uden ARI fornyer hver certbot-instans, når dens lokale plan siger det — typisk når der er under 30 dage tilbage på certifikatet. Det fungerer fint under normale vilkår. Det bryder sammen i to situationer, som enhver der driver et større fleet før eller siden møder:
- Koordineret revokering. En CA revokerer certifikater i bulk på grund af fejludstedelse. 200 servere skal fornye inden for timer, ikke dage. Uden ARI venter hver server på sin egen nedtælling. Med ARI aktiverer I Force all early i Renewal Windows-fanen, og alle klienter ser et aktivt fornyelsesvindue ved deres næste planlagte poll — typisk inden for timer for certbots standard cron-interval.
- 47-dages certifikatlevetid. Et certifikat på 47 dage efterlader kun 10–15 dages vindue, inden "forny ved 30 dage tilbage"-grænsen aktiveres. Forsøger man at fordele fornyelserne på et større fleet mister man evnen til at koordinere — nogle servere fornyer for tidligt, andre for tæt på udløb. ARI giver serveren præcis kontrol: den signalerer det optimale vindue til hver klient individuelt.
ARI eksponeres som et offentligt endpoint: GET /acme/renewalInfo/{certId}. CertControl beregner et standardvindue der starter ved 2/3 af certifikatets levetid og slutter 7 dage før udløb. Administratorer kan tilsidesætte dette vindue for et enkelt certifikat — udskyd fornyelse forbi et release-freeze, fremryk den før en nøglerotation, eller vedhæft en URL til jeres statusside som ARI-bevidste klienter kan vise til operatørerne.
Renewal Windows: admin-grænsefladen
Renewal Windows-fanen under Infrastruktur → ACME Server viser alle certifikater udstedt via jeres ACME Server, med det aktuelle vindue, status (Aktiv / Revokeret) og om der er en manuel tilsidesættelse aktiv. Herfra kan I:
- Sætte et brugerdefineret vindue med en valgfri forklarings-URL
- Tvinge tidlig fornyelse på et enkelt certifikat — sætter vinduet til et 24-timers interval fra nu
- Force all early — masse-opdaterer alle aktive certifikater i én operation
- Rydde en tilsidesættelse og vende tilbage til det beregnede standardvindue
- Backfill certID'er for certifikater udstedt inden ARI-understøttelse blev tilføjet — ét klik dækker hele jeres eksisterende beholdning
Tilsidesættelser træder i kraft ved klientens næste fornyelsestjek. Har I brug for hurtigere respons, kan I køre certbot renew --force-renewal direkte på den pågældende server.
Klientunderstøttelse
ARI understøttes af certbot 2.9+, acme.sh og win-acme. Klienter der ikke understøtter ARI ignorerer blot renewalInfo-nøglen og falder tilbage til deres konfigurerede fornyelsesplan — så aktivering af ARI har ingen negativ effekt på ældre klienter.
ACME Server er kompatibel med alle klienter der taler RFC 8555: certbot, acme.sh, win-acme, Posh-ACME, Caddy og andre. Klienter forbinder til jeres CertControl-instans' /acme/directory-endpoint ved kontoregistrering — ingen særlig konfiguration ud over server-URL'en.
Tilgængelighed
Både ACME Server (RFC 8555) og ARI (RFC 9773) er tilgængelige på Scale-planen. ACME Server-quickstart-guiden dækker kontoopsætning, klientkonfiguration og første certifikatudstedelse på under 10 minutter. ARI aktiveres automatisk for alle certifikater udstedt via ACME Server — ingen yderligere konfiguration kræves. Se vores guide til forebyggelse af certifikatudløb for en bredere gennemgang af hvordan automatisering indpasses i en samlet certifikatstrategi.
Ofte stillede spørgsmål
Hvad gør CertControls ACME Server?
Den gør CertControl til et RFC 8555 ACME-endpoint. Interne servere med certbot, acme.sh, win-acme eller Posh-ACME peger på CertControl, som videresender ordren til en upstream CA, håndterer challenge og returnerer det signerede certifikat — med samlet kontostyring og fuld revisionssynlighed.
Hvad er ARI, og hvilket problem løser det?
ARI (Automatic Renewal Information, RFC 9773) fortæller hver klient præcist hvornår den skal fornye. Det løser koordineret fleetfornyelse ved en bulk-revokering og giver præcis kontrol over fornyelsestiming, når levetider falder mod 47 dage.
Skal interne servere have direkte adgang til certifikatmyndigheden?
Nej. Interne servere behøver kun at kunne nå CertControl, som håndterer den udgående CA-kommunikation. Det gør deployment ligetil bag strenge egress-firewalls, og ACME-kontonøgler gemmes krypteret og forlader aldrig CertControl.
Hvor hurtigt træder en tvunget fornyelse i kraft?
Tilsidesættelser og Force all early træder i kraft ved hver klients næste fornyelsestjek — typisk inden for timer for certbots standard cron-plan. For øjeblikkelig fornyelse kør certbot renew --force-renewal på den pågældende server.
Hvilke ACME-klienter understøtter ARI?
ARI understøttes af certbot 2.9+, acme.sh og win-acme. Klienter uden ARI-understøttelse ignorerer blot renewalInfo-nøglen og falder tilbage til deres konfigurerede plan, så aktivering af ARI har ingen negativ effekt på ældre klienter.