Ömsesidigt TLS (mTLS) autentisering skapar ett säkert ramverk för autentisering av både användare och IoT-enheter. Den här guiden hjälper dig att implementera mTLS för att säkerställa säker dubbelriktad autentisering mellan klienter och servrar.
Snabbstart Guide
Inrätta ömsesidigt TLS följer en enkel process. Generera först de nödvändiga server- och klientcertifikaten. Konfigurera sedan din server för att kräva klientcertifikat. Ställ sedan in dina klienter med sina certifikat och implementera korrekt certifikatvalidering. Testa slutligen anslutningen för att säkerställa att allt fungerar som förväntat.
Envägs och ömsesidig SSL /TLS Autentisering
En av de definierande funktionerna i SSL /TLS protokollet är dess roll för att autentisera annars anonyma parter i datanätverk (t.ex. internet). När du besöker en webbplats med en offentligt betrodd SSL /TLS certifikatkan din webbläsare verifiera att webbplatsägaren framgångsrikt har visat kontroll över domännamnet till en betrodd certifikatutfärdare från tredje part (CA), till exempel SSL.com. Om den här verifieringen misslyckas varnar webbläsaren dig för att inte lita på den webbplatsen. För de flesta applikationer, SSL /TLS använder den här typen av enkelriktad autentisering av en server till en klient; en anonym klient (webbläsaren) förhandlar om en krypterad session med en webbserver, som presenterar en offentligt pålitlig SSL /TLS certifikat för att identifiera sig under SSL /TLS handskakning:
Ömsesidig autentisering, där båda servern och klient i SSL /TLS session är autentiserad, är också möjlig och kan vara mycket användbar under vissa omständigheter. I ömsesidig autentisering skickas en när servern har autentiserats under handskakningen CertificateRequest meddelande till klienten. Klienten svarar genom att skicka ett certifikat till servern för autentisering:
Klientautentisering via ömsesidig TLS kräver att ett certifikat inklusive Client Authentication (1.3.6.1.5.5.7.3.2) Utökad nyckelanvändning (EKU) är installerad på klientenheten. Alla SSL.coms E-post-, klient- och dokumentsigneringscertifikat inkluderar klientautentisering.
Detaljerad implementeringsguide
Förstå ömsesidigt TLS
Traditionell TLS ger serverautentisering och kryptering, men ömsesidigt TLS går längre genom att kräva att båda parter presenterar digitala certifikat. Denna tvåvägsverifiering säkerställer serveräkthet, möjliggör klientautentisering, etablerar en krypterad kommunikationskanal och förhindrar man-i-mitten-attacker. Resultatet är en mycket säker anslutning lämplig för känsliga applikationer och IoT-enhetskommunikation.
Förutsättningar
Innan du påbörjar implementeringen, se till att du har tillgång till OpenSSL eller ett liknande certifikathanteringsverktyg. Din webbserver måste stödja TLS, och du behöver antingen tillgång till en Certifikatmyndighet (CA) eller möjligheten att skapa en privat CA. Dina klienter måste också stödja certifikatbaserad autentisering.
Steg 1: Certifikatgenerering och hantering
Börja med att skapa de nödvändiga certifikaten för både server- och klientautentisering. Servercertifikatinställningen kräver att en privat nyckel skapas, genererar en begäran om certifikatsigneringoch signera certifikatet med din CA.
# Generera serverns privata nyckel
openssl genrsa -ut server.nyckel 2048
?
# Skapa servercertifikatsigneringsbegäran (CSR)
openssl req -ny -nyckel server.nyckel -ut server.csr
?
# Signera servercertifikatet med din CA
openssl x509 -req -i server.csr -CA ca.crt -CAkey ca.nyckel -CAcreateserial -ut server.crt
För klientcertifikat, följ en liknande process för att skapa sina unika referenser:
# Generera klientens privata nyckel
openssl genrsa -ut klient.nyckel 2048
?
# Skapa klient CSR
openssl req -ny -nyckel klient.nyckel -ut client.csr
?
# Signera klientcertifikatet
openssl x509 -req -i client.csr -CA ca.crt -CAkey ca.nyckel -CAcreateserial -ut client.crt
Steg 2: Serverkonfiguration
Servern måste konfigureras för att kräva och validera klientcertifikat. Här är ett exempel på en konfiguration för Nginx:
server {
lyssna 443 ssl;
servernamn exempel.com;
?
ssl_certificate /sökväg/till/server.crt;
ssl_certifikatnyckel /sökväg/till/server.nyckel;
ssl_client_certificate /sökväg/till/ca.crt;
ssl_verify_client på;
ssl_protokoll TLSv1.2 TLSv1.3;
ssl_ciphers HÖG:!aNULL:!MD5;
ssl_prefer_server_ciphers på;
}
För Apache-servrar, använd denna konfiguration:
<VirtualHost *:443>
Server namn example.com
SSLengine on
SSLCertificateFile /sökväg/till/server.crt
SSLCertificateKeyFile /sökväg/till/server.nyckel
SSLCACertificateFile /sökväg/till/ca.crt
SSLVerifyClient kräver
SSLVerifyDepth 1
Steg 3: Klientimplementering
Webbläsarbaserad autentisering kräver import av klientcertifikatet till din webbläsares certifikatlager. Varje webbläsare hanterar denna process på olika sätt, men i allmänhet hittar du alternativet i säkerhets- eller sekretessinställningarna.
För IoT-enheter måste du implementera certifikatbaserad autentisering i din kod. Här är ett exempel som använder Pythons begärandebibliotek:
importera förfrågningar
?
client_cert = ('client.crt', 'client.key')
ca_cert = 'ca.crt'
?
respons = förfrågningar.skaffa sig('https://example.com',
cert=client_cert,
verifiera=ca_cert)
Steg 4: Certifikatvalidering
Korrekt certifikatvalidering är avgörande för säkerheten. Din implementering bör verifiera certifikatkedjans integritet, kontrollera utgångsdatum, validera återkallelsestatus och säkerställa korrekt nyckelanvändning. Här är ett exempel på implementering:
från kryptografi importera x509
från kryptografi.hazmat.backends importera default_backend
?
def validate_certificate(cert_path):
med öppet(cert_path, 'rb') as cert_file:
cert_data = cert_file.läsa()
cert = x509.load_pem_x509_certificate(cert_data, default_backend())
if cert.inte_giltigt_efter < datum Tid.datum Tid.nu():
höja ValueError("Certifikatet har gått ut")
prova:
key_usage = cert.förlängningar.get_extension_for_class(x509.Nyckelanvändning)
if inte key_usage.värde.digital_signatur:
höja ValueError("Certifikatet är inte giltigt för digital signatur")
utom x509.förlängningar.ExtensionNotFound:
höja ValueError("Obligatoriskt tillägg för nyckelanvändning hittades inte")
Användningsfall för ömsesidig autentisering
Ömsesidigt TLS autentisering kan användas både för att autentisera slutanvändare och för ömsesidig autentisering av enheter i ett datanätverk.Användarautentisering
Företag och andra organisationer kan distribuera digitala klientcertifikat till slutanvändare som anställda, entreprenörer och kunder. Dessa klientcertifikat kan användas som en autentiseringsfaktor för åtkomst till företagsresurser som Wi-Fi, VPN och webbapplikationer. När det används istället för (eller utöver) traditionella användarnamn / lösenordsuppgifter, ömsesidigt TLS erbjuder flera säkerhetsfördelar:- Ömsesidigt TLS autentisering är inte sårbar för referensstöld via taktik som Nätfiske. Verizons Utredningsrapport för dataintrång 2020 indikerar att nästan en fjärdedel (22%) av dataintrång beror på nätfiske. Nätfiske-kampanjer är ute för att få ut mer information som webbplatsinloggningslösenord, inte de privata nycklarna till användarnas klientcertifikat. Som ett ytterligare försvar mot nätfiske, alla SSL.com: s E-post-, klient- och dokumentsignering certifikat inkluderar offentligt betrodda S/MIME för signerad och krypterad e-post.
- Ömsesidigt TLS autentisering kan inte äventyras av dålig lösenordshygien eller brute force attacker på lösenord. Du kan kräva att användare skapar starka lösenord, men hur vet du att de inte använder samma "säkra" lösenord på 50 olika webbplatser, eller har det skrivits på en fästis? A 2019 Google-undersökning indikerar att 52% av användarna återanvänder lösenord för flera konton och 13% av användarna återanvänder samma lösenord för alla av deras konton.
- Kundcertifikat erbjuder en tydlig förtroendekedjaoch kan hanteras centralt. Med ömsesidig TLS, verifiering av vilken certifikatutfärdare (CA) som utfärdat en användares referenser bakas direkt in i autentiseringsprocessen. SSL.com: s verktyg för onlinehantering, SWS API, och tillgång till standardprotokoll som SCEP gör utfärdande, förnyelse och återkallande av dessa referenser till ett ögonblick!
- Individer eller organisationer som bara behöver ett eller några certifikat kan beställa E-post-, klient- och dokumentsigneringscertifikat á la carte från SSL.com.
- Protokoll som SCEP, EST och CMP kan användas för att automatisera registrering och förnyelse av klientcertifikat för företagsägda enheter och BYO-enheter.
- För kunder som behöver en stor mängd certifikat finns grossistrabatter tillgängliga via våra Återförsäljar- och volymköpsprogram.
Säkerhet bästa praxis
Stark säkerhet kräver mer än att bara implementera mTLS:
- Implementera automatisk certifikatrotation för att säkerställa att certifikaten uppdateras regelbundet
- Underhåll en lista över återkallade certifikat för att snabbt ogiltigförklara komprometterade certifikat
- Använd starka nyckelstorlekar på minst 2048 bitar för RSA-nycklar
- Konfigurera dina servrar för att endast acceptera säker TLS versioner och starka chiffersviter
Din klientsäkerhetsstrategi bör inkludera att skydda privata nycklar med starka åtkomstkontroller. Regelbundna säkerhetsrevisioner hjälper till att upprätthålla systemets integritet över tid.
Felsökning av vanliga problem
Certifikatkedjan
Vid implementering av mTLS, kan du stöta på problem med certifikatkedjan. Dessa härrör vanligtvis från:
- Ofullständiga certifikatkedjor
- Felaktigt installerade mellancertifikat
Så här löser du dessa problem:
- Verifiera att din förtroendeankarkonfiguration är korrekt
- Se till att alla nödvändiga certifikat finns
Anslutningsproblem
Anslutningsproblem relaterar ofta till:
- Brandväggsinställningar blockerar TLS trafik
- Felaktiga certifikatbehörigheter
För att felsöka:
- Kontrollera att dina certifikat har rätt namn
- Se till att de är anpassade till deras avsedda användning
Prestandaöverväganden
Prestationsöverväganden blir viktiga i skala. Så här optimerar du prestanda:
- Implementera sessionscache för att minska omkostnaderna för upprepade handskakningar
- Välj effektiva chiffersviter som balanserar säkerhet och prestanda
- Övervaka din certifikatvalideringsprocess för att säkerställa att den inte skapar onödiga omkostnader
Slutsats
