Échecs de handshake TLS/SSL

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

Un échec du handshake TLS/SSL se produit lorsqu'un client et un serveur ne parviennent pas à établir une communication à l'aide du protocole TLS/SSL. Lorsque cette erreur se produit dans Apigee Edge, l'application cliente reçoit un état HTTP 503 avec le message Service Unavailable (Service indisponible). Cette erreur s'affiche après tout appel d'API en cas d'échec du handshake TLS/SSL.

Messages d'erreur

HTTP/1.1 503 Service Unavailable

Vous pouvez également voir ce message d'erreur en cas d'échec du handshake TLS/SSL :

Received fatal alert: handshake_failure

Causes possibles

TLS (Transport Layer Security, dont SSL est l'ancêtre) est la technologie de sécurité standard pour établir un lien chiffré entre un serveur Web et un client Web, tel qu'un navigateur ou une application. Une poignée de main est un processus qui permet au client et au serveur TLS/SSL d'établir un ensemble de clés secrètes avec lesquelles ils peuvent communiquer. Au cours de ce processus, le client et le serveur :

1. S'entendre sur la version du protocole à utiliser.
2. Sélectionnez l'algorithme cryptographique à utiliser.
3. s'authentifier mutuellement en échangeant et en validant des certificats numériques.

Si le handshake TLS/SSL réussit, le client et le serveur TLS/SSL se transfèrent des données de manière sécurisée. Sinon, en cas d'échec du handshake TLS/SSL, la connexion est interrompue et le client reçoit une erreur 503 Service Unavailable.

Voici les causes possibles d'échec du handshake TLS/SSL :

Protocole non correspondant

Un échec de handshake TLS/SSL se produit si le protocole utilisé par le client n'est pas compatible avec le serveur, que ce soit pour la connexion entrante (vers le nord) ou sortante (vers le sud). Consultez également Comprendre les connexions Northbound et Southbound.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Northbound ou Southbound. Pour obtenir plus d'informations sur la façon de déterminer la source du problème, consultez Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir plus d'informations :
   • Si vous êtes un utilisateur de Private Cloud, vous pouvez collecter les données tcpdump au niveau du client ou du serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou nord) ou le processeur de messages (pour les connexions sortantes ou sud). Un serveur peut être le routeur Edge (pour les connexions entrantes ou nord) ou le serveur backend (pour les connexions sortantes ou sud) en fonction de votre détermination à l'étape 1.
   • Si vous êtes un utilisateur du cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou nord) ou sur le serveur de backend (pour les connexions sortantes ou sud), car vous n'avez pas accès au routeur Edge ni au processeur de messages.

   tcpdump -i any -s 0 host IP address -w File name
   

   Pour en savoir plus sur l'utilisation de la commande tcpdump, consultez les données tcpdump.
3. Analysez les données tcpdump à l'aide de l'outil Wireshark ou d'un outil similaire.
4. Voici un exemple d'analyse de tcpdump à l'aide de Wireshark :
   • Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre le processeur de messages et le serveur de backend (la connexion sortante ou southbound).
   • Le message 4 de la sortie tcpdump ci-dessous indique que le processeur de messages (source) a envoyé un message "Client Hello" au serveur backend (destination).
     

     

   • Si vous sélectionnez le message Client Hello, cela indique que le processeur de messages utilise le protocole TLSv1.2, comme illustré ci-dessous :

     

   • Le message 5 montre que le serveur backend accuse réception du message "Client Hello" du processeur de messages.
   • Le serveur backend envoie immédiatement Fatal Alert : Close Notify au processeur de messages (message 6). Cela signifie que le handshake TLS/SSL a échoué et que la connexion sera fermée.

   • En examinant plus en détail le message 6, on constate que l'échec du handshake TLS/SSL est dû au fait que le serveur backend n'est compatible qu'avec le protocole TLSv1.0, comme indiqué ci-dessous :

     

   • En raison d'une incompatibilité entre le protocole utilisé par le processeur de messages et le serveur de backend, ce dernier a envoyé le message Fatal Alert Message: Close Notify.

Solution

Le processeur de messages s'exécute sur Java 8 et utilise le protocole TLSv1.2 par défaut. Si le serveur backend ne prend pas en charge le protocole TLSv1.2, vous pouvez procéder de l'une des manières suivantes pour résoudre ce problème :

1. Mettez à niveau votre serveur de backend pour qu'il soit compatible avec le protocole TLSv1.2. Il s'agit d'une solution recommandée, car le protocole TLSv1.2 est plus sécurisé.
2. Si, pour une raison quelconque, vous ne parvenez pas à mettre à niveau votre serveur de backend immédiatement, vous pouvez forcer le processeur de messages à utiliser le protocole TLSv1.0 pour communiquer avec le serveur de backend en procédant comme suit :
   1. Si vous n'avez pas spécifié de serveur cible dans la définition TargetEndpoint du proxy, définissez l'élément Protocol sur TLSv1.0 comme indiqué ci-dessous :

      <TargetEndpoint name="default">
       …
       <HTTPTargetConnection>
         <SSLInfo>
             <Enabled>true</Enabled>
             <Protocols>
                 <Protocol>TLSv1.0</Protocol>
             </Protocols>
         </SSLInfo>
         <URL>https://myservice.com</URL>
       </HTTPTargetConnection>
       …
      </TargetEndpoint>

   2. Si vous avez configuré un serveur cible pour votre proxy, utilisez cette API Management pour définir le protocole sur TLSv1.0 dans la configuration du serveur cible spécifique.

Non-concordance des codes secrets

Un échec de handshake TLS/SSL peut se produire si l'algorithme de la suite de chiffrement utilisé par le client n'est pas compatible avec le serveur pour la connexion entrante (vers le nord) ou sortante (vers le sud) dans Apigee Edge. Consultez également Comprendre les connexions Northbound et Southbound.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Northbound ou Southbound. Pour obtenir plus d'informations sur la façon de déterminer la source du problème, consultez Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir plus d'informations :
   • Si vous êtes un utilisateur de Private Cloud, vous pouvez collecter les données tcpdump au niveau du client ou du serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou nord) ou le processeur de messages (pour les connexions sortantes ou sud). Un serveur peut être le routeur Edge (pour les connexions entrantes ou nord) ou le serveur backend (pour les connexions sortantes ou sud) en fonction de votre détermination à l'étape 1.
   • Si vous êtes un utilisateur du cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou nord) ou sur le serveur de backend (pour les connexions sortantes ou sud), car vous n'avez pas accès au routeur Edge ni au processeur de messages.

   tcpdump -i any -s 0 host IP address -w File name
   

   Pour en savoir plus sur l'utilisation de la commande tcpdump, consultez les données tcpdump.
3. Analysez les données tcpdump à l'aide de l'outil Wireshark ou de tout autre outil que vous connaissez.
4. Voici un exemple d'analyse de la sortie tcpdump à l'aide de Wireshark :
   • Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre l'application cliente et le routeur Edge (connexion sortante). La sortie tcpdump a été collectée sur le routeur Edge.

   • Le message #4 dans la sortie tcpdump ci-dessous montre que l'application cliente (source) a envoyé un message "Client Hello" au routeur Edge (destination).

     

   • La sélection du message "Client Hello" montre que l'application cliente utilise le protocole TLSv1.2.

     

   • Le message 5 indique que le routeur Edge a accusé réception du message "Client Hello" de l'application cliente.
   • Le routeur Edge envoie immédiatement une alerte fatale : échec du handshake à l'application cliente (message 6). Cela signifie que le handshake TLS/SSL a échoué et que la connexion sera fermée.
   • En examinant plus en détail le message 6, vous trouverez les informations suivantes :
     • Le routeur Edge est compatible avec le protocole TLSv1.2. Cela signifie que les protocoles correspondent entre l'application cliente et le routeur Edge.

     • Toutefois, le routeur Edge envoie toujours l'alerte fatale : échec de l'établissement de la liaison à l'application cliente, comme indiqué dans la capture d'écran ci-dessous :

       

   • L'erreur peut être due à l'un des problèmes suivants :
     • L'application cliente n'utilise pas les algorithmes de suite de chiffrement compatibles avec le routeur Edge.
     • Le routeur Edge est compatible avec SNI, mais l'application cliente n'envoie pas le nom du serveur.
   • Le message 4 de la sortie tcpdump liste les algorithmes de la suite de chiffrement compatibles avec l'application cliente, comme indiqué ci-dessous :

     

   • La liste des algorithmes de suite de chiffrement compatibles avec le routeur Edge est disponible dans le fichier /opt/nginx/conf.d/0-default.conf. Dans cet exemple, le routeur Edge ne prend en charge que les algorithmes de la suite de chiffrement à chiffrement élevé.
   • L'application cliente n'utilise aucun des algorithmes de la suite de chiffrement High Encryption. Cette incohérence est à l'origine de l'échec du handshake TLS/SSL.
   • Étant donné que le routeur Edge est compatible avec SNI, faites défiler la sortie tcpdump jusqu'au message 4 et vérifiez que l'application cliente envoie correctement le nom du serveur, comme illustré dans la figure ci-dessous :
     
     
     
   • Si ce nom est valide, vous pouvez en déduire que l'échec de l'établissement de liaison TLS/SSL s'est produit parce que les algorithmes de la suite de chiffrement utilisés par l'application cliente ne sont pas compatibles avec le routeur Edge.

Solution

Vous devez vous assurer que le client utilise les algorithmes de la suite de chiffrement compatibles avec le serveur. Pour résoudre le problème décrit dans la section "Diagnostic" précédente, téléchargez et installez le package Java Cryptography Extension (JCE), puis incluez-le dans l'installation Java pour prendre en charge les algorithmes de la suite de chiffrement High Encryption.

Certificat incorrect

Un échec de handshake TLS/SSL se produit si vous avez des certificats incorrects dans le keystore/truststore, que ce soit au niveau de la connexion entrante (northbound) ou sortante (southbound) dans Apigee Edge. Consultez également Comprendre les connexions Northbound et Southbound.

Si le problème est northbound, différents messages d'erreur peuvent s'afficher selon la cause sous-jacente.

Les sections suivantes listent des exemples de messages d'erreur et les étapes à suivre pour diagnostiquer et résoudre ce problème.

Messages d'erreur

Vous pouvez voir différents messages d'erreur selon la cause de l'échec du handshake TLS/SSL. Voici un exemple de message d'erreur que vous pouvez rencontrer lorsque vous appelez un proxy d'API :

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

Causes possibles

Voici les causes typiques de ce problème :

Non-concordance du nom d'hôte

Diagnostic

1. Notez le nom d'hôte utilisé dans l'URL renvoyée par l'appel d'API Management Edge suivant :

   curl -v https://myorg.domain.com/v1/getinfo

   Par exemple :

   curl -v https://api.enterprise.apigee.com/v1/getinfo

2. Obtenez le CN utilisé dans le certificat stocké dans le keystore spécifique. Vous pouvez utiliser les API de gestion Edge suivantes pour obtenir les détails du certificat :
   1. Obtenez le nom du certificat dans le keystore :
      
      Si vous êtes un utilisateur Private Cloud, utilisez l'API Management comme suit :
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      Si vous êtes un utilisateur du cloud public, utilisez l'API Management comme suit :
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Obtenez les détails du certificat dans le keystore à l'aide de l'API de gestion Edge.
      
      Si vous êtes un utilisateur Private Cloud :
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

       Si vous êtes un utilisateur du cloud public :
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

      Exemple de certificat :

      "certInfo": [
          {
            "basicConstraints": "CA:FALSE",
            "expiryDate": 1456258950000,
            "isValid": "No",
            "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
            "publicKey": "RSA Public Key, 2048 bits",
            "serialNumber": "07:bc:a7:39:03:f1:56",
            "sigAlgName": "SHA1withRSA",
            "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
            "validFrom": 1358287055000,
            "version": 3
          },

      Le nom de l'objet du certificat principal a le CN something.domain.com..

      Étant donné que le nom d'hôte utilisé dans l'URL de la requête API (voir l'étape 1 ci-dessus) et le nom du sujet dans le certificat ne correspondent pas, vous obtenez un échec de l'établissement de liaison TLS/SSL.

Solution

Vous pouvez résoudre ce problème de l'une des deux manières suivantes :

• Obtenez un certificat (si vous n'en avez pas déjà un) où le CN du sujet comporte un certificat générique, puis importez la nouvelle chaîne de certificats complète dans le keystore. Exemple :

  "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",

• Obtenez un certificat (si vous n'en avez pas déjà un) avec un CN de sujet existant, mais utilisez your-org.your-domain comme autre nom de l'objet, puis importez la chaîne de certificats complète dans le keystore.

Références

Keystores et truststores

Chaîne de certificats incomplète ou incorrecte

Diagnostic

1. Obtenez le CN utilisé dans le certificat stocké dans le keystore spécifique. Vous pouvez utiliser les API de gestion Edge suivantes pour obtenir les détails du certificat :
   1. Obtenez le nom du certificat dans le keystore :
      
      Si vous êtes un utilisateur Private Cloud :
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

       Si vous êtes un utilisateur du cloud public :
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
      

   2. Obtenez les détails du certificat dans le keystore :
      
      Si vous êtes un utilisateur Private Cloud :
      

      curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

       Si vous êtes un utilisateur du cloud public :
      

      curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
      

   3. Validez le certificat et sa chaîne, et vérifiez qu'ils respectent les consignes fournies dans l'article Fonctionnement des chaînes de certificats pour vous assurer qu'il s'agit d'une chaîne de certificats valide et complète. Si la chaîne de certificats stockée dans le keystore est incomplète ou non valide, l'échec du handshake TLS/SSL s'affiche.
   4. Le graphique suivant montre un exemple de certificat avec une chaîne de certificats non valide, où les certificats intermédiaires et racine ne correspondent pas :

   Exemple de certificat intermédiaire et racine où l'émetteur et le sujet ne correspondent pas

   
   

Solution

1. Obtenez un certificat (si vous n'en avez pas déjà un) qui inclut une chaîne de certificats complète et valide.
2. Exécutez la commande openssl suivante pour vérifier que la chaîne de certificats est correcte et complète :

   openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

3. Importez la chaîne de certificats validée dans le keystore.

Certificat expiré ou inconnu envoyé par le serveur ou le client

Si un certificat incorrect/expiré est envoyé par le serveur/client au niveau de la connexion Northbound ou Southbound, l'autre extrémité (serveur/client) rejette le certificat, ce qui entraîne un échec du handshake TLS/SSL.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Northbound ou Southbound. Pour obtenir plus d'informations sur la façon de déterminer la source du problème, consultez Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir plus d'informations :
   • Si vous êtes un utilisateur de Private Cloud, vous pouvez collecter les données tcpdump au niveau du client ou du serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou nord) ou le processeur de messages (pour les connexions sortantes ou sud). Un serveur peut être le routeur Edge (pour les connexions entrantes ou nord) ou le serveur backend (pour les connexions sortantes ou sud) en fonction de votre détermination à l'étape 1.
   • Si vous êtes un utilisateur du cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou nord) ou sur le serveur de backend (pour les connexions sortantes ou sud), car vous n'avez pas accès au routeur Edge ni au processeur de messages.

   tcpdump -i any -s 0 host IP address -w File name
   

   Pour en savoir plus sur l'utilisation de la commande tcpdump, consultez les données tcpdump.
3. Analysez les données tcpdump à l'aide de Wireshark ou d'un outil similaire.
4. À partir du résultat tcpdump, identifiez l'hôte (client ou serveur) qui refuse le certificat lors de l'étape de validation.
5. Vous pouvez récupérer le certificat envoyé par l'autre partie à partir de la sortie tcpdump, à condition que les données ne soient pas chiffrées. Cela sera utile pour comparer si ce certificat correspond à celui disponible dans le truststore.
6. Examinez l'exemple tcpdump pour la communication SSL entre le processeur de messages et le serveur de backend.

   Exemple de tcpdump affichant l'erreur "Certificat inconnu"

   
   

   1. Le processeur de messages (client) envoie "Client Hello" au serveur de backend (serveur) dans le message 59.
   2. Le serveur de backend envoie "Server Hello" au processeur de messages dans le message 61.
   3. Elles valident mutuellement les algorithmes de protocole et de suite de chiffrement utilisés.
   4. Le serveur de backend envoie le certificat et le message "Server Hello Done" au processeur de messages dans le message n° 68.
   5. Le processeur de messages envoie l'alerte fatale Description : certificat inconnu dans le message 70.
   6. En examinant plus en détail le message 70, nous n'avons trouvé aucune information supplémentaire en dehors du message d'alerte indiqué ci-dessous :

      
      

   7. Consultez le message 68 pour obtenir des informations sur le certificat envoyé par le serveur backend, comme illustré dans le graphique suivant :

      

   8. Le certificat du serveur de backend et sa chaîne complète sont tous disponibles dans la section "Certificats", comme illustré dans la figure ci-dessus.
7. Si le routeur (vers le nord) ou le processeur de messages (vers le sud) considèrent le certificat comme inconnu, comme dans l'exemple ci-dessus, procédez comme suit :
   1. Obtenez le certificat et sa chaîne stockés dans le truststore spécifique. (Consultez la configuration de l'hôte virtuel pour le routeur et la configuration du point de terminaison cible pour le processeur de messages.) Vous pouvez utiliser les API suivantes pour obtenir les détails du certificat :
      1. Obtenez le nom du certificat dans le truststore :

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs

      2. Obtenez les détails du certificat dans le truststore :

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name

   2. Vérifiez si le certificat stocké dans le truststore du routeur (vers le nord) ou du processeur de messages (vers le sud) correspond à celui stocké dans le keystore de l'application cliente (vers le nord) ou du serveur cible (vers le sud), ou à celui obtenu à partir de la sortie tcpdump. Si ce n'est pas le cas, il s'agit de la cause de l'échec du handshake TLS/SSL.
8. Si le certificat est inconnu de l'application cliente (vers le nord) ou du serveur cible (vers le sud), procédez comme suit :
   1. Obtenez la chaîne de certificats complète utilisée dans le certificat stocké dans le keystore spécifique. (Consultez la configuration de l'hôte virtuel pour le routeur et la configuration du point de terminaison cible pour le processeur de messages.) Vous pouvez utiliser les API suivantes pour obtenir les détails du certificat :
      1. Obtenez le nom du certificat dans le keystore :

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

      2. Obtenez les détails du certificat dans le keystore :
         

         curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
         

   2. Vérifiez si le certificat stocké dans le keystore du routeur (vers le nord) ou du processeur de messages (vers le sud) correspond à celui stocké dans le truststore de l'application cliente (vers le nord) ou du serveur cible (vers le sud), ou à celui obtenu à partir de la sortie tcpdump. Si ce n'est pas le cas, il s'agit de la cause de l'échec de l'établissement de la liaison SSL.
9. Si le certificat envoyé par un serveur/client est expiré, le client/serveur destinataire le refuse et le message d'alerte suivant s'affiche dans tcpdump :

   Alerte (niveau : fatal, description : certificat expiré)

10. Vérifiez que le certificat du keystore de l'hôte concerné a expiré.

Solution

Pour résoudre le problème identifié dans l'exemple ci-dessus, importez le certificat valide du serveur backend dans le truststore du processeur de messages.

Le tableau suivant récapitule les étapes à suivre pour résoudre le problème en fonction de sa cause.

Serveur SNI activé

L'échec du handshake TLS/SSL peut se produire lorsque le client communique avec un serveur SNI (Server Name Indication) activé, mais que le client n'est pas activé pour SNI. Cela peut se produire au niveau de la connexion Northbound ou Southbound dans Edge.

Vous devez d'abord identifier le nom d'hôte et le numéro de port du serveur utilisé, puis vérifier s'il est compatible avec SNI ou non.

Identification d'un serveur compatible avec SNI

1. Exécutez la commande openssl et essayez de vous connecter au nom d'hôte du serveur concerné (routeur Edge ou serveur de backend) sans transmettre le nom du serveur, comme indiqué ci-dessous :

   openssl s_client -connect hostname:port

   Vous pouvez obtenir les certificats et parfois observer l'échec de l'établissement de liaison dans la commande openssl, comme indiqué ci-dessous :
   

   CONNECTED(00000003)
   9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

2. Exécutez la commande openssl et essayez de vous connecter au nom d'hôte du serveur concerné (routeur Edge ou serveur de backend) en transmettant le nom du serveur, comme indiqué ci-dessous :

   openssl s_client -connect hostname:port -servername hostname

3. Si vous obtenez un échec de handshake à l'étape 1 ou des certificats différents à l'étape 1 et à l'étape 2, cela indique que le serveur spécifié est compatible avec SNI.

Une fois que vous avez identifié que le serveur est compatible avec SNI, vous pouvez suivre les étapes ci-dessous pour vérifier si l'échec du handshake TLS/SSL est dû au fait que le client ne parvient pas à communiquer avec le serveur SNI.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Northbound ou Southbound. Pour obtenir plus d'informations sur la façon de déterminer la source du problème, consultez Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir plus d'informations :
   • Si vous êtes un utilisateur de Private Cloud, vous pouvez collecter les données tcpdump au niveau du client ou du serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou nord) ou le processeur de messages (pour les connexions sortantes ou sud). Un serveur peut être le routeur Edge (pour les connexions entrantes ou nord) ou le serveur backend (pour les connexions sortantes ou sud) en fonction de votre détermination à l'étape 1.
   • Si vous êtes un utilisateur du cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou nord) ou sur le serveur de backend (pour les connexions sortantes ou sud), car vous n'avez pas accès au routeur Edge ni au processeur de messages.

   tcpdump -i any -s 0 host IP address -w File name
   

   Pour en savoir plus sur l'utilisation de la commande tcpdump, consultez les données tcpdump.
3. Analysez la sortie tcpdump à l'aide de Wireshark ou d'un outil similaire.
4. Voici un exemple d'analyse de tcpdump à l'aide de Wireshark :
   1. Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre le processeur de messages Edge et le serveur de backend (connexion sortante).
   2. Le message #4 dans la sortie tcpdump ci-dessous indique que le processeur de messages (source) a envoyé un message "Client Hello" au serveur backend (destination).

      

   3. La sélection du message "Client Hello" montre que le processeur de messages utilise le protocole TLSv1.2.

      

   4. Le message 4 indique que le serveur backend accuse réception du message "Client Hello" du processeur de messages.
   5. Le serveur backend envoie immédiatement une alerte fatale : échec du handshake au processeur de messages (message 5). Cela signifie que le handshake TLS/SSL a échoué et que la connexion sera fermée.
   6. Consultez le message 6 pour découvrir les informations suivantes :
      • Le serveur de backend est compatible avec le protocole TLSv1.2. Cela signifie que le protocole correspond entre le processeur de messages et le serveur de backend.
      • Toutefois, le serveur de backend envoie toujours l'alerte fatale : échec de l'établissement de la liaison au processeur de messages, comme illustré dans la figure ci-dessous :

        

   7. Cette erreur peut se produire pour l'une des raisons suivantes :
      • Le processeur de messages n'utilise pas les algorithmes de suite de chiffrement compatibles avec le serveur de backend.
      • Le serveur de backend est compatible avec SNI, mais l'application cliente n'envoie pas le nom du serveur.
   8. Examinez plus en détail le message 3 (Client Hello) dans le résultat tcpdump. Notez que l'Extension: server_name est manquante, comme indiqué ci-dessous :

      

   9. Cela confirme que le processeur de messages n'a pas envoyé server_name au serveur backend compatible avec SNI.
   10. C'est la cause de l'échec du handshake TLS/SSL et la raison pour laquelle le serveur de backend envoie l'alerte fatale : échec du handshake au processeur de messages.
5. Vérifiez que jsse.enableSNIExtension property dans system.properties est défini sur "false" sur le processeur de messages pour confirmer que le processeur de messages n'est pas activé pour communiquer avec le serveur compatible SNI.

Solution

Pour permettre aux processeurs de messages de communiquer avec les serveurs compatibles SNI, procédez comme suit :

1. Créez le fichier/opt/apigee/customer/application/message-processor.properties (s'il n'existe pas déjà).
2. Ajoutez la ligne suivante à ce fichier : conf_system_jsse.enableSNIExtension=true
3. Définissez apigee:apigee comme propriétaire de ce fichier :

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Redémarrez le processeur de messages.

   /opt/apigee/apigee-service/bin/apigee-service message-processor restart

5. Si vous avez plusieurs processeurs de messages, répétez les étapes 1 à 4 sur tous les processeurs de messages.

Si vous ne parvenez pas à déterminer la cause de l'échec de l'établissement de liaison TLS/SSL et à résoudre le problème, ou si vous avez besoin d'aide, contactez l'assistance Apigee Edge. Partagez tous les détails du problème, ainsi que la sortie tcpdump.