Échecs de handshake TLS/SSL

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

Un échec du handshake TLS/SSL se produit lorsqu'un client et un serveur ne parviennent pas à communiquer à l'aide du protocole TLS/SSL. Lorsque cette erreur se produit dans Apigee Edge, l'application cliente reçoit l'état HTTP 503 avec le message Service non disponible. Cette erreur s'affiche après tout appel d'API où un handshake TLS/SSL a échoué.

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

Le protocole TLS (Transport Layer Security, dont le prédécesseur est SSL) est la technologie de sécurité standard permettant d'établir 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 clés secrètes avec lesquelles il peut communiquer. Au cours de ce processus, le client et le serveur:

1. Mettez-vous d'accord sur 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 réussit, le client et le serveur TLS/SSL se transfèrent des données entre eux 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.

Causes possibles des échecs de handshake TLS/SSL:

Cause	Description	Personnes pouvant effectuer les étapes de dépannage
Non-concordance du protocole	Le protocole utilisé par le client n'est pas pris en charge par le serveur.	Utilisateurs des clouds privés et publics
Incohérence au niveau de la suite de chiffrement	La suite de chiffrement utilisée par le client n'est pas prise en charge par le serveur.	Utilisateurs des clouds privés et publics
Certificat incorrect	Le nom d'hôte de l'URL utilisée par le client ne correspond pas au nom d'hôte du certificat stocké côté serveur.	Utilisateurs des clouds privés et publics
	Une chaîne de certificats incomplète ou non valide est stockée côté client ou serveur.	Utilisateurs des clouds privés et publics
	Un certificat incorrect ou expiré est envoyé par le client au serveur, ou du serveur au client.	Utilisateurs des clouds privés et publics
Serveur SNI activé	L'indication du nom du serveur (SNI, Server Name Indication) est activée sur le serveur backend. Toutefois, le client ne peut pas communiquer avec les serveurs SNI.	Utilisateurs de cloud privé uniquement

Non-concordance du protocole

Un échec de handshake TLS/SSL se produit si le protocole utilisé par le client n'est pas pris en charge par le serveur, que ce soit au niveau de la connexion entrante (vers le nord) ou sortante (direction sud). Consultez également la section Comprendre les connexions vers le nord et le sud.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Nord ou Southbound. Pour en savoir plus sur la prise de décision, consultez la section Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir des informations supplémentaires :
   • Si vous êtes un utilisateur du cloud privé, vous pouvez collecter les données tcpdump sur le client ou le serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou les connexions vers le nord) ou le processeur de messages (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur périphérique (pour les connexions entrantes ou liées au nord) ou le serveur backend (pour les connexions sortantes ou celles liées au sud) en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou vers le nord) ou sur le serveur backend (pour les connexions sortantes ou liées au 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
   

   Consultez les données de 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 d'un outil similaire.
4. Voici un exemple d'analyse de tcpdump avec Wireshark :
   • Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre le processeur de messages et le serveur backend (la connexion sortante ou orientée sud).
   • Le message n° 4 dans 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 indiqué ci-dessous:

     

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

   • En examinant plus en détail le message n° 6, vous constaterez que la cause de l'échec du handshake TLS/SSL est que le serveur backend n'accepte que le protocole TLSv1.0, comme indiqué ci-dessous:

     

   • En raison d'une incohérence entre le protocole utilisé par le processeur de messages et le serveur backend, le serveur backend a envoyé le message suivant: Fatal Alert Message: Close Notifier.

Résolution

Il s'exécute sous Java 8 et utilise le protocole TLS v1.2 par défaut. Si le serveur backend n'est pas compatible avec le protocole TLS v1.2, vous pouvez effectuer l'une des opérations suivantes pour résoudre le problème:

1. Mettez à niveau votre serveur backend pour qu'il accepte le protocole TLSv1.2. Cette solution est 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 backend immédiatement, vous pouvez forcer le processeur de messages à utiliser le protocole TLS v1.0 pour communiquer avec le serveur backend. Pour ce faire, procédez 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 de gestion pour définir le protocole sur TLSv1.0 dans la configuration spécifique du serveur cible.

Cipher Non-concordance

Vous pouvez constater un échec du handshake TLS/SSL si l'algorithme de la suite de chiffrement utilisé par le client n'est pas pris en charge par le serveur, que ce soit au niveau de la connexion entrante (vers le nord) ou sortante (vers le sud) dans Apigee Edge. Consultez également la section Comprendre les connexions vers le nord et le sud.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Nord ou Southbound. Pour en savoir plus sur la définition du problème, consultez la section Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir des informations supplémentaires :
   • Si vous êtes un utilisateur du cloud privé, vous pouvez collecter les données tcpdump sur le client ou le serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou les connexions vers le nord) ou le processeur de messages (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur périphérique (pour les connexions entrantes ou liées au nord) ou le serveur backend (pour les connexions sortantes ou celles liées au sud) en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou vers le nord) ou sur le serveur backend (pour les connexions sortantes ou liées au 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
   

   Consultez les données de 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 de tout autre outil que vous connaissez.
4. Voici l'exemple d'analyse de la sortie tcpdump avec Wireshark :
   • Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre l'application cliente et le routeur Edge (connexion au nord). La sortie tcpdump a été collectée sur le routeur Edge.

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

     

   • Si vous sélectionnez le message "Client Hello", l'application cliente utilise le protocole TLSv1.2.

     

   • Le message n° 5 indique que le routeur Edge accuse 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 n° 6). Cela signifie que le handshake TLS/SSL a échoué et que la connexion va être fermée.
   • En examinant plus en détail le message 6, vous obtenez les informations suivantes :
     • Edge Router 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: échec du handshake à l'application cliente, comme illustré 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 Edge Router.
     • Le routeur périphérique est compatible SNI, mais l'application cliente n'envoie pas le nom du serveur.
   • Le message 4 de la sortie tcpdump répertorie les algorithmes de suite de chiffrement compatibles avec l'application cliente, comme indiqué ci-dessous:

     

   • La liste des algorithmes de suite de chiffrement compatibles avec Edge Router est indiquée dans le fichier /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 non-concordance est la cause de l'échec du handshake TLS/SSL.
   • Comme Edge Router est compatible SNI, faites défiler la page jusqu'au message 4 dans la sortie tcpdump 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 du handshake TLS/SSL s'est produit, car les algorithmes de suite de chiffrement utilisés par l'application cliente ne sont pas compatibles avec le routeur Edge.

Résolution

Vous devez vous assurer que le client utilise les algorithmes de 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 afin de prendre en charge les algorithmes de suite de chiffrement à haut chiffrement.

Certificat incorrect

Un échec de handshake TLS/SSL se produit si vous avez des certificats incorrects dans le keystore ou le magasin de confiance, soit au niveau de la connexion entrante (vers le nord) ou sortante (directe sud) dans Apigee Edge. Consultez également la section Comprendre les connexions vers le nord et le sud.

Si le problème se situe vers le nord, des messages d'erreur différents peuvent s'afficher en fonction de la cause sous-jacente.

Les sections suivantes répertorient des exemples de messages d'erreur et la procédure à suivre pour diagnostiquer et résoudre ce problème.

Messages d'erreur

Des messages d'erreur différents peuvent s'afficher en fonction de la cause de l'échec du handshake TLS/SSL. Voici un exemple de message d'erreur pouvant 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

Causes courantes de ce problème:

Cause	Description	Personnes pouvant effectuer les étapes de dépannage
Nom d'hôte incohérent	Le nom d'hôte utilisé dans l'URL et le certificat du keystore du routeur ne correspondent pas. Par exemple, une non-concordance se produit si le nom d'hôte utilisé dans l'URL est myorg.domain.com alors que le nom d'hôte du certificat est CN=something.domain.com. dans son nom.	Utilisateurs de cloud privé et public Edge
Chaîne de certificats incomplète ou incorrecte	La chaîne de certificats est incomplète ou incorrecte.	Utilisateurs de cloud privé et public Edge uniquement
Certificat expiré ou inconnu envoyé par le serveur ou le client	Un certificat expiré ou inconnu est envoyé par le serveur ou le client au niveau de la connexion nord ou sud.	Utilisateurs de cloud privé périphérique et de cloud public de périphérie

Nom d'hôte incohérent

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. 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 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 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 du 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 CN du nom d'objet du certificat principal est 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 de l'objet dans le certificat ne correspondent pas, vous obtenez un échec du handshake TLS/SSL.

Ré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 déjà un) dont le CN d'objet 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 d'objet existant, mais utilisez your-org.your-domain comme nom d'objet alternatif, 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 du 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 de 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, le handshake TLS/SSL échoue.
   4. Le schéma suivant montre un exemple de certificat avec une chaîne de certificats non valide, où les certificats intermédiaire et racine ne correspondent pas:

   Exemple de certificat intermédiaire et racine lorsque l'émetteur et l'objet ne correspondent pas

   
   

Résolution

1. Obtenez un certificat (si vous n'en avez pas encore) 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/arrivé à expiration est envoyé par le serveur/client au niveau de la connexion nord ou sud, l'autre extrémité (serveur/client) le refuse, 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 Nord ou Southbound. Pour en savoir plus sur la prise de décision, consultez la section Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir des informations supplémentaires :
   • Si vous êtes un utilisateur du cloud privé, vous pouvez collecter les données tcpdump sur le client ou le serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou les connexions vers le nord) ou le processeur de messages (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur périphérique (pour les connexions entrantes ou liées au nord) ou le serveur backend (pour les connexions sortantes ou celles liées au sud) en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou vers le nord) ou sur le serveur backend (pour les connexions sortantes ou liées au 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
   

   Consultez les données de tcpdump pour en savoir plus sur l'utilisation de la commande tcpdump.
3. Analysez les données tcpdump à l'aide de Wireshark ou d'un outil similaire.
4. À partir de la sortie tcpdump, identifiez l'hôte (client ou serveur) qui rejette le certificat lors de l'étape de vérification.
5. Vous pouvez récupérer le certificat envoyé par l'autre côté à partir de la sortie tcpdump, à condition que les données ne soient pas chiffrées. Cela permettra de comparer si ce certificat correspond au certificat 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 le message 61.
   3. Ils valident mutuellement le protocole et les algorithmes de suite de chiffrement utilisés.
   4. Le serveur 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: Certificate Unknown" dans le message #70.
   6. En examinant plus en détail le message n° 70, il n'y a pas d'autres détails que le message d'alerte ci-dessous:

      
      

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

      

   8. Le certificat du serveur backend et sa chaîne complète sont tous disponibles dans la section "Certificats ", comme l'illustre la figure ci-dessus.
7. Si le certificat est inconnu du routeur (vers le nord) ou du processeur de messages (direction sud), comme dans l'exemple illustré ci-dessus, procédez comme suit :
   1. Récupérez 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 du 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 magasin de confiance du routeur (Direction Nord) ou du processeur de messages (Direction Sud) correspond au certificat stocké dans le keystore de l'application cliente (vers le nord) ou du serveur cible (Direction Sud), ou à celui obtenu à partir de la sortie tcpdump. En cas de non-concordance, cela est 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 (direction sud), procédez comme suit :
   1. Permet d'obtenir la chaîne complète de certificats utilisée dans le certificat, qui est stocké dans le keystore spécifique. (Reportez-vous à la configuration de l'hôte virtuel pour le routeur et de la configuration du point de terminaison cible du processeur de messages.) Vous pouvez utiliser les API suivantes pour obtenir les détails du certificat :
      1. Récupérez 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 (direction nord) ou du processeur de messages (direction sud) correspond au certificat stocké dans le magasin de confiance de l'application cliente (direction nord) ou du serveur cible (direction sud), ou à celui obtenu à partir de la sortie tcpdump. En cas de non-concordance, c'est la cause de l'échec du handshake SSL.
9. Si le certificat envoyé par un serveur/client a 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 dans le keystore de l'hôte approprié a expiré.

Résolution

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

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

Cause	Description	Solution
Certificat expiré	NorthBound Le certificat stocké dans le keystore du routeur a expiré. Le certificat stocké dans le keystore de l'application cliente a expiré (SSL bidirectionnel).	Importez un nouveau certificat et sa chaîne complète dans le keystore de l'hôte approprié.
	SouthBound Le certificat stocké dans le keystore du serveur cible a expiré. Le certificat stocké dans le keystore du processeur de messages a expiré (SSL bidirectionnel).	Importez un nouveau certificat et sa chaîne complète dans le keystore de l'hôte approprié.
Certificat inconnu	NorthBound Le certificat stocké dans le Truststore de l'application cliente ne correspond pas au certificat du routeur. Le certificat stocké dans le Truststore du routeur ne correspond pas au certificat de l'application cliente (SSL à double sens).	Importez le certificat valide dans le Truststore sur l'hôte approprié.
	SouthBound Le certificat stocké dans le Truststore du serveur cible ne correspond pas au certificat du processeur de messages. Le certificat stocké dans le Truststore du processeur de messages ne correspond pas au certificat du serveur cible (SSL bidirectionnel).	Importez le certificat valide dans le Truststore sur l'hôte approprié.

Serveur SNI activé

L'échec du handshake TLS/SSL peut se produire lorsque le client communique avec un serveur sur lequel l'indication du nom de serveur (SNI) est activée, mais que le client n'est pas activé. Cela peut se produire au niveau de la connexion nord ou 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 s'ils sont activés ou non.

Identification du serveur compatible SNI

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

   openssl s_client -connect hostname:port
   

   Il se peut que vous obteniez les certificats et que, dans certains cas, vous constatiez un échec du handshake avec 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 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 obtenez un échec de handshake à l'étape 1 ou si vous obtenez des certificats différents aux étapes 1 et 2, cela signifie que l'extension SNI est activée pour le serveur spécifié.

Une fois que vous avez déterminé que le serveur est activé avec l'extension 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 peut pas communiquer avec le serveur SNI.

Diagnostic

1. Déterminez si l'erreur s'est produite au niveau de la connexion Nord ou Southbound. Pour en savoir plus sur la prise de décision, consultez la section Déterminer la source du problème.
2. Exécutez l'utilitaire tcpdump pour recueillir des informations supplémentaires :
   • Si vous êtes un utilisateur du cloud privé, vous pouvez collecter les données tcpdump sur le client ou le serveur concerné. Un client peut être l'application cliente (pour les connexions entrantes ou les connexions vers le nord) ou le processeur de messages (pour les connexions sortantes ou liées au sud). Un serveur peut être le routeur périphérique (pour les connexions entrantes ou liées au nord) ou le serveur backend (pour les connexions sortantes ou celles liées au sud) en fonction de ce que vous avez déterminé à l'étape 1.
   • Si vous êtes un utilisateur de cloud public, vous ne pouvez collecter les données tcpdump que sur l'application cliente (pour les connexions entrantes ou vers le nord) ou sur le serveur backend (pour les connexions sortantes ou liées au 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
   

   Consultez les données de tcpdump pour en savoir plus sur l'utilisation de la commande tcpdump.
3. Analysez la sortie tcpdump à l'aide de Wireshark ou d'un outil similaire.
4. Voici l'exemple d'analyse de tcpdump avec Wireshark :
   1. Dans cet exemple, l'échec du handshake TLS/SSL s'est produit entre le processeur de messages Edge et le serveur backend (connexion Sud).
   2. Le message n° 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" indique que le processeur de messages utilise le protocole TLSv1.2.

      

   4. Le message n° 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 n° 5). Cela signifie que le handshake TLS/SSL a échoué et que la connexion va être fermée.
   6. Examinez le message 6 pour découvrir les informations suivantes :
      • Le serveur backend est compatible avec le protocole TLSv1.2. Cela signifie que le protocole correspond entre le processeur de messages et le serveur backend.
      • Toutefois, le serveur backend envoie toujours l'alerte fatale: échec du handshake 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 backend.
      • L'extension SNI est activée sur le serveur backend, 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 l'extension 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 SNI.
   10. Cela explique l'échec du handshake TLS/SSL et la raison pour laquelle le serveur backend envoie l'erreur Fatal Alert: Handshake Failure (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 celui-ci n'est pas activé pour communiquer avec le serveur sur lequel SNI est activé.

Résolution

Procédez comme suit pour permettre aux processeurs de messages de communiquer avec les serveurs SNI:

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. Possibilité de supprimer le propriétaire de ce fichier en apigee:apigee :

   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 besoin d'une aide supplémentaire, contactez l'assistance Apigee Edge. Partagez des informations complètes sur le problème, ainsi que la sortie tcpdump.