Échecs de handshake TLS/SSL

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

Un échec du handshake TLS/SSL se produit lorsqu'un client et un serveur ne parviennent pas à établir la communication à l'aide de la Protocole TLS/SSL. Lorsque cette erreur se produit dans Apigee Edge, le client reçoit un état HTTP 503 avec le message Service Unavailable. Toi cette erreur s'affiche après tout appel d'API où un échec de handshake TLS/SSL se produit.

Messages d'erreur

HTTP/1.1 503 Service Unavailable

Ce message d'erreur peut également s'afficher en cas d'échec de la négociation TLS/SSL:

Received fatal alert: handshake_failure

Causes possibles

TLS (Transport Layer Security, dont le prédécesseur est SSL) est la technologie de sécurité standard pour établissant une liaison chiffrée entre un serveur Web et un client Web, tel qu’un navigateur ou une application. Un handshake est un processus qui permet au client et au serveur TLS/SSL d'établir un ensemble de codes secrets avec lesquelles ils peuvent communiquer. Au cours de ce processus, le client et le serveur:

1. Convenez de la version du protocole à utiliser.
2. Sélectionnez l'algorithme cryptographique à utiliser.
3. Authentifiez-vous mutuellement en échangeant et en validant des certificats numériques.

Si le handshake TLS/SSL aboutit, le client et le serveur TLS/SSL transfèrent les données vers chacun en toute sécurité. Dans le cas contraire, en cas d'échec de la négociation TLS/SSL, la connexion est interrompue et le client reçoit une erreur 503 Service Unavailable.

Voici les causes possibles de l'échec de la négociation TLS/SSL:

Protocole Non-concordance

Un échec de handshake TLS/SSL se produit si le protocole utilisé par le client n'est pas compatible avec au niveau de la connexion entrante (direction nord) ou sortante (direction Sud). Voir aussi <ph type="x-smartling-placeholder"></ph> Comprendre les connexions liées au nord et au sud

Diagnostic

1. Déterminez si l'erreur s'est produite en direction du nord ou southbound. Pour en savoir plus sur la manière la détermination, voir <ph type="x-smartling-placeholder"></ph> Déterminer la source du problème.
2. Exécutez la <ph type="x-smartling-placeholder"></ph> tcpdump pour recueillir des informations supplémentaires: <ph type="x-smartling-placeholder">
   </ph>
   • Si vous êtes un utilisateur du Private Cloud, vous pouvez collecter le tcpdump des données sur le client ou le serveur approprié. Un client peut être l'application cliente (pour les requêtes entrantes, (connexions en direction du nord) ou le champ Processeur (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur Edge (pour (connexions entrantes ou liées au nord) ou au serveur backend (pour les connexions sortantes ou vers le sud), en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous pouvez collecter le tcpdump les données uniquement sur l'application cliente (pour les connexions entrantes ou liées au nord) ou sur le serveur backend. (pour les connexions sortantes ou de direction sud), car vous n'ont pas accès au routeur Edge ni au processeur de messages.

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

   Voir tcpdump pour en savoir plus sur l'utilisation de tcpdump .
3. Analyser les données tcpdump à l'aide de l'outil Wireshark ou un outil similaire.
4. Voici un exemple d'analyse <ph type="x-smartling-placeholder"></ph> tcpdump à l'aide de Wireshark: <ph type="x-smartling-placeholder">
   </ph>
   • Dans cet exemple, l'échec de la négociation TLS/SSL s'est produit entre le processeur de messages et au serveur backend (la connexion sortante, ou connexion sud).
   • Le message 4 dans la sortie tcpdump ci-dessous montre que le processeur de messages (source) a envoyé une "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 indiqué ci-dessous:

     

   • Le message 5 indique que le serveur backend accuse réception de la commande "Client Hello" message de le processeur de messages.
   • Le serveur backend envoie immédiatement le message Fatal Alert : Close Notifier au Processeur de messages (message n° 6). Cela signifie que le handshake TLS/SSL a échoué et que la connexion être clôturées.

   • Si l'on examine de plus près le message n° 6, on constate que l'échec de la négociation TLS/SSL est dû au fait que Le serveur backend n'est compatible qu'avec le protocole TLSv1.0, comme indiqué ci-dessous:

     

   • Parce qu'il existe une incohérence entre le protocole utilisé par le processeur de messages et le serveur backend, celui-ci a envoyé le message Fatal Alert Message: Close Notifier.

Solution

Le processeur de messages s'exécute sur Java 8 et utilise le protocole TLSv1.2 par défaut. Si le backend n'est pas compatible avec le protocole TLSv1.2, vous pouvez suivre l'une des étapes ci-dessous pour résoudre ce problème:

1. Mettez à niveau votre serveur backend pour qu'il soit compatible avec le protocole TLSv1.2. Il s'agit d'une solution recommandée, le protocole TLSv1.2 est plus sécurisé.
2. Si, pour une raison quelconque, vous ne parvenez pas à mettre à niveau votre serveur backend immédiatement, vous pouvez forcer le processeur de messages à utiliser le protocole TLSv1.0 pour communiquer avec le serveur backend en procédant comme suit: <ph type="x-smartling-placeholder">
   </ph>
   1. Si vous n'avez pas spécifié de serveur cible dans la définition du point de terminaison 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 <ph type="x-smartling-placeholder"></ph> le serveur cible de votre proxy, puis utilisez <ph type="x-smartling-placeholder"></ph> cette API de gestion pour définir le protocole sur TLSv1.0 dans le la configuration du serveur cible.

Différence de chiffrement

Vous pouvez voir un échec de handshake TLS/SSL si l'algorithme de la suite de chiffrement utilisé par le client n'est pas pris en charge par le serveur au niveau de la connexion entrante (direction nord) ou sortante (direction sud) dans Apigee Edge. Voir aussi Comprendre les connexions liées au nord et au sud

Diagnostic

1. Déterminez si l'erreur s'est produite la connexion Nord (Nord) ou southbound (Sud). Pour en savoir plus sur la prise de décision, consultez Déterminer la source du problème.
2. Exécutez la <ph type="x-smartling-placeholder"></ph> tcpdump pour recueillir des informations supplémentaires: <ph type="x-smartling-placeholder">
   </ph>
   • Si vous êtes un utilisateur du Private Cloud, vous pouvez collecter le tcpdump des données sur le client ou le serveur approprié. Un client peut être l'application cliente (pour les requêtes entrantes, (connexions en direction du nord) ou le champ Processeur (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur Edge (pour (connexions entrantes ou liées au nord) ou au serveur backend (pour les connexions sortantes ou vers le sud), en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous pouvez collecter le tcpdump les données uniquement sur l'application cliente (pour les connexions entrantes ou liées au nord) ou sur le serveur backend. (pour les connexions sortantes ou de direction sud), car vous n'ont pas accès au routeur Edge ni au processeur de messages.

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

   Voir tcpdump pour en savoir plus sur l'utilisation de la commande tcpdump.
3. Analysez les données tcpdump à l'aide de l'outil Wireshark. ou tout autre outil que vous connaissez.
4. Voici un exemple d'analyse de la sortie tcpdump avec Wireshark: <ph type="x-smartling-placeholder">
   </ph>
   • Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre l'application cliente et Routeur périphérique (connexion nord). La sortie tcpdump a été collectée sur l'Edge le routeur.

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

     

   • Si vous sélectionnez le message "Client Hello", vous indiquez que l'application cliente utilise TLS v1.2.

     

   • Le message n° 5 indique que le routeur Edge accuse réception de la demande "Client Hello" message de l'application cliente.
   • Le routeur Edge envoie immédiatement une alerte fatale : échec de handshake au l'application cliente (message n° 6). Cela signifie que le handshake TLS/SSL a échoué et que la connexion sera fermé.
   • Si l'on examine de plus près le message n° 6, on retrouve les informations suivantes: <ph type="x-smartling-placeholder">
     </ph>
     • Le routeur Edge est compatible avec le protocole TLSv1.2. Cela signifie que le protocole correspond entre l'application cliente et le routeur Edge.

     • Cependant, le routeur Edge envoie toujours l'alerte fatale: handshake Échec de l'application cliente, comme illustré dans la capture d'écran ci-dessous:

       

   • L'erreur peut être due à l'un des problèmes suivants: <ph type="x-smartling-placeholder">
     </ph>
     • L'application cliente n'utilise pas les algorithmes de la suite de chiffrement pris en charge par Edge Router.
     • Le routeur Edge est compatible SNI, mais l'application cliente n'envoie pas la nom du serveur.
   • Le message 4 dans la sortie tcpdump liste les algorithmes de la suite de chiffrement pris en charge par le client application, comme indiqué ci-dessous:

     

   • La liste des algorithmes de suite de chiffrement compatibles avec Edge Router est indiquée dans le /opt/nginx/conf.d/0-default.conf. Dans cet exemple, le routeur Edge n'est compatible qu'avec les algorithmes de la suite de chiffrement High Encryption.
   • L'application cliente n'utilise aucun des algorithmes de la suite de chiffrement High Encryption. Cette incohérence est à l'origine du Échec du handshake TLS/SSL.
   • Comme le routeur Edge est compatible SNI, faites défiler la page jusqu'au message n°4 dans la sortie tcpdump et vérifiez que l'application cliente envoie correctement le nom du serveur, comme indiqué dans figure ci-dessous:
     
     
     
   • Si ce nom est valide, vous pouvez en déduire que l'échec du handshake TLS/SSL s'est produite, car 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 prises en charge par le serveur. Pour résoudre le problème décrit dans la "Diagnostic", téléchargez et installez <ph type="x-smartling-placeholder"></ph> Java Cryptography Extension (JCE) et l'inclure dans le fichier 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, au niveau de la connexion entrante (direction nord) ou sortante (direction Sud) dans Apigee Edge. Voir aussi <ph type="x-smartling-placeholder"></ph> Comprendre les connexions liées au nord et au sud

Si le problème se trouve en direction du nord, différents messages d'erreur peuvent s'afficher. selon la cause sous-jacente.

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

Messages d'erreur

Vous pouvez voir des messages d'erreur différents en fonction de la cause de l'échec du handshake TLS/SSL. Voici un exemple de message d'erreur qui peut s'afficher 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

Les causes courantes de ce problème sont les suivantes:

Nom d'hôte Non-concordance

Diagnostic

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

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

   Par exemple:

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

2. Récupérez le CN utilisé dans le certificat stocké dans le keystore spécifique. Vous pouvez utiliser API de gestion Edge suivantes pour obtenir les détails du certificat: <ph type="x-smartling-placeholder">
   </ph>
   1. <ph type="x-smartling-placeholder"></ph> Obtenez le nom du certificat dans le keystore:
      
      Si vous êtes un utilisateur du 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 de 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. <ph type="x-smartling-placeholder"></ph> 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 de 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 sujet du certificat principal a le CN suivant : 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 l'objet dans le certificat ne correspondent pas, vous obtenez l'échec du handshake TLS/SSL.

Solution

Ce problème peut être résolu de l'une des deux manières suivantes:

• Obtenez un certificat (si vous n'en avez pas encore) dans lequel le CN de l'objet contient un caractère générique. certificat, 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 encore) avec un CN d'objet existant, mais utilisez your-orgyour-domain comme nom d'objet alternatif, puis importez le fichier au keystore.

Références

Keystores et Truststores

Chaîne de certificats incomplète ou incorrecte

Diagnostic

1. Récupérez le CN utilisé dans le certificat stocké dans le keystore spécifique. Vous pouvez utiliser API de gestion Edge suivantes pour obtenir les détails du certificat: <ph type="x-smartling-placeholder">
   </ph>
   1. <ph type="x-smartling-placeholder"></ph> 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 de cloud public:
      

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

   2. <ph type="x-smartling-placeholder"></ph> Récupérez 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 de cloud public:
      

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

   3. Valider le certificat et sa chaîne et vérifier qu'ils adhèrent aux consignes fournies dans l'article <ph type="x-smartling-placeholder"></ph> comment fonctionnent les chaînes de certificats pour s'assurer qu'elles sont la chaîne de certificats. Si la chaîne de certificats stockée dans le keystore est incomplètes ou non valides, le handshake TLS/SSL s'affiche l'échec.
   4. Le graphique suivant montre un exemple de certificat avec une chaîne de certificats non valide, où les certificats intermédiaires et racines ne correspondent pas:

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

   
   

Solution

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

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

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

Expirée ou inconnue certificat envoyé par le serveur ou le client

Si un certificat incorrect/arrivé à expiration est envoyé par le serveur/client vers le nord ou au niveau de la connexion Sud, alors l'autre extrémité (serveur/client) rejette le certificat ce qui entraîne l'échec du handshake TLS/SSL.

Diagnostic

1. Déterminez si l'erreur s'est produite en direction du nord ou southbound. Pour en savoir plus sur la manière la détermination, voir <ph type="x-smartling-placeholder"></ph> Déterminer la source du problème.
2. Exécutez la <ph type="x-smartling-placeholder"></ph> tcpdump pour recueillir des informations supplémentaires: <ph type="x-smartling-placeholder">
   </ph>
   • Si vous êtes un utilisateur du Private Cloud, vous pouvez collecter le tcpdump des données sur le client ou le serveur approprié. Un client peut être l'application cliente (pour les requêtes entrantes, (connexions en direction du nord) ou le champ Processeur (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur Edge (pour (connexions entrantes ou liées au nord) ou au serveur backend (pour les connexions sortantes ou vers le sud), en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous pouvez collecter le tcpdump les données uniquement sur l'application cliente (pour les connexions entrantes ou liées au nord) ou sur le serveur backend. (pour les connexions sortantes ou de direction sud), car vous n'ont pas accès au routeur Edge ni au processeur de messages.

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

   Voir tcpdump pour en savoir plus sur l'utilisation de la commande tcpdump.
3. Analyser les données tcpdump à l'aide de Wireshark ou d'un un outil similaire.
4. À partir de la sortie tcpdump, déterminez l'hôte (client ou serveur) qui refuse la lors de l'étape de vérification.
5. Vous pouvez récupérer le certificat envoyé par l'autre extrémité à partir de la sortie tcpdump, à condition que le les données ne sont pas chiffrées. Il vous sera utile de comparer si ce certificat correspond au certificat est disponible dans le truststore.
6. Examinez l'exemple tcpdump pour la communication SSL entre le processeur de messages et le serveur backend.

   Exemple tcpdump affichant une erreur de certificat inconnu

   
   

   1. Le processeur de messages (client) envoie "Client Hello" au serveur backend (serveur) dans le message n°59.
   2. Le serveur backend envoie "Server Hello" au processeur de messages dans un message N° 61.
   3. Ils valident mutuellement le protocole et les algorithmes de la suite de chiffrement utilisés.
   4. Le serveur backend envoie le certificat et le message "Hello Done" au serveur Processeur de messages dans le message #68.
   5. Le processeur de messages envoie l'alerte fatale "Description: Certificate Inconnu" dans le message 70.
   6. Nous n'avons pas d'autres détails concernant le message n° 70. que le message d'alerte ci-dessous:

      
      

   7. Consultez le message n° 68 pour obtenir des informations sur le certificat envoyé par le backend. comme illustré ci-dessous:

      

   8. Le certificat du serveur backend et sa chaîne complète sont tous disponibles sous la rubrique "Certificats" , comme illustré dans la figure ci-dessus.
7. Si le certificat est inconnu du routeur (en direction du nord) ou du comme dans l'exemple illustré ci-dessus, le processeur de messages (direction sud), puis suivez ces étapes: <ph type="x-smartling-placeholder">
   </ph>
   1. Récupérez le certificat et sa chaîne stockés dans le truststore spécifique. (Consultez à la configuration d'hôte virtuel pour la configuration du routeur et du point de terminaison cible pour le processeur de messages). Vous pouvez utiliser les API suivantes pour obtenir des informations certificat: <ph type="x-smartling-placeholder">
      </ph>
      1. <ph type="x-smartling-placeholder"></ph> Récupérez 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. <ph type="x-smartling-placeholder"></ph> Récupérez 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 est stocké dans le Truststore du routeur (en direction du nord) ou Le processeur de messages (direction sud) correspond au certificat stocké dans le keystore de l'application cliente (direction vers le nord) ou du serveur cible (direction Sud), ou la celle obtenue à partir de la sortie tcpdump. S’il y a une non-concordance, cela explique pourquoi l'échec du handshake TLS/SSL.
8. Si le certificat est inconnu par l'application cliente (en direction du nord) ou le serveur cible (direction Sud), puis procédez comme suit: <ph type="x-smartling-placeholder">
   </ph>
   1. Récupérez la chaîne de certificats complète utilisée dans le certificat stocké dans la keystore. Reportez-vous à la configuration de l'hôte virtuel pour le routeur et le point de terminaison cible pour le processeur de messages.) Vous pouvez utiliser les API suivantes pour obtenir détails du certificat: <ph type="x-smartling-placeholder">
      </ph>
      1. <ph type="x-smartling-placeholder"></ph> 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. <ph type="x-smartling-placeholder"></ph> Récupérez 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 (en direction du nord) ou Le processeur de messages (direction sud) correspond au certificat stocké dans le truststore du l'application cliente (direction nord) ou le serveur cible (direction Sud), ou celle qui est obtenu à partir de la sortie tcpdump. S'il y a une non-concordance, c'est la cause du problème échec du handshake.
9. S'il s'avère que le certificat envoyé par un serveur/client a expiré, le certificat le client/serveur rejette le certificat et le message d'alerte suivant apparaît dans tcpdump:

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

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

Solution

Pour résoudre le problème identifié dans l'exemple ci-dessus, importez le fichier certificat au trustore sur le processeur de messages.

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

SNI activé Serveur

L'échec de la négociation TLS/SSL peut se produire lorsque le client communique avec un serveur Indication du nom (SNI) activée serveur, mais l'extension SNI n'est pas activée pour le client. Cela peut se produire dans la direction nord vers le sud dans Edge.

Tout d'abord, vous devez identifier le nom d'hôte et le numéro de port du serveur utilisé, et vérifier si si la SNI est activée ou non.

Identification du serveur compatible avec l'extension SNI

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

   openssl s_client -connect hostname:port
   

   Vous pouvez obtenir les certificats et parfois vous pouvez observer l'échec de la poignée de main dans la commande openssl, comme illustré 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 de serveur approprié. (routeur Edge ou serveur backend) en transmettant le nom du serveur comme indiqué ci-dessous:

   openssl s_client -connect hostname:port -servername hostname
   

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

Une fois que la fonctionnalité SNI est activée sur le serveur, procédez comme suit pour vérifiez si l'échec du handshake TLS/SSL est dû à l'impossibilité de communiquer avec le client au serveur SNI.

Diagnostic

1. Déterminez si l'erreur s'est produite en direction du nord ou southbound. Pour en savoir plus sur la manière la détermination, voir <ph type="x-smartling-placeholder"></ph> Déterminer la source du problème.
2. Exécutez la <ph type="x-smartling-placeholder"></ph> tcpdump pour recueillir des informations supplémentaires: <ph type="x-smartling-placeholder">
   </ph>
   • Si vous êtes un utilisateur du Private Cloud, vous pouvez collecter le tcpdump des données sur le client ou le serveur approprié. Un client peut être l'application cliente (pour les requêtes entrantes, (connexions en direction du nord) ou le champ Processeur (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur Edge (pour (connexions entrantes ou liées au nord) ou au serveur backend (pour les connexions sortantes ou vers le sud), en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous pouvez collecter le tcpdump les données uniquement sur l'application cliente (pour les connexions entrantes ou liées au nord) ou sur le serveur backend. (pour les connexions sortantes ou de direction sud), car vous n'ont pas accès au routeur Edge ni au processeur de messages.

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

   Voir <ph type="x-smartling-placeholder"></ph> tcpdump pour en savoir plus sur l'utilisation de la commande tcpdump.
3. Analyser la sortie tcpdump à l'aide de Wireshark ou d'un un outil similaire.
4. Voici un exemple d'analyse de tcpdump avec Wireshark: <ph type="x-smartling-placeholder">
   </ph>
   1. Dans cet exemple, l'échec de la négociation TLS/SSL s'est produit entre le message périphérique Processeur et serveur backend (connexion sud).
   2. Le message n° 4 dans la sortie tcpdump ci-dessous montre que le processeur de messages (source) a envoyé un "Client Hello" au serveur backend (destination).

      

   3. Sélection de la fenêtre "Client Hello" indique que l'élément Le processeur utilise le protocole TLSv1.2.

      

   4. Le message n° 4 indique que le serveur backend accuse réception de l'événement "Client Hello" message du processeur de messages.
   5. Le serveur backend envoie immédiatement une Alerte fatale : handshake Échec du processeur de messages (message n° 5). Cela signifie que le handshake TLS/SSL a échoué et la connexion sera fermée.
   6. Consultez le message n° 6 pour découvrir les informations suivantes <ph type="x-smartling-placeholder">
      </ph>
      • Le serveur backend est compatible avec le protocole TLSv1.2. Cela signifie que le protocole mis en correspondance entre le processeur de messages et le serveur backend.
      • Cependant, le serveur backend envoie toujours l'alerte Fatal Alert: Handshake Échec du processeur de messages, comme illustré dans la figure ci-dessous:

        

   7. Cette erreur peut se produire pour l'une des raisons suivantes: <ph type="x-smartling-placeholder">
      </ph>
      • Le processeur de messages n'utilise pas les algorithmes de la suite de chiffrement pris en charge par le à un serveur backend.
      • L'extension SNI du serveur backend est activée, mais l'application cliente n'envoie pas le nom du serveur.
   8. Examinez plus en détail le message n° 3 (Client Hello) dans la sortie tcpdump. Notez que Extension: server_name est manquant, comme indiqué ci-dessous:

      

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

Solution

Permettez au(x) processeur(s) de messages de communiquer avec les serveurs compatibles SNI en exécutant la procédez comme suit:

1. Créer le /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. Attribuer la propriété "apigee:apigee" au 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 disposez de 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 du handshake TLS/SSL et à résoudre le problème ou si vous avez encore besoin d'aide, contactez Assistance Apigee Edge Fournissez toutes les informations sur le problème ainsi que la sortie tcpdump.