F5 : certificats, SNI et authentification mTLS

Ce guide concerne BIG-IP sur TMOS. Les noms et options doivent être confrontés à la documentation de votre version.

Repère visuelLe 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.

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 sa fiabilité dépend d’une frontière de confiance explicite ; ce n’est pas la même preuve qu’un handshake mTLS direct.

Repère visuelmTLS 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.

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

Références consultées le 2 octobre 2026. 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é.

F5 — ltm profile client-ssl · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
Projet OpenSSL — openssl s_client · OpenSSL 3.5 · consulté le 2 octobre 2026.
F5 — ltm profile server-ssl · Référence TMSH v17.0.0 · consulté le 2 octobre 2026.
F5 — About SSL Profiles · BIG-IP 21.0.0 · consulté le 2 octobre 2026.

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