Denne artikel vil forklare, hvordan man bruger certifikater udstedt af en tredjeparts certificeringsmyndighed (CA), såsom Let's Encrypt, Comodo, Symantec, Digicert osv. Den vil også dække, hvordan certifikater generelt fungerer.
Synopsis
Certifikaterne tjener to hovedformål: At kryptere kommunikation mellem to enheder og at bekræfte enhedens ægthed. Førstnævnte kan tildeles med et såkaldt selvsigneret certifikat, men for at godkende enheden har du brug for et globalt betroet certifikat udstedt af root eller mellemliggende CA. Denne artikel vil forklare, hvordan certifikater generelt opnår denne godkendelse, hvordan man ændrer certifikatets format, så det fungerer sammen med andre enheder, herunder vores firewalls, hvordan man importerer certifikatet til din firewall, og hvordan certifikater skal håndteres for at undgå sikkerhedsrisici.
Indholdsfortegnelse
- Hvordan fungerer et certifikat?
- Selvsignerede certifikater
- Arbejde med certifikater
- Import af certifikater i USG / ATP firewalls
- Certifikatsikkerhed
Hvordan fungerer et certifikat?
Hvert certifikat består af to dele: Certifikatet (også kaldet den offentlige nøgle) og den private nøgle. Certifikatet kan deles offentligt og indeholder kun information om det formål, hvortil certifikatet blev udstedt, og til hvilken enhed certifikatet blev udstedt - dette kan være din FQDN, e-mail-adresse eller anden værdi.
Certifikater har en begrænset gyldighedsperiode - dette hjælper med situationer, hvor et gammelt certifikat med en privat nøgle graves op et sted efter årtier. Hvis gyldigheden var uendelig, kunne certifikatet stadig bruges til ondsindede formål af alle, der får fat i det. Fra 2021 anbefales det ikke at bruge en gyldighedsperiode over et år. Med fremkomsten af automatiske genudstedelsesmekanismer som CertBot kan denne periode blive meget kortere for yderligere at forbedre sikkerheden.
Certifikater kan tilbagekaldes, hvis den private nøgle var lækket - og af sikkerhedshensyn bør ethvert sikkerhedsbrud, der kompromitteret hardware indeholdende private nøgler, efterfølges af en tilbagekaldelse af certifikat og efterfølgende genudstedelse af nye certifikater.
Certifikater kan udstedes til forskellige enheder, såsom FQDN, e-mail, endda IP-adresse eller fornavn. Selvom det er teknisk muligt at have wildcard FQDN-certifikater, og de ofte foretrækkes af brugerne, skal du huske på, at i tilfælde af en privat nøglelækage fra en bestemt tjeneste godkender wildcard-certifikatet hele FQDN - som et resultat en lækage af privat nøgle på en webserver, der bruges til simpel præsentation af virksomheden, kan lige så godt bruges til MITM-angreb mellem Exchange-server eller CRM-system. At holde certifikater uafhængige for hvert underdomæne hjælper med at mindske virkningen af lækagen, indtil certifikatet tilbagekaldes.
Mens det også er muligt at udstede certifikater til IP-adresse, udfases det. Årsagen bag dette er, at IP'erne let kan ændres sammenlignet med FQDN.
Det grundlæggende princip for certifikater er ret simpelt. I et eksempel ønsker Alice at få adgang til Bobs server, men problemet er, at hun aldrig var der, så de kunne aldrig udveksle en fælles hemmelighed for at godkende. Hvordan kan Alice være sikker på, at hun faktisk opretter forbindelse til Bob? Det er her Charlie spiller ind. Alice kender Charlie og tilføjede sit certifikat til rodcertifikatlageret. Derfor betragter Alice Charlie som en betroet enhed. Hvis Bob har sit eget certifikat og private nøgle udstedt af Charlie, kan han godkende overfor Alice, og det betyder ikke noget, at Alice aldrig har været i kontakt med Bob før, fordi Bob er tillid til af Charlie, og da Alice stoler på Charlie, stoler hun også på Bob . Dette kaldes en Chain of Trust.
Lad os tage et kig på Chain of Trust for vores Support Campus webcertifikat:
Bemærk, at der også er en anden enhed, der hedder R3. Dette kaldes Intermediate CA, mens DST Root CA X3 er Root CA. Certifikatet kan kun have en rod-CA, men der kan være flere mellemliggende CA'er. Intermediate CA er en enhed, der har fået tilladelse til at udstede certifikater til sine kunder. Så længe din pc har DST Root CA X3-certifikat på listen over pålidelige rodcertifikater, vil den betragte support.zyxel.eu pålidelig.
Selvsignerede certifikater
Som standard bruger vores firewalls (og mange andre enheder) selvsignerede certifikater til at etablere krypteret TLS-forbindelse. Et sådant certifikat rapporteres af en velkendt fejlmeddelelse fra browseren: 
Der er to grunde til, at dette sker. Den første årsag er, at certifikatet grundlæggende er et rod-CA-certifikat, der ikke findes i dit system. Men det er simpelthen ikke at installere det som root CA på din computer, fordi certifikatet ikke udstedes til din IP eller dit domæne. Certifikatet er dog egnet til en sikker forbindelse, og brug af det har ingen sikkerhedsrisiko, så længe dets private nøgle ikke lækkes - det eneste problem her er, at identiteten ikke kan bekræftes.
Arbejde med certifikater
I årenes løb blev der udviklet mange certifikatformater. Certifikaterne bruger dog stadig det samme princip, og alle formater kan konverteres til andre formater.
Certifikatformater
Det ældste format ville være PEM, som indeholder den ASCII-kodede nøgle. Årsagen bag dette er original brug i krypterede mails, hvor binært certifikat kan blive forkert. PEM'er er almindelige i Unix-systemer, og det er sandsynligt, at din CA har sendt dig et certifikat sammen med en privat nøgle i PEM-format. Bruger normalt .pem eller .cer filtypenavn.
DER er en binær form af ASCII PEM-formatcertifikat. Alle typer certifikater og private nøgler kan kodes i DER-format. Dette format understøtter lagring af et enkelt certifikat og inkluderer ikke en privat nøgle til den mellemliggende / rod-CA. De har udvidelse .der eller .cer og bruges oftest på Java-platforme.
PKCS # 7 er et binært format, der tillader at indeholde certifikater eller hele certifikat Chain of Trust i en enkelt fil. Ingen privat nøgle kan dog gemmes i dette format. Dette format bruges oftest af CA'er til at give en komplet Chain of Trust. Bruger udvidelse .p7b.
PKCS # 12, også kendt som PFX, er et format, der også kan indeholde hele Chain of Trust og den private nøgle. Normalt leveres dette format af CA'er, da det kan sikres med en adgangskode. Bruger ofte .p12 eller .pfx udvidelse.
Certifikatværktøjer
Windows har et indbygget system CLI utility certutil, der kan bruges til at konvertere certifikater. Management-plugins i Microsoft Management Console tillader også styring af certifikater.
Open source-værktøjet kaldet OpenSSL er også i stand til at håndtere og konvertere certifikater. Binære filer er tilgængelige til Windows, Linux og macOS (og mange andre platforme)
Nyttige certutil kommandoer:
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.
Nyttige OpenSSL-kommandoer:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importerer certifikat i USG / ATP firewalls
Det nuværende design (fra juni 2021) er begrænset til import af certifikater uden mellemliggende nøgler. Hvis certifikatet indeholder en mellemliggende nøgle, parses filen forkert, og forsøget på at bruge et sådant certifikat kan resultere i utilgængelighed af tjenester (såsom WebGUI). Det er en god ide at få certifikatet i .pem-format og eksportere det til .pfx-format ved hjælp af enten certutil eller OpenSSL. Certifikatet kan importeres sammen med adgangskoden i følgende menu:
Configuration > Objects > Certificates > My Certificates
Certifikatsikkerhed
Hvert certifikat har sin respektive private nøgle. Mens et certifikat er offentlig information, skal den private nøgle håndteres som en hemmelighed - og den bør ikke deles af nogen. Ikke engang hos os på Zyxel - den eneste gyldige måde er at bruge fjernhjælpeværktøjer som TeamViewer. Når du gemmer den private nøgle i pem-format, skal du dobbelttjekke tilladelserne til at få adgang til den private nøgle for at forhindre, at den lækker. Brug altid adgangskodekryptering i pfx-format for at give mindst en vis grad af sikkerhed ved eksport af certifikater. Eventuelle certifikater med den lækkede private nøgle skal straks tilbagekaldes.
ANSVARSFRASKRIVELSE:
Kære kunde, vær opmærksom på, at vi bruger maskinoversættelse til at levere artikler på dit lokale sprog. Ikke alle tekster oversættes muligvis nøjagtigt. Hvis der er spørgsmål eller uoverensstemmelser om nøjagtigheden af oplysningerne i den oversatte version, bedes du læse den originale artikel her: Originalversion