Menu
Comprendre F5 · LTM

F5 : certificats, SNI et authentification mTLS

Vérifier identité, chaîne de confiance, sélection SNI et certificat client ; distinguer les authentifications des deux côtés du proxy.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (3)
  • Certification : F5 301A · Référence consultée le · Objectifs abordés : F5 301A 1.04, F5 301A 2.02.
  • Certification : F5 301B · Référence consultée le · Objectifs abordés : F5 301B 2.07, F5 301B 2.09.
  • Certification : F5CTSLTMR · Référence consultée le · Objectifs abordés : F5CTSLTMR 6.01, F5CTSLTMR 6.02, F5CTSLTMR 6.03, F5CTSLTMR 6.04.

Ce guide concerne BIG-IP sur TMOS. Vérifiez les noms et les options dans la documentation de votre version.

Comprendre en imageLe SNI arrive avant le Host HTTP
Le SNI arrive avant le Host HTTP Le client annonce éventuellement le SNI dans son ClientHello. Le certificat est choisi pendant TLS, puis HTTP peut être échangé. Le contrôle du nom, de la chaîne, de la validité et du certificat client sont des vérifications distinctes. mTLS éventuel Objets, conditions et comparaisons du guide ClientHello SNI : app.example.test Certificat serveur Choix pendant TLS Contrôles TLS Chaîne, nom, dates HTTP Host et URI disponibles Session chiffrée TLS établi Certificat client Si demandé / exigé Quatre contrôles indépendants Pour le service HTTPS, examinez le nom couvertpar le certificat, sa période de validité, sa chaîneet son association à la bonne clé privée. Uncertificat non expiré peut être présenté pour lemauvais nom ou avec une chaîne incomplète. Le SNI précède l’en-tête HTTP Host Le client peut annoncer un nom dans ClientHelloavec SNI. Ce nom participe à la sélection du profilClient SSL quand plusieurs profils correspondent àla VIP. L’en-tête HTTP Host arrive plus tard, aprèsl’établissement TLS ; il ne peut pas corrigerrétroactivement le certificat déjà présenté.

Le client annonce éventuellement le SNI dans son ClientHello. Le certificat est choisi pendant TLS, puis HTTP peut être échangé. Le contrôle du nom, de la chaîne, de la validité et du certificat client sont des vérifications distinctes.

Télécharger le schéma en SVG · version claire

Quatre contrôles indépendants

Pour le service HTTPS, examinez le nom couvert par le certificat, sa période de validité, sa chaîne et son association à la bonne clé privée. Un certificat non expiré peut être présenté pour le mauvais nom ou avec une chaîne incomplète.

Le certificat terminal et les intermédiaires ont des rôles différents. La présence du fichier dans BIG-IP ne prouve pas qu’il est utilisé par le profil sélectionné. Vérifiez l’association cert/key/chain et le résultat observé par un client.

Sources : F5, ltm profile client-ssl ; Projet OpenSSL, openssl s_client.

Le SNI précède l’en-tête HTTP Host

Le client peut annoncer un nom dans ClientHello avec SNI. Ce nom participe à la sélection du profil Client SSL quand plusieurs profils correspondent à la VIP. L’en-tête HTTP Host arrive plus tard, après l’établissement TLS ; il ne peut pas corriger rétroactivement le certificat déjà présenté.

Prévoyez le comportement des clients sans SNI et des noms inconnus. Les propriétés server-name, sni-default et sni-require doivent être relues ensemble dans la version utilisée.

Sources : F5, ltm profile client-ssl.

Demander un certificat n’est pas toujours l’exiger

mTLS ajoute l’authentification du client par certificat. Un mode qui demande un certificat sans l’imposer ne répond pas au même besoin qu’un mode qui le requiert. L’autorité de confiance, la profondeur de chaîne et les règles sur la validité restent à définir.

La gestion de révocation dépend également des mécanismes configurés, tels que CRL ou OCSP dans les cas supportés. Une chaîne reconnue ne prouve pas à elle seule qu’un certificat révoqué sera refusé.

Sources : F5, ltm profile client-ssl ; F5, ltm profile server-ssl.

Deux authentifications possibles en ré-encryption

Si le backend exige un certificat client, il dialogue avec BIG-IP en tant que client TLS. Le certificat utilisé par le profil Server SSL n’est pas automatiquement celui de l’utilisateur initial, et la clé privée de cet utilisateur n’est pas transférée par le proxy.

Décidez où l’identité utilisateur doit être validée et comment l’application doit la recevoir. Un en-tête peut porter une information provenant du proxy, mais l’application doit vérifier qu’elle vient d’un proxy autorisé ; ce n’est pas la même preuve qu’un handshake mTLS direct.

Comprendre en imagemTLS client et confiance backend sont indépendants
mTLS client et confiance backend sont indépendants Le client peut être authentifié par son certificat sur la session Client SSL. Le certificat du backend peut être vérifié sur la session Server SSL. Ces deux chaînes de confiance sont distinctes ; le certificat client n’est pas automatiquement transmis comme identité TLS au backend. Objets, conditions et comparaisons du guide Client Certificat client Client SSL Vérifie le client CA clients Confiance configurée Serveur Certificat backend Server SSL Vérifie le serveur CA serveurs Confiance configurée Quatre contrôles indépendants Pour le service HTTPS, examinez le nom couvertpar le certificat, sa période de validité, sa chaîneet son association à la bonne clé privée. Uncertificat non expiré peut être présenté pour lemauvais nom ou avec une chaîne incomplète. Le SNI précède l’en-tête HTTP Host Le client peut annoncer un nom dans ClientHelloavec SNI. Ce nom participe à la sélection du profilClient SSL quand plusieurs profils correspondent àla VIP. L’en-tête HTTP Host arrive plus tard, aprèsl’établissement TLS ; il ne peut pas corrigerrétroactivement le certificat déjà présenté.

Le client peut être authentifié par son certificat sur la session Client SSL. Le certificat du backend peut être vérifié sur la session Server SSL. Ces deux chaînes de confiance sont distinctes ; le certificat client n’est pas automatiquement transmis comme identité TLS au backend.

Télécharger le schéma en SVG · version claire

Sources : F5, About SSL Profiles ; F5, ltm profile server-ssl.

Observer ce qui est réellement présenté

Depuis un poste de test autorisé, adaptez nom et IP de documentation. Le contrôle ci-dessous demande une vérification du nom et arrête l’échange en cas d’erreur de validation. Fournissez le fichier de CA approprié si votre environnement utilise une autorité privée.

Contrôler le certificat présentéShell · requête TLS de diagnostic
openssl s_client -connect 192.0.2.40:443 \
  -servername app.example.invalid \
  -verify_hostname app.example.invalid \
  -verify_return_error -showcerts

Sources : Projet OpenSSL, openssl s_client.

Construire une matrice de tests

En laboratoire, comparez un nom connu, un nom inconnu, un client sans certificat et un client doté d’un certificat approuvé. Notez pour chacun le profil attendu et le résultat souhaité. Ajoutez expiration et révocation si ces critères font partie du besoin.

Les réglages SSLv3 ou les suites anciennes présents dans certains supports historiques ne doivent pas être réintroduits pour résoudre un symptôme sans analyse. La configuration TLS doit rester alignée sur les exigences et la version réellement exploitées.

Sources : F5, ltm profile client-ssl ; Projet OpenSSL, openssl s_client.

Sources et portée

Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.

Retrouver le parcours de lecture F5 LTM

Continuer la série F5

Explorer tous les guides du parcours F5 LTM

Découvrir l’expertise F5 de Samhan

Échange

Besoin d’éclaircir votre architecture F5 ?

Échangeons sur vos flux, vos contraintes de disponibilité et vos services applicatifs.

Parler de votre projet