Här hittar du guider för hur man skapar en begäran (CSR) för beställning, samt installerar SITHS Funktionscertifikat.

Innehållsförteckning

Revisionshistorik

Installation av tillit till SITHS Funktionscertifikat

För att ett system ska kunna använda eller kommunicera med ett annat system som använder SITHS Funktionscertifikat måste båda systemen lita på de certifikatutfärdare som SITHS använder för att digitalt signera det certifikat som ni sedan måste installera på er server.

Här finns en guide för hur man installerar tillit till en certifikatutfärdare på Microsoft IIS 10.0: How do I install an SSL Certificate into Microsoft IIS 10? (digicert.com)

De SITHS certifikatutfärdare som ska installeras som betrodda återfinns på denna sida: PKI-struktur och rotcertifikat.

För användning av SITHS funktionscertifikat gäller för tillfället följande rotcertifikat och mellanliggande (intermediate) certifikatutfärdare

• Rot: SITHS e-id Root CA v2

  • Mellanliggande: SITHS e-id Function CA v1

• Rot: SITHS Root CA v1

  • Mellanliggande: SITHS Type 3 CA v1

Beställning och installation av SITHS Funktionscertifikat

Dvs. det servercertifikat som utfärdas från SITHS och som er tjänst kommer att använda

Hur beställningen och installationen av certifikatet fungerar ser olika ut beroende på vilket operativsystem/system och applikation/verktyg som används. Använd i första hand guider för det system din organisation använder. Nedan följer ett antal länkar som kan vara en hjälp på vägen.

Vad är ett certifikat?

Här finns en enkel beskrivning vad ett certifikat är

Hantering av nycklar och certifikat

För att SITHS Funktionscertifikat ska vara så säkra som möjligt krävs att:

• Genereringen av privata nycklar görs med en kvalitetssäkrad slumptalsgenerator. (Observera att de enda helt säkra metoderna för detta är att använda en hårdvaruenhet speciellt avsedd för detta. De exempel vi hänvisar till hänvisar till i länken nedan är inte kvalitetssäkrade med avseende på just detta. Dock används de av merparten av alla som beställer servercertifikat, även vid beställning från andra CA’s än SITHS. Det är viktigt att ni själva tar ställning till vilken skyddsnivå ni behöver för era privata nycklar).

• Generering, transport och lagring av nycklar och certifikat sker på ett säkert sätt.

• Certifikat och nycklar aldrig kommer i orätta händer, det vill säga att de aldrig finns på samma plats förutom hos ansvarig mottagare av certifikaten.

Steg 1 - Begäran (CSR) för beställning av SITHS Funktionscertifikat

Hur en CSR (certifikatsigneringsbegäran) genereras är oberoende av SITHS och ser olika ut beroende på vilket operativsystem och applikation som används. Här är några externa guider med exempel på hur detta kan göras.

En CSR innehåller en publik nyckel som inkluderas i ett certifikat som sedan signeras av en CA, till exempel SITHS. Den publika nyckeln är unik och kan endast användas tillsammans med den Privata nyckel som ligger kvar på systemet som används för att skapa CSR-filen. Notera att SITHS behöver en publik nyckel som är av typen RSA och 2048-4096 bitar lång.

Observera att Inera och SITHS inte har säkerhetsgranskat varken metoderna eller applikationerna som listas nedan.

• https://www.digicert.com/csr-creation.htm

Steg 2 – Behörig id-administratör utfärdar certifikatet i SITHS Admin

Installation av certifikat

Här kan du läsa om hur du installerar ditt SITHS-certifikat.

Installation ser olika ut beroende på vilket operativsystem och webbserver som används, och kan även vara beroende av hur den tjänst som ska använda certifikatet är utvecklad. Exempelvis kan en tjänst utvecklad i Java som driftas på Windows, använda antingen Windows certifikatlagring eller en java keystore. När certifikatet installeras kan man presenteras med olika val och möjligheter för att kunna exportera och flytta den Privata nyckeln som finns kvar på det system där CSR-filen skapades. Vid flytt av både certifikat och privata nycklar gäller det dock att säkerställa nycklarnas integritet, så att de inte hamnar i orätta händer. Vi påminner också om man ska beakta de Särskilda villkor som en beställare av ett SITHS-certifikat godtar i samband med beställning och som återfinns i mallen för beställning av SITHS funktionscertifikat.

Installation

För eventuella guider hänvisas i första hand till dokumentationen för det system din organisation använder. Nedan följer några externa guider med exempel på hur installation kan göras på några vanliga system.

Observera att Inera och SITHS inte har säkerhetsgranskat varken metoderna eller applikationerna som listas nedan.

• https://www.digicert.com/ssl-certificate-installation.htm

Verktyg för hantering av certifikat, nycklar och CSR

Här hittar du verktyg för att hantera certifikat, skapa nycklar och CSR (Certificate Signing Request) - så kallad certifikatsigneringsbegäran.

Observera att Inera och SITHS inte har säkerhetsgranskat varken metoderna eller applikationerna som listas nedan.

Linux/Windows

• Openssl (https://www.openssl.org/)

Windows

• Direkt i Microsoft IIS

• SSLTools Manager (http://www.ssltools.com/)

Java

Observera att varje version av Java som installeras får sin egen ”keystore” där certifikat lagras och hanteras.

• Keytool (installeras tillsammans med javainstallationen, https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html

• KeyStore Explorer http://keystore-explorer.sourceforge.net/

Exempel på hela processen i OpenSSL

1. Skapa en krypterad privat nyckel

• Använd kommandot: openssl genrsa -aes256 -out <sökväg och namn till nyckelfilen> 4096.

• Där –aes256 står för typ av kryptering av den privata nyckeln.

• 4096 i slutet står för nyckellängden (måste vara 2048-4096).

• Ange ett lösenord 2 gånger för att skydda den krypterade privata nyckeln.

2.  Skapa en CSR (certifikatsigneringsbegäran)

• Använd kommandot: openssl req -subj ”Önskat subjekt för certifikatet” -new -key  <sökväg och namn till nyckelfilen> -out <sökväg och namn till CSR-filen>. Notering: SITHS kommer skriva över subjektet med organization, locality och country utefter en kontroll av ägarskapet för funktionen

• Ange lösenordet för den krypterade nyckelfilen när OpenSSL efterfrågar det.

3. Verifiera innehållet i en CSR

För att verifiera innehållet i en CSR-fil kan du använda kommandot: openssl req -in <sökväg och namn till CSR-filen> -noout –text.

Du kan då se: DN (fullständig sökväg till objektet), Nyckellängd och typ av nyckel (4096-bitar RSA), exponent (65537, vilket är standard). CSR-filen bifogas certifikatbeställningen som skickas till RA-organisationen.

3b. Konvertera certifikatet till rätt format

OM certifikatet beställs via Inera måste certifikatet först konverteras från binärt (DER) format till base64 (PEM) innan steg 4 kan utföras. Detta görs genom kommandot: openssl x509 -inform DER -in <sökväg och namn till certifikatfilen> -outform PEM -out <önskat namn på den konverterade filen>.

Om filen redan har rätt format får du förmodligen följande felmeddelande istället och kan då gå vidare med steg 4 nedan:

4. Konvertera ett certifikat och en privat nyckel till en PKCS#12 fil

Efter att du har fått tillbaka certifikatet från RA-organisationen kan du packa ihop den privata nyckeln och certifikatet i en och samma bärare. Denna bärare kan sedan användas om man måste transportera ett certifikat och tillhörande privat nyckel. Observera att alla som har tillgång till både privat nyckel och certifikat kan utge sig för att vara den server som certifikatet pekar på, så se till att hantera filerna som en värdehandling. Det är alltid den som står som mottagare på kvittensblanketten som kommer att vara ansvarig för certifikatet och hur det har hanterats.

Kommandot som används är:

• openssl pkcs12 -export -in <Sökväg till certifikatet i base64 format> -inkey <nyckelfilen> -out  <Sökväg till PKCS12 filen>

• Ange eventuellt lösenord för nyckelfilen om du valt att skapa ett sådant. Du måste också välja ett exportlösenord för .p12 filen som används för att packa upp certifikatet och de publika nycklarna.

OBS! Om certifikatsfilen är i fel format kan du få nedan felmeddelande. Säkerställ då att du följt steg 3b ovan.