Begränsningar i AWS Certificate Manager: Där ACM inte når upp till Enterprise PKI

AWS Certificate Manager (ACM) är en hanterad tjänst som tillhandahåller, driftsätter och förnyar TLS/SSL-certifikat för AWS-integrerade tjänster. Det har blivit standardutgångspunkten för TLS-certifikat i AWS-ekosystemet, och det av goda skäl: det är gratis för integrerade tjänster, helt hanterat och i praktiken osynligt när det väl är konfigurerat. Men certifikathantering håller sig sällan snyggt innanför AWS gränser.

I takt med att företag sprider arbetsbelastningar över flera moln, lokal infrastruktur och en växande blandning av certifikatutfärdare, slutar frågan att vara "Är ACM bra?" och blir till "Var slutar ACM att vara tillräckligt?". Den här bloggen besvarar den frågan. Den kartlägger var ACM verkligen passar in, de praktiska begränsningarna PKI som team stöter på när de går bortom AWS-nativa tjänster, den ekonomi som driver dessa begränsningar, och hur en leverantörsneutral CLM-plattform fyller luckorna, särskilt i takt med att krympande certifikatgiltighetsperioder och övergången efter kvantum ökar insatserna.

Var ACM passar in, och var det inte gör det

Om hela din arbetsbelastning ligger bakom en Application Load Balancer, frontad av Amazon CloudFront och exponerad via Amazon API Gateway, är AWS Certificate Manager (ACM) verkligen svår att slå. Den utfärdar publika TLS-certifikat utan kostnad för dessa integrerade tjänster, hanterar förnyelser och driftskostnaderna är nära noll. För renodlade AWS-nativa team som har en begränsad verksamhet är det en av de bättre hanterade tjänsterna som AWS erbjuder.

Problemet börjar i det ögonblick som er certifikatposition sträcker sig bortom AWS-gränsen. De flesta företag vi arbetar med på Encryption Consulting är inte rena AWS-butiker. De kör en blandning av lokala Microsoft AD CS, tredjeparts CA:er som DigiCert eller Entrust för offentligt betrodda certifikat, HashiCorp Vault PKI för service mesh och DevOps-arbetsbelastningar, och en lång rad arbetsbelastningar på F5 BIG-IP, NGINX, Apache Tomcat och IIS som inte har något att göra med AWS.

Enligt Flexeras rapport om molnets tillstånd från 2024 har cirka 89 % av företagen anammat multimoln, och Gartner förutspår att över 90 % av organisationerna kommer att använda hybridmoln år 2027. I den världen är ett CLM-verktyg som bara kan hantera en molnleverantör, i en region, i bästa fall en delvis lösning.

Den här bloggen går igenom de praktiska begränsningarna med ACM som PKI-team faktiskt stöter på under företagsimplementeringar, ekonomin bakom dem och hur en leverantörsneutral CLM-plattform som Encryption Consultings CertSecure-hanterare stänger de luckor som ACM lämnar öppna.

ACM vs. AWS Private CA: En snabb uppfriskning

Innan vi går vidare är det värt att separera två AWS-tjänster som ofta blandas ihop. AWS döpte om "ACM Private CA" till "AWS Private CA" i september 2022, och skillnaden är viktig när man läser prissidor eller utformar registreringsflöden.

AWS Certificate Manager (ACM) är livscykeltjänsten. Den utfärdar, driftsätter och förnyar publika TLS-certifikat från Amazons publika CA, och fungerar även som hanteringslager för privata certifikat utfärdade av AWS Private CA. ACM-utfärdade publika certifikat som används exklusivt med integrerade AWS-tjänster (ELB, CloudFront, API Gateway, App Runner och liknande) är gratis.

AWS Private CA är den hanterade privata CA-infrastrukturen. Den kör din CA-hierarki på FIPS 140-2 hårdvaruskyddade nycklar, men du betalar en månadsavgift per CA plus avgifter per utfärdat certifikat.

Begränsningarna nedan gäller för båda, eftersom de levereras som en enda upplevelse för de flesta team.

De verkliga begränsningarna med AWS Certificate Manager

1. Det kostnadsfria offentliga certifikatet var aldrig riktigt ditt

ACM:s huvudfunktion är det kostnadsfria publika TLS-certifikatet, men den privata nyckeln för ett "standard" offentligt ACM-certifikat kan inte exporteras. Certifikatet kan bara bindas till ACM-integrerade AWS-tjänster. Om din TLS-terminerande slutpunkt är något annat (en EC2-instans som kör NGINX, en lokal F5, en Azure App Service, en GCP-belastningsutjämnare, ett tredjeparts-CDN, en hårdvaruenhet), kan det kostnadsfria ACM-certifikatet helt enkelt inte distribueras där. Du kommer att köra parallella arbetsflöden: ett ACM-hanterat flöde för AWS-integrerade tjänster och en helt separat process för allt annat. Det är driftsskuld som ökar.

AWS delvis åtgärdat detta i juni 2025 med exporterbara publika certifikat, vilket låter dig ladda ner den privata nyckeln och distribuera certifikatet var som helst. Flexibiliteten är verklig, men ekonomin förändras kraftigt:

• 7 dollar per fullständigt kvalificerat domännamn (FQDN), debiteras vid utfärdande och igen vid varje förnyelse.
• 79 USD per jokernamn (till exempel *.dindomän.com), återigen vid utfärdande och vid varje förnyelse.
• ACM-certifikat har en maximal giltighetstid på 13 månader, med förnyelse vid 11 månader, så förnyelser sker ungefär en gång om året idag.

Det verkar blygsamt tills man räknar ut det på företagsnivå. Med CA/Webbläsarforum Stegvis minskning av giltigheten (200 dagar från mars 2026, 100 dagar från mars 2027, 47 dagar från mars 2029), förnyelser kommer att gå från årliga till ungefär var sjätte vecka inom tre år. Multiplicera det med 500 eller 5 000 FQDN:er och den "kostnadsfria certifikathanteraren" blir en återkommande kostnad per certifikat som skalas linjärt med antalet certifikat.

Slutsatsen är inte att exporterbara certifikat är orimliga, utan att ACM:s prismodell utformades för AWS-intern användning. I det ögonblick du flyttar den utanför den gränsen förändras kostnadsmodellen fundamentalt, och du betalar nu avgifter per certifikat utöver den automatiseringsinfrastruktur du fortfarande behöver bygga för driftsättning.

2. Automatiseringen slutar vid AWS gräns

Inom AWS är ACM utmärkt. Förnyelser på ELB, CloudFront, API Gateway och liknande tjänster hanteras tyst. Certifikatet roterar, den integrerade tjänsten hämtar det nya certifikatet och det finns inget för operatören att göra.

Utanför AWS distribuerar ACM ingenting. För ett exporterbart certifikat som är avsett för en lokal F5, en NGINX-server, en Citrix ADC, en Kubernetes-ingång som inte finns i EKS, eller någon annan icke-AWS-slutpunkt, upphör ACM:s ansvar vid API-anropet. Du kan prenumerera på Amazon EventBridge för förnyelsemeddelanden, men själva provisioneringen, nyckelrotationen på enheten, den virtuella serverns bindning till lastbalanseraren, omstart av lyssningstjänsten och valideringen av det nya certifikatet är helt ditt problem att lösa.

Det innebär anpassade skript, anpassade IAM-policyer, anpassad felhantering och en anpassad revisionslogg. Varje team vi har hjälpt till att bygga detta slutar med att återuppfinna samma kontrollplan: en kö av certifikathändelser, en arbetare som hämtar det nya certifikatet, ett kopplingsbibliotek för varje typ av målslutpunkt, en mekanism för återförsök vid partiella fel och en återställningsplan när det nya certifikatet inte fungerar i applikationen. Det är precis vad en specialbyggd CLM-plattform ska göra, och det är precis vad ACM inte gör när man lämnar AWS-gränsen.

3. Lagret är fragmenterat efter konto och region

ACM:s inventering är begränsad till ett enda AWS-konto och en enda region. Om du bedriver verksamhet över 12 konton och 4 regioner har du 48 logiska certifikatinventeringar att spåra, och det finns ingen inbyggd enskild vy över dem.

CloudFront-begränsningen förvärrar detta. Även om din applikation körs helt i ap-south-1 eller eu-west-1, CloudFront kräver att certifikatet är i us-east-1Så en typisk distribution i flera regioner innehåller samma logiska certifikat i två regioner: en i us-east-1 för CDN:et, en i programmets faktiska region för lastutjämnaren. Det finns ingen automatisk synkronisering, ingen delad inventering och ingen inbyggd vy över flera regioner. I praktiken får identiska domäner separata certifikat utfärdade och förnyade oberoende av varandra, utan inventering som binder dem samman.

För säkerhets- och revisionsteam är denna fragmentering ett verkligt problem. Man kan inte tillämpa en organisationsomfattande policy ("inga RSA-2048-certifikat efter den 1 januari 2027" eller "alla certifikat måste ha en registrerad ägare") om det inte finns något enskilt lager att tillämpa mot. Man kan inte köra en kryptografisk statusbedömning före postkvantmigration om du inte kan se vad du har. Och skuggcertifikat, de som en utvecklare begärde för två år sedan i en region som ingen övervakar längre, är precis de som orsakar avbrott på lördagskvällar.

4. AWS Private CA-prissättningar sammanställs snabbt

AWS Private CA:s publicerade priser är enkelt, men siffrorna läggs ihop snabbare än de flesta lag förväntar sig:

• 400 USD per privat CA per månad för allmänt läge (valfri giltighetsperiod)
• 50 USD per privat CA per månad för korttidscertifikatläge (max 7 dagars giltighetstid)
• Utgivningsnivåer per certifikat från en generell CA: 0.75 USD för de första 1 000, 0.35 USD för de kommande 9 000 och 0.001 USD över 10 000
• 0.06 USD per certifikat per månad för OCSP-svar (faktureras endast för certifikat som faktiskt tar emot OCSP-förfrågningar)

För en typisk tvånivåhierarki (en offline-rot-CA och en online-utfärdande CA) ligger du på 800 dollar per månad innan du utfärdar ett enda certifikat. Lägg till hög tillgänglighet över flera regioner så kan du enkelt nå 1 600 till 2 400 dollar per månad. För ett tillverknings- eller IoT-användningsfall som utfärdar 50 000 enhetscertifikat per månad är avgifterna per certifikat rimliga tack vare volymnivån, men månadsavgiften per CA skalas inte ner: varje regional CA, varje separat förtroendehierarki, varje testmiljö kostar samma fasta 400 dollar per månad.

Jämför detta med en egenhostad Microsoft AD CS-hierarki, där marginalkostnaden per certifikat efter den initiala driftsättningen i praktiken är noll, eller ett hanterat PKI-erbjudande där kostnaden amorteras på annat sätt. AWS Private CA är bekvämt men det är inte den billigaste vägen, och kostnadsmodellen belönar konsolidering till en enda CA snarare än den separation av arbetsuppgifter som många säkerhetsteam faktiskt vill ha.

5. Efterlevnadsrapportering är en självbyggande sak

ACM producerar inte färdiga efterlevnadsrapporter på certifikatnivå för PCI DSS, HIPAA, SOC 2, DORA, eller något annat ramverk. AWS tillhandahåller angränsande funktioner (AWS Config-regler kan upptäcka icke-kompatibla ACM-certifikat, Security Hub har standardmappningar som flaggar fynd, AWS Artifact ger dig AWS servicenivårapporter), men ingen av dessa är en nyckelfärdig "visa mig, per avdelning, granskningsklar status för varje certifikat, vem som äger det, vilken algoritm det använder, när det går ut och om det avvek från policyn vid utfärdandet".

För ett reglerat företag visar sig den bristen vid revisionstillfället. Compliance-teamet ber "att producera en rapport över varje TLS-certifikat som omfattas, med nyckellängd, SAN-poster, ägarskap, utfärdande CA, utgångsdatum och policyefterlevnad." Med enbart ACM bygger du den rapporten från en blandning av beskriv-certifikat-anrop, anpassade Lambda-funktioner, AWS Config-exporter och ett kalkylblad som har redigerats för hand. Det mogna CLM-arbetsflödet är att klicka på en knapp och få rapporten, schemalagd varje vecka, levererad till revisorns inkorg.

6. Leverantörsinlåsning minskar kryptoagilitet

Två branschförändringar konvergerar under de närmaste åren, och båda kräver kryptoagilitet:

• CA / webbläsarforum Valsedel SC-081v3, som godkändes i april 2025, minskar den maximala giltighetstiden för offentliga TLS från dagens 398 dagar till 200 dagar (mars 2026), 100 dagar (mars 2027) och 47 dagar (mars 2029). Fönstret för återanvändning av domänvalidering sjunker till 10 dagar i mars 2028.
• NIST: s post-kvantkryptografi Övergångstidslinjen kräver att organisationer avvecklar äldre RSA och ECC senast 2030 och ersätter dem helt senast 2035. ML-DSA och ML-KEM (FIPS 204 och 203) är de nya standarderna. AWS har börjat lägga till ML-DSA-stöd till AWS KMS och AWS Private CA, men den bredare operativa historien om att byta algoritmer över en kedja är större än en CA.

Krypto-agility är möjligheten att byta CA:er, algoritmer, nyckelstorlekar, giltighetsperioder och distributionsmål utan att behöva omstrukturera ditt kontrollplan. Om din certifikathantering är arkitekturmässigt knuten till en leverantör saknar du kryptoagilitet, utan ett beroende. I det ögonblick AWS ändrar en prissättningsmodell, ändrar ett serviceavtal, avskriver en funktion, eller ditt affärsmål ändras och du behöver flytta arbetsbelastningar till Azure eller GCP, är kostnaden för att avveckla det beroendet kostnaden för att bygga om din CLM-stack. Det är en dålig position att befinna sig i när man går in i både 47-dagars mandat och PQC-migrationen.

47-dagarsmandatet skärper varje gap

Allt ovanstående blir svårare i takt med att certifikatets giltighetstid krymper. Idag förnyas ett typiskt TLS-certifikat en gång om året. I mars 2026 blir det ungefär var sjätte och en halv månad. I mars 2027, var tredje och en halv månad. I mars 2029, var sjätte och en halv vecka.

Det är en åttafaldig ökning av förnyelsefrekvensen på under tre år. Varje lucka i ACM:s automatisering, varje region du måste kontrollera separat, varje slutpunkt utanför AWS-gränsen som behöver ett manuellt distributionsskript, varje efterlevnadsrapport du sammanställer för hand, allt detta skalas linjärt med förnyelsefrekvensen. Ett arbetsflöde som är irriterande med 12 månaders giltighetstid blir operativt ohållbart efter 47 dagar.

Det är just därför branschdiskussionen har skiftat så kraftigt mot slutna, leverantörsneutrala CLM. Det beror inte på att ACM är dåligt, utan på att partiell automatisering helt enkelt inte överlever volymen.

Hur CertSecure Manager åtgärdar dessa brister

CertSecure-hanterare, Encryption Consultings CLM-plattform, byggdes av PKI-experter som hanterar exakt dessa scenarier i klientuppdrag varje dag. Där ACM slutar vid AWS-gränsen, tar CertSecure Manager upp:

• Flera CA, leverantörsneutral genom design. CertSecure Manager ansluter till Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust och andra publika och privata CA:er via en enda konsol. Du får ett lager, ett policyplan, en förnyelsekö, oavsett vilken CA som utfärdat certifikatet eller vilket moln arbetsbelastningen finns i.
• Sluten automatisering bortom AWS. Förnyelseagenter för Apache, Tomcat, IIS, F5 BIG-IP, NGINX och anpassade interna applikationer hanterar distributionssteget som ACM inte gör. Den nya CertSecure Manager Orchestrator för F5, byggt genom vårt partnerskap i F5 Application Delivery and Security Platform Partner Program, mappar automatiskt varje certifikat till rätt SSL-profil för den virtuella F5-servern, vilket eliminerar det manuella bindningssteget som orsakar de flesta certifikatrelaterade F5-avbrott.
• Standardregistreringsprotokoll. REST API- och ACME-slutpunkter låter molnbaserade och DevOps-arbetsbelastningar registreras automatiskt, på samma sätt som de skulle göra mot Let's Encrypt eller någon annan standard ACME-slutpunkt. Det betyder att cert-manager i Kubernetes, certbot på en Linux-värd eller en anpassad CI/CD-pipeline alla kan registreras via samma protokoll.
• Centraliserad synlighet i molnet och lokalt. Automatiserad certifikatidentifiering skannar din miljö, bygger en enhetlig inventering över AWS-konton och regioner, Azure-, GCP-, lokala och Kubernetes-kluster, och visar ägarskap, algoritm, giltighet och policyefterlevnad för varje certifikat i en instrumentpanel.
• Policytillämpning och godkännanden. Globala och avdelningsspecifika policyer täcker minsta nyckelstorlek, tillåtna algoritmer, FIPS-godkända begränsningar, regler för jokertecken, regler för återanvändning av CSR, DNS-vitlistning för domänvalidering och arbetsflöden för godkännande av M-of-N för certifikatmallar med hög tillförlitlighet. Dessa policyer tillämpas vid utfärdandetillfället, inte i efterhand.
• Revisionsklar efterlevnadsrapportering. Schemalagda rapporter levereras varje vecka eller månad till efterlevnadsbrevlådan, med den information på certifikatnivå som PCI DSS, HIPAA, SOC 2 och DORA-revisioner som faktiskt efterfrågas. Ingen manuell export, ingen sammanfogning av kalkylblad.
• Inbyggd kryptoagilitet. Eftersom CertSecure Manager är CA-agnostisk är det en policyändring snarare än en omarkitektur att byta ut den underliggande CA:n, rotera till en ny nyckelalgoritm eller migrera från en leverantör till en annan. Det spelar roll inför både 47-dagarsmandatet och PQC-migreringen.

När ACM är tillräckligt, och när det inte är det

Inte alla team behöver en komplett CLM-plattform. Här är en praktisk översikt över var ACM ensamt är tillräckligt och var det inte längre räcker:

Scenario	ACM ensam	Leverantörsneutral CLM
Ett AWS-konto, en region, helt AWS-nativa arbetsbelastningar	Ja	Nej
Färre än 100 certifikat, alla på ACM-integrerade tjänster	Ja	Nej
Multimoln (AWS + Azure och/eller GCP)	Nej	Ja
Hybridmoln med lokal anläggningstillgång (AD CS, F5, NGINX, Apache, IIS)	Nej	Ja
Över 1 000 certifikat över flera certifikatutfärdare och miljöer	Nej	Ja
Strikt efterlevnadspolicy (PCI DSS, HIPAA, SOC 2, DORA, reglerade branscher)	Nej	Ja
Kubernetes och containerbaserade arbetsbelastningar som spänner över moln	Nej	Ja
Förbereder för 47-dagars giltighet med eventuella icke-AWS-slutpunkter	Nej	Ja
Att närma sig PQC-migrering med en heterogen CA-egendom	Nej	Ja

Mönstret är enkelt. ACM är tillräckligt där certifikatpositionen är begränsad, AWS-nativ och liten. I det ögonblick som något av dessa tre villkor upphör, betalas kostnaden för att stanna kvar hos ACM enbart i form av driftskomplexitet, granskningssmärta och avbrottsrisk.

Slutsats

ACM är en genuint bra tjänst inom sitt designområde. Misstaget är att anta att området matchar företagets verklighet. De flesta organisationer arbetar över flera moln, flera CA:er och en lång svans av lokala slutpunkter som ACM inte kan nå. 47-dagars TLS-giltighetstidslinjen och PQC-migreringen kommer att göra varje lucka i ACM:s automatisering, synlighet och policytillämpning betydligt mer smärtsam än den är idag.

Rätt tillvägagångssätt är att använda ACM där det är bäst (kostnadsfria publika certifikat på AWS-integrerade tjänster, smidiga förnyelser inom AWS-gränserna) och att lägga en leverantörsneutral CLM-plattform ovanpå för att hantera allt som ACM aldrig var utformat för att göra. Det ger dig den operativa enkelheten hos ACM där det fungerar, och den automatisering, styrning och kryptoagilitet över flera miljöer som du behöver överallt annars.