Den här artikeln kommer att förklara hur man använder certifikat som utfärdats av en tredje parts certifieringsmyndighet (CA), såsom Let's Encrypt, Comodo, Symantec, Digicert etc. Den kommer också att täcka hur certifikat fungerar i allmänhet.
Synopsis
Certifikaten tjänar två huvudsyften: Att kryptera kommunikation mellan två enheter och att bekräfta enhetens äkthet. Den förstnämnda kan beviljas av ett så kallat självsignerat certifikat, men för att autentisera enheten behöver du ett globalt pålitligt certifikat utfärdat av root eller mellanliggande CA. Den här artikeln kommer att förklara hur certifikat generellt uppnår denna autentisering, hur man ändrar certifikatets format så att det fungerar med andra enheter, inklusive våra brandväggar, hur man importerar certifikatet till din brandvägg och hur certifikat ska hanteras för att undvika säkerhetsrisker.
Innehållsförteckning
- Hur fungerar ett certifikat?
- Självsignerade certifikat
- Arbeta med certifikat
- Importerar certifikat i USG / ATP-brandväggar
- Certifikatsäkerhet
Hur fungerar ett certifikat?
Varje certifikat består av två delar: Certifikatet (även kallat den offentliga nyckeln) och den privata nyckeln. Certifikatet kan delas offentligt och innehåller bara information om syftet för vilket certifikatet utfärdades och till vilken enhet certifikatet utfärdades - detta kan vara din FQDN, e-postadress eller annat värde.
Certifikaten har en begränsad giltighetsperiod - detta hjälper till i situationer där något gammalt certifikat med en privat nyckel grävs upp någonstans efter årtionden. Om giltigheten var oändlig kunde certifikatet ändå användas för skadliga ändamål av alla som får tag på det. Från och med 2021 rekommenderas att du inte använder en giltighetsperiod över ett år. Med tillkomsten av automatiska återutgivningsmekanismer som CertBot kan denna period bli mycket kortare för att ytterligare förbättra säkerheten.
Certifikat kan återkallas om den privata nyckeln läckt ut - och som en försiktighetsåtgärd bör alla säkerhetsöverträdelser som äventyrar hårdvara som innehåller privata nycklar följas av ett certifikatåterkallande och efterföljande utfärdande av nya certifikat.
Certifikat kan utfärdas till olika enheter, såsom FQDN, e-post, till och med IP-adress eller förnamn. Även om det är tekniskt möjligt att ha jokertecken FQDN-certifikat och de föredras ofta av användare, kom ihåg att i händelse av en privat nyckelläckage från en viss tjänst autentiserar jokerteckencertifikatet hela FQDN - som ett resultat av privat nyckel på en webbserver som används för enbart företagspresentation kan lika gärna användas för MITM-attacker mellan Exchange-servern eller CRM-systemet. Att hålla certifikat oberoende för varje underdomän hjälper till att mildra effekten av läckan tills certifikatet återkallas.
Även om det också är möjligt att utfärda certifikat till IP-adress, avskaffas det. Anledningen till detta är att IP-adresserna enkelt kan ändras jämfört med FQDN.
Grundprincipen för certifikat är ganska enkel. I ett exempel vill Alice komma åt Bobs server, men problemet är att hon aldrig var där så att de aldrig kunde utbyta någon gemensam hemlighet för att autentisera. Hur kan Alice vara säker på att hon faktiskt ansluter till Bob? Det är här Charlie spelar in. Alice känner till Charlie och lade till sitt certifikat i rotcertifikatförvaret. Därför anser Alice att Charlie är en pålitlig enhet. Om Bob har sitt eget certifikat och privata nyckel utfärdat av Charlie kan han verifiera Alice och det spelar ingen roll att Alice aldrig varit i kontakt med Bob tidigare, för Bob litar på Charlie, och eftersom Alice litar på Charlie litar hon också på Bob . Detta är något som kallas en Chain of Trust.
Låt oss ta en titt på Chain of Trust för vårt webbcertifikat för Support Campus:
Observera att det också finns en annan enhet som heter R3. Detta kallas Intermediate CA, medan DST Root CA X3 är Root CA. Certifikatet kan bara ha en rot-CA, men det kan finnas fler mellanliggande certifikat. Intermediate CA är en enhet som har fått tillstånd att utfärda certifikat för sina kunder. Så länge din dator har DST Root CA X3-certifikat i listan över betrodda rotcertifikat kommer den att betraktas som support.zyxel.eu.
Självsignerade certifikat
Som standard använder våra brandväggar (och många andra enheter) självsignerade certifikat för att upprätta krypterad TLS-anslutning. Ett sådant certifikat rapporteras av ett välkänt felmeddelande av webbläsaren: 
Det finns två skäl till varför detta händer. Den första anledningen är att certifikatet i grunden är ett root CA-certifikat som inte finns i ditt system. Men att bara installera det som root CA på din dator kommer inte att göra tricket, eftersom certifikatet inte utfärdas för din IP eller domän. Certifikatet är dock lämpligt för en säker anslutning och användningen av det har ingen säkerhetsrisk så länge den privata nyckeln inte läcks ut - det enda problemet här är att identiteten inte kan bekräftas.
Arbeta med certifikat
Under åren har många certifikatformat utvecklats. Certifikaten använder dock fortfarande samma princip och alla format kan konverteras till andra format.
Certifikatformat
Det äldsta formatet skulle vara PEM, som innehåller den ASCII-kodade nyckeln. Anledningen bakom detta är originalanvändning i krypterade e-postmeddelanden, där binärt certifikat kan bli felaktigt. PEM är vanliga i Unix-system och det är troligt att din CA skickade ett certifikat till dig tillsammans med en privat nyckel i PEM-format. Använder vanligtvis filtillägget .pem eller .cer.
DER är en binär form av ASCII PEM-formatcertifikat. Alla typer av certifikat och privata nycklar kan kodas i DER-format. Detta format stöder lagring av ett enda certifikat och inkluderar inte en privat nyckel för mellanliggande / rot-CA. De har förlängning .der eller .cer och används oftast på Java-plattformar.
PKCS # 7 är ett binärt format som gör det möjligt att innehålla certifikat eller hela certifikat Chain of Trust i en enda fil. Ingen privat nyckel kan dock lagras i detta format. Detta format används oftast av behöriga myndigheter för att tillhandahålla en komplett kedja av förtroende. Använder tillägget .p7b.
PKCS # 12, även känt som PFX, är ett format som också kan innehålla hela Chain of Trust och den privata nyckeln. Vanligtvis tillhandahålls detta format av CA: er, eftersom det kan säkras med ett lösenord. Använder vanligtvis .p12 eller .pfx förlängning.
Certifikatverktyg
Windows har ett inbyggt system CLI-verktyg certutil som kan användas för att konvertera certifikat. Management-plugins i Microsoft Management Console tillåter också hantering av certifikat.
Open source-verktyget OpenSSL kan också hantera och konvertera certifikat. Binärer finns för Windows, Linux och macOS (och många andra plattformar)
Användbara certutil-kommandon:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Användbara OpenSSL-kommandon:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importerar certifikat i USG / ATP-brandväggar
Den nuvarande utformningen (från juni 2021) är begränsad till import av certifikat utan mellanliggande nycklar. Om certifikatet innehåller en mellanliggande nyckel, analyseras filen felaktigt och försöket att använda ett sådant certifikat kan leda till att tjänsten är otillgänglig (t.ex. WebGUI). Det är en bra idé att få certifikatet i .pem-format och exportera det till .pfx-format med antingen certutil eller OpenSSL. Certifikatet kan importeras tillsammans med lösenordet i följande meny:
Configuration > Objects > Certificates > My Certificates
Certifikatsäkerhet
Varje certifikat har sin respektive privata nyckel. Medan ett certifikat är offentlig information måste den privata nyckeln hanteras som en hemlighet - och den ska inte delas av någon. Inte ens hos oss på Zyxel - det enda giltiga sättet är att använda verktyg för fjärrhjälp som TeamViewer. När du lagrar den privata nyckeln i pem-format, dubbelkolla behörigheterna för att komma åt den privata nyckeln för att förhindra att den läcker ut. Använd alltid lösenordskryptering i pfx-format för att ge åtminstone en viss säkerhet vid export av certifikat. Alla certifikat med den läckta privata nyckeln bör återkallas omedelbart.
VARNING:
Kära kund, tänk på att vi använder maskinöversättning för att tillhandahålla artiklar på ditt lokala språk. Det är inte säkert att all text översätts korrekt. Om det finns frågor eller avvikelser om informationens noggrannhet i den översatta versionen, läs igenom originalartikeln här: Originalversion