Hur man importerar SSL/TLS-certifikat i IIS Server Manager

Snabbt svar: Att importera ett certifikat till IIS Server Manager innebär att kombinera SSL/TLS-certifikatet med dess privata nyckel i .PFX-format, och sedan antingen importera .PFX-filen via Server Certificates eller binda ett redan installerat certifikat till en webbplats via Site Bindings. Processen tar cirka 10 till 15 minuter när certifikatet, förutsättningarna och behörigheterna är på plats.

SSL/TLS-certifikat är det som gör det möjligt att hosta en webbplats på IIS (Internet Information Services) utan att exponera varje förfrågan i klartext. De krypterar trafiken mellan servern och webbläsaren, vilket är anledningen till att de inte är valfria för någon IIS-webbplats som hanterar PII, PHI, PCI-data eller något annat som en angripare kan fånga upp genom en man-in-the-middle-attack.

Det knepiga är sällan konceptet. Det handlar om hur man får ett certifikat som utfärdats eller hanterats någon annanstans till ett format som IIS faktiskt accepterar, och sedan binder det korrekt utan att en befintlig webbplats skadas. Den här guiden går igenom båda, förutsättning för förutsättning och skärm för skärm, och pekar ut var de flesta team förlorar tid eller introducerar ett förebyggbart avbrott.

Key Takeaways

• IIS Server Manager behöver certifikatet och den privata nyckeln tillsammans i .PFX-format; ett certifikat utan dess privata nyckel kan inte importeras.
• Det finns två stödda sökvägar: att importera en .PFX-fil direkt eller att binda ett certifikat som redan finns i den lokala datorns certifikatarkiv.
• De flesta bindningsfel kan spåras tillbaka till att programpoolens identitet inte har läsåtkomst till den privata nyckeln, inte till själva certifikatet.
• Offentliga TLS-certifikat har ett krympande giltighetsschema enligt CA/Browser Forum Ballot SC-081v3: 200 dagar från mars 2026, 100 dagar från mars 2027 och 47 dagar från mars 2029, vilket gör manuell import och bindning till en återkommande uppgift, inte en engångsuppgift.
• En undersökning från DigiCert Trust Pulse som publicerades i juli 2025 visade att 45 procent av företagen hade certifikatrelaterade driftstopp under det senaste året, och 37.5 procent av dessa incidenter orsakades av utgångna certifikat, vilket är exakt det felläge som manuell IIS-bindning är benägen att uppleva.

Snabb checklista innan du börjar

• Begäran om certifikatsignering (CSR) har skickats in och ett giltigt certifikat har utfärdats av en betrodd certifikatutfärdare (CA).
• Certifikatet är tillgängligt i, eller kan exporteras till, .PFX-format med sin privata nyckel.
• IIS installerat, körs och kan nås med administratörsåtkomst.
• Administrativa rättigheter till servern och till certifikathanteringskonsolen (certlm.msc).
• Privat nyckel säkerhetskopieras säkert före export, ifall arbetskopian förloras eller skadas.
• Ett underhållsfönster identifierat, ifall webbplatsbindningen behöver en återställning.

Varför detta är viktigt för hantering av företagscertifikats livscykel

Att importera ett certifikat till IIS ser ut som en liten, mekanisk uppgift tills det multipliceras över hela företaget. Enligt DigiCerts Trust Pulse Survey, publicerad 2 juli 2025, rapporterade 45 procent av företagen certifikatrelaterade driftstopp under det senaste året, och 37.5 procent av dessa incidenter orsakades specifikt av utgångna certifikat ( DigiCert, juli 2025 ). Manuell import och bindning, upprepad server för server, är precis den typ av process som producerar det felmönstret: det beror på att någon kommer ihåg att förnya, exportera, importera och binda om innan det gamla certifikatet upphör att gälla.

Den risken förvärras eftersom certifikatens livslängd krymper. Enligt CA/Browser Forum Ballot SC-081v3, godkänt av Sectigo och antaget den 14 april 2025, sjunker den maximala giltighetstiden för offentliga TLS-certifikat från 398 dagar till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029 ( Sectigo, april 2025 ). En manuell import-och-bind-process som var tolererbar under en 398-dagars- eller till och med 200-dagarscykel blir en nästan månatlig driftsbörda vid 47 dagar, och en nästan månatlig möjlighet för en missad förnyelse att stänga ner en produktionsanläggning. Detta är den viktigaste anledningen till att 47-dagars TLS-certifikatberedskap och certifikatautomatisering har gått från att vara en bra idé till en schemaläggningsnödvändighet för alla team som kör IIS i stor skala.

Förutsättningar innan du börjar

Bekräfta vart och ett av dessa innan du startar importen. Att hoppa över en förutsättning är den vanligaste orsaken till att guiden misslyckas halvvägs eller att webbplatsbindningen inte träder i kraft.

1. CSR och utfärdat certifikat: Generera en begäran om certifikatsignering (CSR) för domänen, inklusive det gemensamma namnet, organisationsuppgifter och plats, och skicka in det till en certifikatutfärdare (CA) för att erhålla det undertecknade intyget.
2. Certifikat i .PFX-format: Bekräfta att certifikatet är tillgängligt, eller kan exporteras, som en .PFX-fil som paketerar certifikatet och dess privata nyckel. Detta är det enda format som IIS Server Manager accepterar för direktimport.
3. Certifikat iscensatt i den personliga butiken: Importera certifikatet till den lokala datorn eller det personliga certifikatarkivet innan du försöker importera det till IIS, om det inte redan finns där.
4. IIS installerat och körs: Bekräfta att IIS är installerat via Serverhanteraren eller guiden Lägg till roller och funktioner på Windows Server, och att tjänsten körs och är konfigurerad för att vara värd för målplatsen.
5. Administrativ åtkomst: Bekräfta administratörsbehörigheter på servern och i certifikathanteringskonsolen, eftersom både import- och bindningsstegen kräver dem.
6. Säkerhetskopiering av privat nyckel: Säkerhetskopiera den privata nyckeln säkert innan export, eftersom förlust av den gör certifikatet oanvändbart och tvingar fram en ny utfärdande.

Om du hanterar certifikat via en tredjepartsplattform för certifikatlivscykelhantering (CLM) som inte kan utfärda en .PFX-fil direkt, är det just detta som gör nästa avsnitt, att exportera till PFX manuellt, nödvändigt.

Steg för steg: Exportera certifikatet till PFX-format

Det är .PFX-formatet som gör certifikatet importerbart till IIS, eftersom det paketerar certifikatet och den privata nyckeln tillsammans. Dessa steg använder certifikathanteringskonsolen (certlm.msc).

1. Öppna konsolen för certifikathantering: Körning certlm.msc, Eller gå till Arkiv> Lägg till / ta bort Snap-in, Välj Certifieringar, klicka på Lägg tillväljer Mitt användarkonto, Klicka sedan Finish och OK.
2. Leta reda på certifikatet: Navigera till Certifikat – Nuvarande användare > Personligt > Certifikat.
3. Starta exporten: Högerklicka på certifikatet och välj Alla uppgifter> Exportera.
4. Exportera den privata nyckeln: I guiden Exportera certifikat klickar du på Nästa, Välj sedan Ja, exportera den privata nyckeln, och klicka Nästa igen.
5. Välj .PFX-formatet: Välj alternativet .PFX och klicka på Nästa.
6. Ange ett lösenord och spara plats: Ange ett lösenord för att skydda filen, klicka på Nästa, välj var du vill spara det och klicka på Finish.

Certifikatet är nu i .PFX-format och redo att importeras till IIS Server Manager. Det finns två sätt att slutföra importen: importera .PFX-filen direkt eller bind ett certifikat som redan finns i det lokala maskinarkivet. Om PFX-export blockeras av en begränsning för certifikatmallen, gå vidare till metod 2 nedan.

Steg för steg: Importera och binda certifikatet i IIS

Metod 1: Importera via en .PFX-fil

Steg 1: Öppna IIS-hanteraren och navigera till avsnittet Servercertifikat.

Steg 2: Importera certifikatet. I åtgärdsfönstret till höger väljer du Importera , bläddrar till .PFX-filen, anger lösenordet och klickar på OK.

När importen är klar är certifikatet tillgängligt för IIS och redo att bindas till en webbplats.

Obs! Om exporten till .PFX misslyckas på grund av en begränsning i certifikatmallen, låter metod 2 dig binda certifikatet utan att behöva en .PFX-fil alls.

Metod 2: Bind ett befintligt certifikat från certifikatbindningar

Använd den här metoden om certifikatet och dess privata nyckel redan finns i det lokala maskinarkivet.

Steg 1: Öppna webbplatsbindningar. I IIS-hanteraren väljer du standardwebbplatsen (eller målwebbplatsen) i den vänstra rutan och väljer sedan Bindningar i den högra åtgärdsrutan.

Steg 2: Redigera port 443-bindningen. Leta reda på och välj bindningen för port 443 och klicka sedan på Redigera.

Steg 3: Koppla certifikatet. Ange värdnamnet som är kopplat till certifikatet, välj rätt certifikat från rullgardinsmenyn, använd Visa för att bekräfta att det är rätt certifikat och klicka på OK.

Felsökning av bindningsfel

Om redigering av webbplatsbindningen ger ett fel är det nästan alltid ett behörighetsproblem för den privata nyckeln snarare än ett problem med själva certifikatet.

1. Kontrollera programpoolens identitet: Bekräfta vilket konto webbplatsens programpool körs under, och att det är nätverkstjänstkontot eller en motsvarande identitet med certifikatåtkomst.
2. Öppna certifikatarkivet: Körning certlm.msc och leta upp certifikatet under Personligt > Certifikat.
3. Hantera privata nycklar: Högerklicka på certifikatet, gå till Alla uppdrag, och välj Hantera privata nycklar.

4. Bevilja åtkomst: Klicka Lägg till, Typ Nätverkstjänst som objektnamn, klicka på Kontrollera namnoch tilldela Läsa lov.

5. Starta om IIS: Körning iisreset från en förhöjd kommandotolk och försök sedan igen med bindningen.

Du har importerat och bundit certifikatet. Webbplatsen bör nu hantera trafik via HTTPS med det nya certifikatet.

Tabell över förutsättningar för åtgärd

Använd den här tabellen för att bekräfta ägarskap innan importen påbörjas, särskilt i miljöer där ansvaret för PKI, säkerhet, plattform och efterlevnad ligger hos olika team.

Förutsättning	Ägare	Handling
Giltigt CSR och utfärdat certifikat	PKI-teamet	Generera CSR-en, skicka in den till CA och bekräfta att det utfärdade certifikatet matchar det avsedda värdnamnet.
Certifikat i .PFX-format	PKI-teamet	Exportera certifikatet och den privata nyckeln till .PFX, eller bekräfta att CLM-plattformen kan leverera det i det formatet.
Administrativ åtkomst till servern	Plattformsteam	Ge tidsbegränsad administrativ åtkomst till ingenjören som utför importen.
Identitetsbehörigheter för programpooler	Plattformsteam	Bekräfta att programpoolens identitet har läsåtkomst till den privata nyckeln innan bindning.
Ändrings- och återställningsfönster	Säkerhetsteam	Godkänn ett underhållsfönster och bekräfta att det finns en återställningsplan före bindningsändringen.
Revisionsbevis för förändringen	Compliance-teamet	Registrera certifikatets serienummer, utfärdandedatum och bindningsdatum för certifikatregistret.

Före och efter: Manuellt kontra automatiserat arbetsflöde för certifikatimport

Stegen ovan fungerar bra för en enskild server eller en tillfällig förnyelse. Jämförelsen nedan visar varför samma process blir en belastning i stor skala, särskilt när giltighetsfönstren krymper mot 47 dagar.

Steg	Manuellt arbetsflöde	Automatiserat arbetsflöde (CertSecure Manager)
Certifikatbegäran	Ingenjören genererar manuellt CSR och skickar till CA	Registrering utlöses automatiskt via ACME, SCEP eller EST
Exportera till .PFX	Manuell export via certlm.msc, per server	Levereras i önskat format av automatiseringsagenten
Importera och bind	Manuella steg genom IIS Manager, per webbplats	IIS-automatiseringsagenten tillämpar bindningen direkt
Förnyelsespårning	Förlitar sig på att en person kommer ihåg utgångsdatumet	Centralt spårad med automatisk förnyelse före utgångsdatum
Feltillstånd	Missad förnyelse orsakar ett avbrott vid utgångsdatum	Förnyelse och ombindning sker före deadline

Återställningsvägledning

Om det nya certifikatet orsakar bindningsfel, webbläsarvarningar eller om webbplatsen inte fungerar som den ska, återställ det istället för att fortsätta felsöka i produktion.

1. Öppna igen Webbplatsbindningar för den berörda webbplatsen och redigera port 443-bindningen.
2. Välj det tidigare, fortfarande giltiga certifikatet från rullgardinsmenyn och klicka på OK.
3. Körning iisreset för att tillämpa ändringen, bekräfta sedan att webbplatsen laddas korrekt via HTTPS.
4. Ta inte bort det nya certifikatet från arkivet förrän grundorsaken till felet har bekräftats, så att det kan importeras igen när det är åtgärdat.
5. Logga återställningen och orsaken i ändringsposten för complianceteamet.

Vanliga fel och korrigeringar

• "Parametern är felaktig" under exporten: Vanligtvis betyder det att den privata nyckeln är markerad som icke-exporterbar. Utfärda certifikatet igen med den privata nyckeln inställd på exporterbar, eller använd metod 2 för att binda det utan att exportera.
• Certifikatet visas inte i rullgardinsmenyn för bindning: Certifikatet finns inte i den lokala datorns personliga arkiv, eller så importerades det istället till den aktuella användararkivet. Importera det till datorarkivet igen.
• ”Det går inte att hitta certifikatnyckelbehållaren” eller liknande åtkomstfel: Programpoolens identitet saknar läsåtkomst till den privata nyckeln. Bevilja läsbehörighet via Hantera privata nycklar, enligt felsökningsstegen ovan.
• Webbläsaren visar fortfarande det gamla certifikatet efter bindning: Webbplatsen startades inte om, eller så cachar en lastbalanserare eller ett CDN framför den det föregående certifikatet. iisreset och kontrollera eventuella uppströms anslutningspunkter.
• Varning om värdnamnsmatchning: Det bundna certifikatets vanliga namn eller SAN-poster matchar inte webbplatsens värdnamn. Kontrollera att CSR:n genererades för rätt domän innan du utfärdar det på nytt.

Framgångsmått att spåra efter implementering

Spåra dessa efter utrullningen för att bekräfta att import- och bindningsprocessen fungerar och för att bygga upp argument för automatisering om siffrorna rör sig åt fel håll när giltighetsperioderna krymper.

• Certifikatrelaterade driftstopp per kvartal
• Genomsnittlig tid för att importera och binda ett certifikat, per server
• Antal certifikat som förnyats inom giltighetsfönstret jämfört med sent förnyade
• Antal manuella supportärenden relaterade till certifikatbindning eller utgång
• Procentandel av IIS-servrar med certifikatlivscykel synlig i en central inventering snarare än spårad lokalt

Team som flyttar detta arbetsflöde till CertSecure Manager rapporterar vanligtvis att automatiseringen minskar manuella certifikatärenden och minskar förnyelse- och distributionstiden jämfört med den manuella processen per server som beskrivs ovan. Fråga ditt CertSecure Manager-kontoteam om referenssiffrorna för din miljö för innevarande kvartal.

Multimoln- och hybrid-PKI-miljöer

Stegen i den här guiden gäller för en enda Windows-server som kör IIS. I en miljö med flera moln eller hybrider kan samma certifikat behöva distribueras konsekvent över lokala IIS-servrar, molnbaserade virtuella maskiner och lastbalanserare från olika leverantörer, var och en med sin egen importmekanism. Att upprepa dessa steg manuellt över varje instans multiplicerar både ansträngningen och risken för en missad förnyelse.

Det är här kryptoflexibilitet och centraliserad certifikatidentifiering är viktiga, bortom en enda server. En aktuell, korrekt inventering av varje certifikat som används, lokalt och i molnet, är det som gör det möjligt att veta vilka IIS-instanser som behöver den här uppdateringen innan ett utgångsdatum orsakar ett avbrott, snarare än att ta reda på det i efterhand. Att bygga den inventeringen tillsammans med PQC- beredskapsplanering innebär också att samma identifieringsarbete stöder nästa migrering, inte bara den här.

Ägare och åtgärdsmatris per team

Team	Ansvar	Åtgärdspunkt
PKI-teamet	Certifikatutfärdande och format	Bekräfta att alla IIS-bundna certifikat kan levereras i .PFX-format eller automatiseras via CLM-plattformen.
Säkerhetsteam	Risk- och förändringskontroll	Kräv en återställningsplan och ett underhållsfönster för varje ändring av produktionsbindning.
Plattformsteam	Konfiguration av server och applikationspool	Verifiera behörigheterna för programpoolens identitet på den privata nyckeln före varje bindningsändring.
Compliance-teamet	Revisionsbevis och anpassning av regelverk	Upprätthåll ett certifikatregister som visar utfärdande-, bindnings- och utgångsdatum för varje IIS-värdbaserad tjänst som omfattas av regleringen.

Hur kan krypteringskonsultation hjälpa till?

CertSecure Manager, vår CLM- plattform, inkluderar automatiseringsagenter för IIS, Apache, Tomcat och lastbalanserare som F5, så certifikatförnyelse, leverans i rätt format och distribution, inklusive bindning till den värdbaserade tjänsten, sker utan att man manuellt går igenom stegen i den här guiden. Det eliminerar de två vanligaste felpunkterna som nämns ovan: en missad förnyelse och en privat nyckelbehörighet som aldrig beviljades.

För team som också spårar sin bredare kryptografiska egendom bygger och underhåller CBOM Secure en kontinuerlig inventering av certifikat och kryptografiska tillgångar i lokala och molnmiljöer, vilket är grunden både för att fånga IIS-certifikat innan de löper ut och för att planera framåt för post-kvantummigrering . Se hur de två kopplas samman i From Discovery to Action: How a Cryptographic Bill of Materials Turns Inventory into Intelligence. Våra hanterade PKI-tjänster ger heltäckande support för certifikatutfärdande, förnyelse och felsökning när en manuell korrigering som den i den här guiden inte räcker till.

Slutsats

Att importera ett SSL/TLS-certifikat till IIS Server Manager handlar om två saker: att få certifikatet och den privata nyckeln i .PFX-format och binda dem korrekt med rätt behörigheter. Båda metoderna i den här guiden tar dig dit, och felsökningsstegen täcker det behörighetsproblem som orsakar de flesta bindningsfel. När certifikatgiltighetsperioderna krymper mot 47 dagar är den större frågan om det fortfarande är hållbart att upprepa processen manuellt, server för server, eller om det är dags att flytta förnyelse- och bindningsarbetet till en automatiserad plattform för certifikatlivscykeln.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från En guide om hur man importerar certifikat till IIS Server Manager?

Certifikatet och dess privata nyckel måste kombineras till .PFX-format innan IIS kan använda dem, och de kan sedan tillämpas antingen genom att importera .PFX-filen direkt via Server Certificates eller genom att binda ett redan installerat certifikat via Site Bindings. De flesta fel beror på ett behörighetsgap på den privata nyckeln snarare än ett problem med själva certifikatet.

Varför är detta viktigt för hanteringen av företagscertifikats livscykel?

En enda import är en liten uppgift, men att upprepa den manuellt över hundratals IIS-servrar, med en giltighetscykel som krymper mot 47 dagar, förvandlar ett rutinmässigt steg till en återkommande källa till avbrott. DigiCerts Trust Pulse-undersökning från juli 2025 fann att 45 procent av företagen hade certifikatrelaterad driftstopp under det senaste året, varav 37.5 procent orsakades av utgångna certifikat.

Vilka team ansvarar för att agera utifrån denna vägledning?

PKI-teamen äger certifikatutfärdande och format, säkerhetsteamen äger ändringskontroll och godkännande av återställning, plattformsteamen äger server- och applikationspoolkonfigurationen, och efterlevnadsteamen äger certifikatregistret och revisionsbevisen. Ägar- och åtgärdsmatrisen ovan tilldelar varje ansvar uttryckligen.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell import och bindning per server ökar risken för missade förnyelser, ett inkonsekvent certifikat mellan lastbalanserade instanser och odokumenterade ändringar som efterlevnadsteam inte kan ta hänsyn till under en granskning. Allt eftersom giltighetstider krymper måste samma manuella process köras oftare, vilket mångfaldigar alla dessa risker.

Hur minskar automatisering risken för certifikatavbrott?

Automatiserad hantering av certifikatlivscykeln spårar centralt utgångsdatum, förnyar certifikat före deadline och levererar och binder dem till IIS, Apache, Tomcat eller lastbalanserare via en agent snarare än en manuell process per server, vilket eliminerar beroendet av att någon kommer ihåg att agera före utgångsdatum.

Vilka mätvärden bör teamen följa efter implementeringen?

Spåra certifikatrelaterade driftstopp per kvartal, genomsnittlig tid för att importera och binda ett certifikat, andelen certifikat som förnyats inom deras giltighetsfönster, manuell ärendevolym kopplad till certifikatproblem och andelen servrar med certifikatstatus synlig i en central inventering.

Hur kopplas detta till 47-dagars TLS-certifikatberedskap?

CA/Browser Forum Ballot SC-081v3 fasar ner maximal giltighetstid för offentliga TLS-certifikat till 200 dagar i mars 2026, 100 dagar i mars 2027 och 47 dagar i mars 2029. Varje IIS-server som förlitar sig på den manuella processen i den här guiden kommer att behöva upprepas mycket oftare, vilket är det operativa argumentet för att gå över till automatisk förnyelse och bindning innan de kortare fönstren träder i kraft.

Hur ska detta hanteras i multimoln- eller hybrid-PKI-miljöer?

Samma certifikat behöver ofta distribueras på lokala IIS-servrar, virtuella molnmaskiner och lastbalanserare från olika leverantörer. En central, kontinuerligt uppdaterad certifikatinventering gör det möjligt att veta vilka instanser som fortfarande behöver uppdateringen, snarare än att upptäcka en lucka efter att ett certifikat redan har löpt ut någonstans i certifikatet.

Vilka förutsättningar behövs innan implementering?

En giltig CSR och utfärdat certifikat, certifikatet tillgängligt eller exporterbart i .PFX-format, administrativ åtkomst till servern och certifikathanteringskonsolen, IIS installerat och igång, och en säker säkerhetskopia av den privata nyckeln före export. Avsnittet om förkunskapskrav ovan täcker allt i detalj.

Vilka skärmdumpar eller konfigurationsexempel bör inkluderas?

De mest användbara skärmdumparna är stegen i guiden Certifikatexport för att skapa .PFX-filen, importskärmen för Servercertifikat, redigeringsdialogrutan för Webbplatsbindningar som visar värdnamn och certifikatval, och skärmen Hantera behörigheter för privata nycklar som används för att åtgärda det vanligaste bindningsfelet. Den här guiden tar med alla steg i ordning.