Hvad er mTLS (mutual TLS)? Komplet guide

I almindelig TLS beviser kun serveren sin identitet — klienten forbliver anonym. mTLS vender den ligning om: begge parter præsenterer et certifikat, og ingen forbindelse etableres uden at begge er verificeret. Det er fundamentet under Zero Trust og service mesh-sikkerhed. Her er hvordan det virker, hvornår du skal bruge det, og hvordan du sætter det op.

Kort svar

mTLS (mutual TLS) er TLS hvor begge parter autentificerer sig med et certifikat — ikke kun serveren. Under handshaken beder serveren klienten om et certifikat, og klienten beder som altid om serverens. Begge sider validerer modpartens certifikat mod en betroet CA. Forbindelsen oprettes kun hvis begge certifikater er gyldige, ikke udløbne og udstedt af en CA man stoler på. mTLS bruges til at sikre service-til-service-kommunikation, API'er og alt hvor du vil bevise hvem der ringer — ikke bare at linjen er krypteret.

mTLS vs almindelig TLS: hvad er forskellen?

Almindelig TLS (det din browser bruger på https) autentificerer kun serveren. Du ved at du taler med den rigtige example.com, men example.com ved ikke hvem du er — det afgøres bagefter med f.eks. et login og en cookie. mTLS flytter klient-identiteten ned i selve transportlaget:

	Almindelig TLS	mTLS
Server beviser identitet	Ja	Ja
Klient beviser identitet	Nej	Ja
Kryptering	Ja	Ja
Typisk brug	Offentlige websites	Service-til-service, API'er, Zero Trust

Vi går i dybden i mTLS vs almindelig TLS.

Sådan udvider mTLS handshaken

En normal TLS-handshake forhandler protokol og cipher suite og verificerer serverens certifikat. mTLS tilføjer to beskeder: serveren sender en CertificateRequest, og klienten svarer med sit eget Certificate plus en CertificateVerify der beviser, at klienten ejer den private nøgle. Du kan se serverens forespørgsel i s_client-output som Acceptable client certificate CA names — det er listen over CA'er hvis klientcertifikater serveren accepterer.

Prøv det: opret en intern CA og et klientcertifikat

mTLS kræver en CA der udsteder klientcertifikater. Til intern brug laver man typisk sin egen. Her opretter vi en CA og signerer et klientcertifikat med den rette Extended Key Usage:

# 1) Opret en intern CA
openssl req -x509 -newkey rsa:4096 -nodes -keyout ca.key -out ca.crt \
  -days 3650 -subj "/CN=Internal Root CA"

# 2) Opret klientnoegle + CSR
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr \
  -subj "/CN=service-a"

# 3) Signer klientcertifikatet med clientAuth EKU
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out client.crt -days 365 \
  -extfile <(printf "extendedKeyUsage=clientAuth")

Bemærk extendedKeyUsage=clientAuth — uden den vil mange servere afvise certifikatet som uegnet til klient-autentificering.

Kræv klientcertifikat på serveren (nginx)

I nginx aktiveres mTLS med tre direktiver: peg på CA'en der skal validere klienter, og sæt verifikationen til obligatorisk:

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/ssl/api/fullchain.pem;
    ssl_certificate_key /etc/ssl/api/privkey.pem;

    # mTLS: kraev og valider klientcertifikat mod vores CA
    ssl_client_certificate /etc/ssl/api/ca.crt;
    ssl_verify_client      on;
    ssl_verify_depth       2;

    location / {
        # videregiv klientens identitet til backend
        proxy_set_header X-Client-DN  $ssl_client_s_dn;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_pass http://backend;
    }
}

ssl_verify_client on afviser enhver forbindelse uden gyldigt klientcertifikat. Med optional tillades anonyme klienter, men du kan stadig læse $ssl_client_verify i din applikation og afgøre adgang der.

Forbind som klient (curl)

En klient skal nu sende sit certifikat og sin nøgle:

curl --cert client.crt --key client.key \
     --cacert ca.crt \
     https://api.example.com/health

Mangler --cert/--key, afviser serveren handshaken — og fejlmeldingen er ofte en kryptisk sslv3 alert handshake failure. Se vores guide til fejlfinding af mTLS.

Hvornår skal du bruge mTLS?

Service-til-service inde i et cluster — hvor du vil have at hver service beviser sin identitet, ikke bare deler et netværk. Se mTLS i Kubernetes.
API gateway → backend — så backend kun accepterer trafik fra gatewayen. Se mTLS mellem API gateway og backend.
Maskine-til-maskine-API'er hvor et delt certifikat er stærkere og mere reviderbart end en API-token. Sammenlign med OAuth2 client credentials.
Zero Trust-arkitektur hvor intet netværk er betroet og hver forbindelse skal autentificeres. Se mTLS og Zero Trust.

For browser-baseret adgang findes også klientcertifikater i browsere, men det er en niche med sin egen UX.

Den skjulte byrde: mange flere certifikater

mTLS er stærk sikkerhed, men prisen er certifikat-spredning. Pludselig har hver service, hver klient og hver intern CA sit eget certifikat med sin egen udløbsdato. Et udløbet klientcertifikat afbryder en integration lige så effektivt som et udløbet servercertifikat — men det opdages sjældnere, fordi ingen browser advarer om det.

Sådan holder CertControl styr på dine mTLS-certifikater

CertControl opdager og overvåger certifikater på tværs af jeres miljø — inklusive klientcertifikater og certifikater udstedt af interne CA'er. Platformen sporer hver udløbsdato, validerer at kæderne er komplette, og advarer i god tid før et certifikat udløber, uanset om det sidder på en server eller i en service-til-service-klient. Så bliver et udløbet mTLS-certifikat aldrig det næste produktionsnedbrud, som ingen så komme.

Ofte stillede spørgsmål

Hvad står mTLS for?

Mutual TLS — gensidig TLS. "Mutual" henviser til at begge parter (både server og klient) autentificerer sig med et certifikat, i modsætning til almindelig TLS hvor kun serveren gør det.

Er mTLS mere sikkert end almindelig TLS?

Det giver en ekstra sikkerhedsgaranti: serveren ved hvem klienten er, allerede på transportlaget. Det forhindrer at uautoriserede klienter overhovedet kan etablere en forbindelse. Men det erstatter ikke autorisation — du skal stadig afgøre hvad en autentificeret klient må.

Skal jeg bruge en offentlig CA til mTLS?

Næsten aldrig. Klientcertifikater til mTLS udstedes typisk af en intern CA, du selv kontrollerer, fordi du så bestemmer præcis hvilke klienter der er gyldige. Offentlige CA'er udsteder normalt ikke clientAuth-certifikater til vilkårlige interne navne.

Hvad er forskellen på mTLS og en API-token?

En API-token er en delt hemmelighed der sendes i en header; et mTLS-certifikat beviser ejerskab af en privat nøgle uden at sende hemmeligheden. Certifikater udløber og kan tilbagekaldes via en CA, og identiteten bindes til transportlaget. Se sammenligningen med OAuth2 client credentials.

Hvad sker der hvis et klientcertifikat udløber?

Handshaken fejler, og klienten kan ikke forbinde — typisk med en handshake-fejl frem for en pæn fejlmeddelelse. Derfor er overvågning af klientcertifikaters udløb lige så vigtigt som for servercertifikater.

Kan jeg køre mTLS og almindelig TLS på samme server?

Ja. Du kan kræve klientcertifikat kun på bestemte paths eller server-blokke (fx /api) og lade resten være åbent. I nginx styres det med ssl_verify_client per location eller per server.

Se platformen Book demo