Kort svar
På F5 BIG-IP terminerer en Client SSL-profil TLS fra klienten (den indeholder det offentlige certifikat og dets nøgle som et cert-key-objekt). En Server SSL-profil styrer TLS ud mod backend. Knytter du kun en Client SSL-profil til din virtual server, laver BIG-IP'en offloading. Knytter du begge, laver den bridging (re-encryption). Uden nogen SSL-profil er det ren passthrough.
De to profiltyper
| Profil | Retning | Indeholder |
|---|---|---|
| Client SSL | BIG-IP ← klient | Servercertifikat + nøgle (cert-key), kæde, ciphers |
| Server SSL | BIG-IP → backend | Trust/validering af backend, evt. klientcertifikat til mTLS |
Cert-key-objektet
Certifikatet og dets private nøgle importeres som separate objekter under SSL Certificate List og knyttes derefter sammen i Client SSL-profilen. Husk at importere den fulde kæde (intermediates) i profilens Chain-felt, ellers serverer BIG-IP'en kun leaf-certifikatet og ikke-browser-klienter fejler med "unable to get local issuer certificate". Med tmsh:
# Importér nøgle og certifikat
tmsh install sys crypto key example.com.key from-local-file /var/tmp/privkey.pem
tmsh install sys crypto cert example.com.crt from-local-file /var/tmp/fullchain.pem
# Opret Client SSL-profil der binder cert + key + kæde
tmsh create ltm profile client-ssl example_clientssl \
cert example.com.crt key example.com.key chain ca-bundle.crt \
ciphers "ECDHE+AES-GCM:ECDHE+CHACHA20" \
options { no-tlsv1 no-tlsv1.1 no-sslv3 }
Offloading vs bridging på BIG-IP
Hvilke profiler du knytter til den virtuelle server afgør arkitekturen — præcis som beskrevet i offloading vs passthrough vs bridging:
- Offloading: kun en Client SSL-profil. BIG-IP'en dekrypterer og sender klartekst til backend.
- Bridging: både Client SSL og Server SSL. BIG-IP'en dekrypterer, kan køre iRules/WAF, og krypterer igen mod backend.
- Passthrough: ingen SSL-profil. Den krypterede stream går urørt til backend, der selv terminerer.
# Bridging: knyt BÅDE client-ssl og server-ssl til den virtuelle server
tmsh modify ltm virtual vs_https \
profiles add { example_clientssl { context clientside } \
example_serverssl { context serverside } }
Server SSL og backend-validering
Ved bridging bør Server SSL-profilen faktisk validere backend-certifikatet (server-name og en CA-bundle), ikke bare kryptere blindt. Ellers er backend-leddet krypteret men ikke autentificeret. Backend-certifikatet er — som ved Azure ende-til-ende TLS — det der oftest glemmes, fordi det ikke er offentligt.
mTLS og klientcertifikater
Skal klienter præsentere et certifikat, sætter du Client Certificate: require og en trusted CA i Client SSL-profilen. Skal BIG-IP'en omvendt præsentere et klientcertifikat over for backend, ligger det i Server SSL-profilen. Mere om mønsteret i mTLS i Kubernetes — princippet er det samme.
Sådan holder CertControl styr på jeres BIG-IP-certifikater
En BIG-IP samler hurtigt mange Client SSL-profiler, hver med sit eget cert-key-objekt og sin egen udløbsdato — og de interne Server SSL-/backend-certifikater oven i. CertControl scanner alle de virtuelle servere udefra, bekræfter at kæden serveres komplet og at protokollerne er moderne, og advarer før et hvilket som helst af certifikaterne udløber. Se også ACME-pillaren om at automatisere fornyelsen og rotation uden nedetid når et nyt cert-key-objekt skal tages i brug.
Ofte stillede spørgsmål
Hvad er forskellen på en Client SSL- og en Server SSL-profil?
Client SSL-profilen terminerer TLS fra klienten og indeholder dit servercertifikat og nøgle. Server SSL-profilen styrer TLS fra BIG-IP'en ud mod backend. De to profiler er uafhængige og knyttes hver for sig til den virtuelle server.
Hvordan laver jeg offloading vs bridging på BIG-IP?
Offloading: knyt kun en Client SSL-profil til den virtuelle server. Bridging: knyt både en Client SSL- og en Server SSL-profil. Ingen SSL-profil giver ren passthrough.
Hvad er et cert-key-objekt?
Certifikatet og den private nøgle importeres som separate objekter på BIG-IP'en og bindes sammen i Client SSL-profilen. Husk også at lægge intermediates i profilens Chain-felt, så hele kæden serveres.
Hvorfor serverer min BIG-IP ikke hele kæden?
Fordi intermediate-certifikaterne ikke er angivet i Client SSL-profilens Chain-felt. Uden dem sender BIG-IP'en kun leaf-certifikatet, og ikke-browser-klienter fejler. Tilføj kæden i profilen.
Kan BIG-IP håndtere mTLS?
Ja. Klient-mTLS sættes i Client SSL-profilen (Client Certificate: require + en trusted CA). Skal BIG-IP'en selv præsentere et klientcertifikat mod backend, lægges det i Server SSL-profilen.