↓Zum Hauptinhalt springen
  1. Artikel/

Zugriffskontrolle über Client-Zertifikate (mTLS)

Default Default
Inhaltsverzeichnis

Zugriffskontrolle über Client-Zertifikate (mTLS) #

1. Grundprinzip #

Im normalen HTTPS-Verkehr authentifiziert sich nur der Server mit einem Zertifikat gegenüber dem Client.
Bei mutual TLS (mTLS) geschieht die Authentifizierung beidseitig:

  • Der Server weist sich durch sein Zertifikat aus.
  • Der Client (Browser, Gerät, API) präsentiert ebenfalls ein Zertifikat, das der Server prüft.

Dadurch kann der Server exakt festlegen, welche Clients Zugriff erhalten – z.B. nur Mitarbeiter oder Geräte mit gültigem Unternehmenszertifikat.

2. Ablauf (vereinfacht) #

┌────────────┐          ┌───────────────────────┐
│  Benutzer  │  HTTPS → │  Interner Webserver   │
│  (Browser) │          │  mit mTLS aktiviert   │
└─────┬──────┘          └─────────────┬─────────┘
      │                               │
      │ 1. Server sendet Zertifikatsanforderung
      │                               │
      │ 2. Client sendet eigenes Zertifikat
      │                               │
      │ 3. Server prüft:
      │      - Signiert durch vertrauenswürdige CA?
      │      - Gültig, nicht abgelaufen?
      │      - Berechtigt (z.B. anhand CN)?
      │                               │
      │ 4. Bei Erfolg → Zugriff erlaubt
      │    Sonst → 403 Forbidden
      │                               │

3. Typische Einsatzszenarien #

Bereich Beispiel
Intranet-Zugriff Nur Geräte mit Firmenzertifikat dürfen interne Seiten aufrufen.
APIs zwischen Systemen Microservices authentifizieren sich gegenseitig über Zertifikate.
VPN & Zero-Trust-Netzwerke Jeder Client besitzt ein Zertifikat aus der internen PKI.
Industrie & IoT Maschinen identifizieren sich eindeutig über Zertifikate.

4. Beispielkonfiguration (nginx) #

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

    ssl_certificate      /etc/ssl/certs/server.crt;
    ssl_certificate_key  /etc/ssl/private/server.key;

    # CA, die Client-Zertifikate ausgestellt hat
    ssl_client_certificate /etc/ssl/ca/clients_ca.crt;

    # Zertifikatspflicht aktivieren
    ssl_verify_client on;

    location /admin/ {
        if ($ssl_client_verify != SUCCESS) {
            return 403;
        }
        # Beispielhafte Filterung nach Distinguished Name
        if ($ssl_client_s_dn !~ "CN=Thorben Kaufmann") {
            return 403;
        }
        root /srv/admin;
    }
}

Damit dürfen nur Clients mit gültigem Zertifikat, das von clients_ca.crt signiert wurde, den Pfad /admin/ öffnen.

5. Einrichtung einer internen CA #

Zur Ausstellung von Client-Zertifikaten wird eine interne PKI (Public Key Infrastructure) benötigt.
Ein einfaches Setup kann z.B. mit OpenSSL erstellt werden:

# CA-Schlüssel und Zertifikat erzeugen
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt

# Client-Schlüssel und CSR erzeugen
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr

# Client-Zertifikat signieren
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial   -out client.crt -days 365 -sha256

Der Client erhält danach client.crt und client.key (oft in einer .p12-Datei kombiniert).

6. Vorteile und Herausforderungen #

Vorteile Herausforderungen
Passwortlos, stark kryptografisch Verteilung und Verwaltung von Zertifikaten
Schutz gegen Phishing Regelmäßige Erneuerung (z.B. jährlich)
Gerätebindung möglich Aufwändigere Serverkonfiguration
Ideal für Maschinenkommunikation Dokumentation & PKI-Organisation nötig

7. Fazit #

mTLS (mutual TLS) ist ein bewährtes Verfahren, um Benutzer oder Geräte anhand von Zertifikaten zu authentifizieren.
Es wird in Unternehmen, Rechenzentren und industriellen Netzwerken eingesetzt, um sicheren, passwortlosen Zugriff zu ermöglichen.

Weiterführend #

↑