Denne artikkelen vil forklare hvordan du bruker sertifikater utstedt av en tredjeparts sertifiseringsmyndighet (CA), for eksempel Let's Encrypt, Comodo, Symantec, Digicert osv. Den vil også dekke hvordan sertifikater fungerer generelt.
Synopsis
Sertifikatene tjener to hovedformål: Å kryptere kommunikasjon mellom to enheter og å bekrefte enhetens ekthet. Førstnevnte kan tildeles av et såkalt selvsignert sertifikat, men for å godkjenne enheten trenger du et globalt klarert sertifikat utstedt av root eller mellomliggende CA. Denne artikkelen vil forklare hvordan sertifikater generelt oppnår denne autentiseringen, hvordan du endrer sertifikatformatet for å fungere med andre enheter, inkludert brannmurer, hvordan du importerer sertifikatet til brannmuren og hvordan sertifikater skal håndteres for å unngå sikkerhetsrisiko.
Innholdsfortegnelse
- Hvordan fungerer et sertifikat?
- Selvsignerte sertifikater
- Arbeider med sertifikater
- Importerer sertifikater i USG / ATP-brannmurer
- Sertifikat sikkerhet
Hvordan fungerer et sertifikat?
Hvert sertifikat består av to deler: Sertifikatet (også kalt den offentlige nøkkelen) og den private nøkkelen. Sertifikatet kan deles offentlig og inneholder bare informasjon om formålet sertifikatet ble utstedt for og til hvilken enhet sertifikatet ble utstedt - dette kan være din FQDN, e-postadresse eller annen verdi.
Sertifikater har en begrenset gyldighetsperiode - dette hjelper i situasjoner der noe gammelt sertifikat med en privat nøkkel blir gravd opp et sted etter flere tiår. Hvis gyldigheten var uendelig, kunne sertifikatet fortsatt brukes til ondsinnede formål av alle som får tak i det. Fra og med 2021 anbefales det å ikke bruke en gyldighetsperiode over ett år. Med ankomsten av automatiske gjenutstedelsesmekanismer som CertBot, kan denne perioden bli mye kortere for ytterligere å forbedre sikkerheten.
Sertifikater kan tilbakekalles i tilfelle den private nøkkelen ble lekket - og som en forholdsregel, bør sikkerhetsbrudd som kompromitterte maskinvare som inneholder private nøkler følges av et sertifikat tilbakekalling og påfølgende utstedelse av nye sertifikater.
Sertifikater kan utstedes til forskjellige enheter, for eksempel FQDN, e-post, til og med IP-adresse eller fornavn. Selv om det er teknisk mulig å ha wildcard FQDN-sertifikater, og de ofte foretrekkes av brukere, må du huske at i tilfelle en privat nøkkellekkasje fra en bestemt tjeneste, autentiserer jokertegnesertifikatet hele FQDN - som et resultat av en lekkasje av privat nøkkel på en webserver som bare brukes til firmapresentasjon, kan like godt brukes til MITM-angrep mellom Exchange-server eller CRM-system. Å holde sertifikater uavhengige for hvert underdomener bidrar til å redusere effekten av lekkasjen til sertifikatet blir tilbakekalt.
Selv om det også er mulig å utstede sertifikater til IP-adresse, avvikles det. Årsaken bak dette er at IP-ene enkelt kan endres sammenlignet med FQDN.
Det grunnleggende prinsippet om sertifikater er ganske enkelt. I et eksempel ønsker Alice å få tilgang til Bobs server, men problemet er at hun aldri var der, så de kunne aldri utveksle en felles hemmelighet for å autentisere. Hvordan kan Alice være sikker på at hun faktisk kobler seg til Bob? Det er her Charlie spiller inn. Alice kjenner Charlie og la til sertifikatet sitt i rotsertifikatlageret. Derfor anser Alice Charlie som en pålitelig enhet. Hvis Bob har sitt eget sertifikat og private nøkkel utstedt av Charlie, kan han godkjenne overfor Alice, og det spiller ingen rolle at Alice aldri var i kontakt med Bob før, fordi Bob er klarert av Charlie, og siden Alice stoler på Charlie, stoler hun på Bob også . Dette er noe som kalles en Chain of Trust.
La oss ta en titt på Chain of Trust for vårt web-sertifikat for Support Campus:
Legg merke til at det også er en annen enhet kalt R3. Dette kalles Intermediate CA, mens DST Root CA X3 er Root CA. Sertifikatet kan bare ha én rot-CA, men det kan være flere mellomliggende CA-er. Intermediate CA er en enhet som har fått tillatelse til å utstede sertifikater til sine kunder. Så lenge PC-en din har DST Root CA X3-sertifikat i listen over pålitelige rotsertifikater, vil den vurdere support.zyxel.eu klarert.
Selvsignerte sertifikater
Som standard bruker brannmurer (og mange andre enheter) selvsignerte sertifikater for å etablere kryptert TLS-forbindelse. Slike sertifikater rapporteres av en velkjent feilmelding fra nettleseren: 
Det er to grunner til at dette skjer. Den første grunnen er at sertifikatet i utgangspunktet er et rot-CA-sertifikat som ikke er tilstede i systemet ditt. Men bare å installere den som root CA på datamaskinen din, vil ikke gjøre det, fordi sertifikatet ikke er utstedt for IP eller domene. Sertifikatet er imidlertid egnet for en sikker tilkobling, og bruk av det har ingen sikkerhetsrisiko så lenge den private nøkkelen ikke lekker. Det eneste problemet her er at identiteten ikke kan bekreftes.
Arbeider med sertifikater
Gjennom årene ble det utviklet mange sertifikatformater. Sertifikatene bruker imidlertid fortsatt det samme prinsippet, og alle formater kan konverteres til andre formater.
Sertifikatformater
Det eldste formatet ville være PEM, som inneholder den ASCII-kodede nøkkelen. Årsaken bak dette er original bruk i krypterte e-poster, der binært sertifikat kan bli misdannet. PEM-er er vanlige i Unix-systemer, og det er sannsynlig at CA har sendt deg et sertifikat sammen med en privat nøkkel i PEM-format. Bruker vanligvis .pem eller .cer filtypen.
DER er en binær form for ASCII PEM-format sertifikat. Alle typer sertifikater og private nøkler kan kodes i DER-format. Dette formatet støtter lagring av et enkelt sertifikat og inkluderer ikke en privat nøkkel for mellomliggende / rot-CA. De har utvidelse .der eller .cer og brukes oftest på Java-plattformer.
PKCS # 7 er et binært format som gjør det mulig å inneholde sertifikater eller hele sertifikatet Chain of Trust i en enkelt fil. Imidlertid kan ingen privat nøkkel lagres i dette formatet. Dette formatet brukes oftest av CAer for å gi en komplett Chain of Trust. Bruker utvidelse .p7b.
PKCS # 12, også kjent som PFX, er et format som også kan inneholde hele Chain of Trust og den private nøkkelen. Vanligvis er dette formatet levert av CA, da det kan sikres med et passord. Bruker ofte .p12- eller .pfx-utvidelse.
Sertifikatverktøy
Windows har et innebygd CLI-verktøy certutil som kan brukes til å konvertere sertifikater. Administrasjonsprogrammer i Microsoft Management Console tillater også administrasjon av sertifikater.
Open source-verktøyet kalt OpenSSL er også i stand til å håndtere og konvertere sertifikater. Binære filer er tilgjengelige for Windows, Linux og macOS (og mange andre plattformer)
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 sertifikat i USG / ATP-brannmurer
Den nåværende utformingen (fra juni 2021) er begrenset til import av sertifikater uten mellomnøkler. Hvis sertifikatet inneholder en mellomnøkkel, blir filen analysert feil, og forsøket på å bruke et slikt sertifikat kan føre til utilgjengelighet av tjenesten (for eksempel WebGUI). Det er lurt å få sertifikatet i .pem-format og eksportere det til .pfx-format ved hjelp av enten certutil eller OpenSSL. Sertifikatet kan importeres, sammen med passordet i følgende meny:
Configuration > Objects > Certificates > My Certificates
Sertifikat sikkerhet
Hvert sertifikat har sin respektive private nøkkel. Mens et sertifikat er offentlig informasjon, må den private nøkkelen håndteres som en hemmelighet - og skal ikke deles av noen. Ikke engang hos oss på Zyxel - den eneste gyldige måten er å bruke verktøy for fjernhjelp som TeamViewer. Når du lagrer den private nøkkelen i pem-format, må du dobbeltsjekke tillatelsene for å få tilgang til den private nøkkelen for å forhindre lekkasje. Bruk alltid passordkryptering i pfx-format for å gi minst en viss sikkerhet når du eksporterer sertifikater. Eventuelle sertifikater med den lekte private nøkkelen skal tilbakekalles umiddelbart.
FRASKRIVELSE:
Kjære kunde, vær oppmerksom på at vi bruker maskinoversettelse til å levere artikler på ditt lokale språk. Ikke all tekst kan oversettes nøyaktig. Hvis det er spørsmål eller avvik med hensyn til nøyaktigheten av informasjonen i den oversatte versjonen, kan du lese originalartikkelen her: Originalversjon