mTLS mellem API gateway og backend

Mange arkitekturer har et velsikret ydre — TLS, WAF og autentificering på gatewayen — men en blød kerne, hvor gatewayen taler til backenden over uautentificeret HTTP. Hvis nogen kommer forbi gatewayen, eller en anden service kan nå backenden direkte, falder hele modellen. mTLS lukker det hul.

Kort svar

Brug mTLS på hoppet mellem API gateway og backend, så backenden kun accepterer forbindelser fra gatewayen — og kun fordi gatewayen kan fremvise et gyldigt klientcertifikat. Gatewayen autentificerer brugerne udadtil; mTLS sikrer, at trafikken til backenden faktisk kommer fra gatewayen og ikke fra en omvej. Det forhindrer at en kompromitteret nabo-service eller en intern angriber kan ramme backenden direkte.

Truslen mTLS lukker

Et typisk setup: gateway på kanten, backend-services på et internt netværk. Problemet er at "internt netværk" sjældent er en reel sikkerhedsgrænse. Enhver pod, container eller server der kan route til backenden, kan kalde den — gatewayens autentificering springes helt over. mTLS gør backenden selektiv: den åbner kun for klienter med et certifikat, den stoler på.

Trin 1: udsted et klientcertifikat til gatewayen

Backenden skal stole på en CA, og gatewayen får et klientcertifikat fra netop den CA:

# Backendens interne CA (kan vaere jeres eksisterende interne CA)
openssl req -x509 -newkey rsa:4096 -nodes -keyout backend-ca.key \
  -out backend-ca.crt -days 3650 -subj "/CN=Backend Internal CA"

# Klientcertifikat til gatewayen, med clientAuth EKU
openssl req -newkey rsa:2048 -nodes -keyout gateway.key -out gateway.csr \
  -subj "/CN=api-gateway"
openssl x509 -req -in gateway.csr -CA backend-ca.crt -CAkey backend-ca.key \
  -CAcreateserial -out gateway.crt -days 365 \
  -extfile <(printf "extendedKeyUsage=clientAuth")

Trin 2: backend kræver klientcertifikat (nginx)

Backendens TLS-terminering — her nginx foran applikationen — sættes til at kræve og verificere klientcertifikatet:

server {
    listen 8443 ssl;
    server_name backend.internal;

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

    ssl_client_certificate /etc/ssl/backend/backend-ca.crt;
    ssl_verify_client      on;

    location / {
        # afvis alt der ikke er en verificeret gateway-identitet
        if ($ssl_client_s_dn !~ "CN=api-gateway") { return 403; }
        proxy_pass http://127.0.0.1:8080;
    }
}

Her bruger vi $ssl_client_s_dn til både at kræve et gyldigt certifikat og at det er gatewayens. Det skelner mellem autentificering (gyldigt cert) og autorisation (det rigtige cert).

Trin 3: gatewayen sender sit klientcertifikat (Envoy)

Bruger du Envoy som gateway, konfigureres et upstream-TLS-kontekst med klientcertifikat og den CA, der validerer backenden:

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
    common_tls_context:
      tls_certificates:
        - certificate_chain: { filename: "/etc/envoy/gateway.crt" }
          private_key:       { filename: "/etc/envoy/gateway.key" }
      validation_context:
        trusted_ca: { filename: "/etc/envoy/backend-ca.crt" }
        match_typed_subject_alt_names:
          - san_type: DNS
            matcher: { exact: "backend.internal" }

Med nginx som gateway er ækvivalenten proxy_ssl_certificate, proxy_ssl_certificate_key og proxy_ssl_trusted_certificate i en location-blok mod upstream.

Verificér hoppet

Test at backenden afviser dig uden certifikat, og accepterer dig med:

# Skal fejle (ingen klientcert):
curl https://backend.internal:8443/health

# Skal lykkes (gateway-identitet):
curl --cert gateway.crt --key gateway.key \
     --cacert backend-ca.crt \
     https://backend.internal:8443/health

Fejler det selv med certifikat, så tjek de typiske mTLS-faldgruber — forkert CA, manglende EKU eller en ufuldstændig kæde — i fejlfinding af mTLS.

Pas på: gateway-certifikatet der udløber i stilhed

Gateway-til-backend-mTLS skaber et certifikat ingen ser i en browser. Når gatewayens klientcertifikat udløber, holder al trafik til backenden op med at virke på én gang — uden forvarsel og uden en pæn fejlside. CertControl overvåger også denne slags interne klientcertifikater fra interne CA'er, sporer udløb og advarer i god tid, så hoppet mellem gateway og backend ikke pludselig bliver et single point of failure. Forstå grundlaget i vores mTLS-guide og se det bredere billede i mTLS og Zero Trust.

Ofte stillede spørgsmål

Hvorfor er TLS alene ikke nok mellem gateway og backend?

Almindelig TLS krypterer og beviser backendens identitet, men ikke gatewayens. Enhver klient på det interne netværk kan stadig forbinde. mTLS kræver at klienten — gatewayen — også beviser sin identitet, så backenden kan afvise alle andre.

Skal jeg bruge samme CA til gateway og brugere?

Nej, og som regel skal du ikke. Brugernes TLS til gatewayen bruger typisk et offentligt certifikat, mens gateway-til-backend-mTLS bruger en intern CA, du kontrollerer fuldt ud.

Kan jeg begrænse hvilken identitet backenden accepterer?

Ja. At kræve et gyldigt certifikat er autentificering; at tjekke at det er det rigtige certifikat (fx via $ssl_client_s_dn i nginx eller SAN-matchere i Envoy) er autorisation. Brug begge.

Hvad sker der hvis gatewayens klientcertifikat udløber?

Backenden afviser alle forbindelser fra gatewayen, og din API holder op med at svare — typisk uden en tydelig fejl. Derfor er overvågning af udløb på interne klientcertifikater kritisk.

Virker det med flere gateway-instanser?

Ja. Udsted enten samme klientcertifikat til alle instanser, eller giv hver instans sit eget certifikat fra samme CA. Backenden stoler på CA'en, ikke på en enkelt instans.

Se platformen Book demo