In dit artikel wordt uitgelegd hoe u certificaten gebruikt die zijn uitgegeven door een externe certificeringsinstantie (CA), zoals Let's Encrypt, Comodo, Symantec, Digicert enz. Het behandelt ook hoe certificaten in het algemeen werken.
Korte inhoud
De certificaten hebben twee hoofddoelen: de communicatie tussen twee entiteiten versleutelen en de authenticiteit van de entiteit bevestigen. De eerste kan worden verleend door een zogenaamd zelfondertekend certificaat, maar om de entiteit te authenticeren, hebt u een wereldwijd vertrouwd certificaat nodig dat is uitgegeven door een root- of intermediaire CA. In dit artikel wordt uitgelegd hoe certificaten deze authenticatie in het algemeen bereiken, hoe u de indeling van het certificaat kunt wijzigen om met andere apparaten te werken, inclusief onze firewalls, hoe u het certificaat in uw firewall kunt importeren en hoe certificaten moeten worden behandeld om beveiligingsrisico's te voorkomen.
Inhoudsopgave
- Hoe werkt een certificaat?
- Zelfondertekende certificaten
- Werken met certificaten
- Certificaten importeren in USG/ATP-firewalls
- Certificaatbeveiliging
Hoe werkt een certificaat?
Elk certificaat bestaat uit twee delen: het certificaat (ook wel de publieke sleutel genoemd) en de private sleutel. Het certificaat kan openbaar worden gedeeld en bevat alleen informatie over de doeleinden waarvoor het certificaat is uitgegeven en aan welke entiteit het certificaat is uitgegeven - dit kan uw FQDN, e-mailadres of andere waarde zijn.
Certificaten hebben een beperkte geldigheidsduur - dit helpt bij situaties waarin een oud certificaat met een privésleutel na tientallen jaren ergens wordt opgegraven. Als de geldigheid oneindig was, zou het certificaat nog steeds voor kwaadaardige doeleinden kunnen worden gebruikt door iedereen die het in handen krijgt. Vanaf 2021 wordt aangeraden geen geldigheidsduur van meer dan een jaar te hanteren. Met de komst van automatische heruitgiftemechanismen zoals CertBot, kan deze periode veel korter worden om de beveiliging verder te verbeteren.
Certificaten kunnen worden ingetrokken in het geval dat de privésleutel is gelekt - en uit voorzorg moet elke inbreuk op de beveiliging waarbij hardware met privésleutels is gecompromitteerd, worden gevolgd door een intrekking van het certificaat en daaropvolgende heruitgifte van nieuwe certificaten.
Certificaten kunnen worden uitgegeven aan verschillende entiteiten, zoals FQDN, e-mail, zelfs IP-adres of voornaam. Hoewel het technisch mogelijk is om FQDN-certificaten met jokertekens te gebruiken en gebruikers geven daar vaak de voorkeur aan, moet u er rekening mee houden dat in het geval van een lek van een privésleutel van een specifieke service, het jokertekencertificaat de hele FQDN verifieert. privésleutel op een webserver die alleen voor bedrijfspresentatie wordt gebruikt, kan net zo goed worden gebruikt voor MITM-aanvallen tussen Exchange-server of CRM-systeem. Door certificaten voor elk subdomein onafhankelijk te houden, wordt de impact van het lek beperkt totdat het certificaat wordt ingetrokken.
Hoewel het ook mogelijk is om certificaten uit te geven naar een IP-adres, wordt dit afgeraden. De reden hierachter is dat de IP's gemakkelijk kunnen worden gewijzigd in vergelijking met FQDN.
Het basisprincipe van certificaten is vrij eenvoudig. Alice wil bijvoorbeeld toegang tot de server van Bob, maar het probleem is dat ze daar nooit was, dus ze konden nooit een gemeenschappelijk geheim uitwisselen om zich te authenticeren. Hoe kan Alice er zeker van zijn dat ze daadwerkelijk contact maakt met Bob? Dit is waar Charlie in het spel komt. Alice kent Charlie en heeft zijn certificaat toegevoegd aan de opslagplaats voor basiscertificaten. Daarom beschouwt Alice Charlie als een vertrouwde entiteit. Als Bob zijn eigen certificaat en privésleutel heeft die zijn uitgegeven door Charlie, kan hij zich authenticeren bij Alice en het maakt niet uit dat Alice nooit eerder contact met Bob heeft gehad, want Bob wordt vertrouwd door Charlie, en aangezien Alice Charlie vertrouwt, vertrouwt zij Bob ook . Dit wordt een Chain of Trust genoemd.
Laten we eens kijken naar de Chain of Trust voor ons Support Campus-webcertificaat:
Merk op dat er ook een andere entiteit is die R3 wordt genoemd. Dit wordt Intermediate CA genoemd, terwijl DST Root CA X3 Root CA is. Certificaat kan slechts één root-CA hebben, maar er kunnen meer tussen-CA's zijn. Intermediate CA is een entiteit die toestemming heeft gekregen om certificaten uit te geven voor haar klanten. Zolang uw pc het DST Root CA X3-certificaat in de lijst met vertrouwde rootcertificaten heeft, wordt support.zyxel.eu als vertrouwd beschouwd.
Zelfondertekende certificaten
Standaard gebruiken onze firewalls (en vele andere apparaten) zelfondertekende certificaten om een versleutelde TLS-verbinding tot stand te brengen. Een dergelijk certificaat wordt gerapporteerd door een bekende foutmelding door de browser: 
Er zijn twee redenen waarom dit gebeurt. De eerste reden is dat het certificaat in feite een root-CA-certificaat is dat niet in uw systeem aanwezig is. Maar het simpelweg installeren als root-CA op uw computer is niet voldoende, omdat het certificaat niet wordt uitgegeven voor uw IP of domein. Het certificaat is echter geschikt voor een beveiligde verbinding en het gebruik ervan brengt geen veiligheidsrisico met zich mee zolang de private sleutel niet gelekt wordt - het enige probleem hierbij is dat de identiteit niet kan worden bevestigd.
Werken met certificaten
In de loop der jaren zijn er veel certificaatformaten ontwikkeld. De certificaten hanteren echter nog steeds hetzelfde principe en alle formaten kunnen worden omgezet naar andere formaten.
Certificaatformaten
Het oudste formaat is de PEM, die de ASCII-gecodeerde sleutel bevat. De reden hierachter is het oorspronkelijke gebruik in gecodeerde e-mails, waarbij het binaire certificaat misvormd kan raken. PEM's komen veel voor in Unix-systemen en het is waarschijnlijk dat uw CA u een certificaat heeft gestuurd samen met een persoonlijke sleutel in PEM-indeling. Gebruikt meestal de bestandsextensie .pem of .cer.
DER is een binaire vorm van ASCII PEM-formaat certificaat. Alle soorten certificaten en privésleutels kunnen worden gecodeerd in DER-indeling. Deze indeling ondersteunt de opslag van één certificaat en bevat geen privésleutel voor de tussenliggende/root-CA. Ze hebben de extensie .der of .cer en worden het meest gebruikt op Java-platforms.
PKCS#7 is een binair formaat waarmee certificaten of de volledige certificaatketen van vertrouwen in een enkel bestand kunnen worden opgeslagen. Er kan echter geen privésleutel in dit formaat worden opgeslagen. Dit formaat wordt het meest gebruikt door CA's om een volledige vertrouwensketen te bieden. Gebruikt extensie .p7b.
PKCS#12, ook wel PFX genoemd, is een formaat dat ook de hele Chain of Trust en privésleutel kan bevatten. Meestal wordt dit formaat geleverd door CA's, omdat het kan worden beveiligd met een wachtwoord. Gebruikt gewoonlijk de extensie .p12 of .pfx.
Certificaattools
Windows heeft een ingebouwd systeem CLI-hulpprogramma certutil dat kan worden gebruikt om certificaten te converteren. Beheerplug-ins in Microsoft Management Console maken ook het beheer van certificaten mogelijk.
Het open-source hulpprogramma OpenSSL kan ook certificaten verwerken en converteren. Binaries zijn beschikbaar voor Windows, Linux en macOS (en vele andere platforms)
Handige certutil-opdrachten:
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.
Handige OpenSSL-opdrachten:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Certificaat importeren in USG/ATP-firewalls
Het huidige ontwerp (vanaf juni 2021) is beperkt tot het importeren van certificaten zonder tussensleutels. Als het certificaat een tussensleutel bevat, wordt het bestand onjuist geparseerd en kan de poging om een dergelijk certificaat te gebruiken ertoe leiden dat de service niet beschikbaar is (zoals WebGUI). Het is een goed idee om het certificaat in .pem-indeling te krijgen en te exporteren naar .pfx-indeling met behulp van certutil of OpenSSL. Het certificaat kan samen met het wachtwoord worden geïmporteerd in het volgende menu:
Configuration > Objects > Certificates > My Certificates
Certificaatbeveiliging
Elk certificaat heeft zijn respectieve privésleutel. Hoewel een certificaat openbare informatie is, moet de privésleutel als geheim worden behandeld - en mag deze door niemand worden gedeeld. Zelfs niet bij ons bij Zyxel - de enige geldige manier is om hulpmiddelen voor hulp op afstand zoals TeamViewer te gebruiken. Wanneer u de privésleutel in pem-indeling opslaat, controleer dan nogmaals de machtigingen voor toegang tot de privésleutel om lekkage te voorkomen. Gebruik altijd wachtwoordversleuteling in pfx-formaat om op zijn minst enige mate van beveiliging te bieden bij het exporteren van certificaten. Alle certificaten met de gelekte privésleutel moeten onmiddellijk worden ingetrokken.
DISCLAIMER:
Geachte klant, houd er rekening mee dat we machinevertaling gebruiken om artikelen in uw lokale taal aan te bieden. Niet alle tekst is mogelijk nauwkeurig vertaald. Als er vragen of discrepanties zijn over de juistheid van de informatie in de vertaalde versie, lees dan het originele artikel hier: Originele versie