Partager via

Échec de la négociation TLS avec l’erreur NoCredentials si les messages vers des domaines externes sont différés

  • S’applique à: Exchange Online

Numéro de la base de connaissances d’origine : 4495258

Symptômes

Email messages envoyés à des domaines externes sont mis en file d’attente dans des Exchange Server locales (2016 ou 2013). Lorsque vous case activée le status, le message d’erreur suivant s’affiche :

421 4.4.1 La connexion a expiré. » Tentative de basculement vers un autre hôte, mais cela n’a pas réussi. Soit il n’y a pas d’autres hôtes, soit la remise a échoué à tous les autres hôtes.

En outre, l’entrée d’erreur suivante dans les journaux du connecteur d’envoi indique que la négociation TLS (Transport Layer Security) a échoué :

Échec de la négociation TLS avec l’erreur NoCredentials

Cause

Ce problème se produit si les conditions suivantes sont remplies :

  • Il manque une clé privée au certificat utilisé pour le protocole TLS sortant.
  • Vous remplissez l’attribut à l’aide TLSCertificateName des chaînes Issuer et SubjectName du certificat. En outre, l’attribut est utilisé pour le <I>Issuer string<S>SubjectName string protocole TLS sortant dans le connecteur d’envoi afin d’acheminer les messages électroniques vers des domaines externes.

Résolution

Pour résoudre ce problème, procédez comme suit :

  1. Activez la journalisation sur le connecteur d’envoi faisant autorité pour l’envoi de messages électroniques. Pour ce faire, exécutez l’applet de commande PowerShell suivante en tant qu’administrateur :

    Set-SendConnector "NameOfTheSendCconnector" -ProtocolLoggingLevel Verbose

  2. Passez en revue les journaux d’envoi du connecteur pour identifier le certificat utilisé pendant le protocole TLS sortant. Par exemple, l’entrée de journal peut ressembler à ce qui suit :

    Date/Heure.ConnectorId,Sortant vers Office 365,SessionId,16,192.168.0.78 :28252,172.16.38.36 :25,,Certificat d’envoi
    Date/Heure.ConnectorId,Sortant vers Office 365,SessionId,17,192.168.0.78 :28252,172.16.38.36 :25,    ,CN=.xxx.xxx.xxx,Objet du certificat
    Date/Heure.ConnectorId,Sortant vers Office 365,SessionId,18,192.168.0.78 :28252,172.16.38.36 :25,    "CN=xxxxxx, OU=xxxxxx, O=xxxx, L=xxxx, S=xxxxx, C=xx »,Nom de l’émetteur du certificat
    Date/Heure.ConnectorId,Sortant vers Office 365,SessionId,19,192.168.0.78 :28252,172.16.38.36 :25,,xxxxxxxxxxxxxxxxx,Numéro de série du certificat
    Date/Heure.ConnectorId,Outbound to Office 365,SessionId,20,192.168.0.78 :28252,172.16.38.36 :25,    ,xxxxxxxxxxxxxxxxxxxxxxxxxx
    Date/Heure.ConnectorId,Outbound to Office 365,SessionId,21,192.168.0.78 :28252,172.16.38.36 :25,,.xxxx.xxx.xx
    Date/Heure.ConnectorId,Outbound to Office 365,SessionId,22,192.168.0.78 :28252,172.167.38.36 :25,*,,,La négociation TLS a échoué avec l’erreur NoCredentials

  3. Vérifiez le status de la PrivateKey propriété pour le certificat identifié à l’étape 2. Pour ce faire, exécutez l’applet de commande suivante :

    Get-ChildItem -Path Cert:\LocalMachine\My | where {$_.Thumbprint -like 'Certificate thumbprint identified in step 2'} | Select-Object -Property thumbprint,hasprivatekey

  4. Supprimez le certificat identifié à l’étape 2 en exécutant l’applet de commande suivante :

    Get-ChildItem -Path Cert:\LocalMachine\My | where {$_.Thumbprint -like 'Certificate thumbprint identified in step 2'} | remove-item

    Remarque

    Avant de supprimer le certificat identifié à l’étape 2, assurez-vous qu’il n’existe aucune dépendance du certificat vis-à-vis d’une autre application qui s’exécute sur le serveur qui exécute Microsoft Exchange Server. S’il existe une dépendance, apportez les modifications requises dans l’application afin que l’application commence par utiliser le certificat mentionné à l’étape 5.

  5. Importez un certificat tiers valide via le processus d’importation habituel, puis case activée l’status du certificat à partir d’Exchange Management Shell en exécutant l’applet de commande suivante.

    Get-ExchangeCertificate | where {$_.rootca -eq 'third-party certificate'}

    Remarque

    Exchange Management Shell répertorie toujours les certificats qui ont une clé privée valide.

  6. Activez le service SMTP sur le certificat tiers nouvellement importé en exécutant l’applet de commande suivante :

    Enable-Exchangecertificate -thumbprint "Thumbprint of the new certificate" -services SMTP

    Remarque

    Lorsque vous êtes invité à remplacer le certificat existant à l’aide d’un nouveau certificat, tapez Non.

  7. Si le certificat tiers a déjà été importé, Exchange Server commence par utiliser le nouveau certificat tiers.

  8. Exécutez l’applet de commande suivante pour effectuer une nouvelle tentative sur les messages dans la file d’attente.

    Get-queue -resultsize unlimited | where {$_.status -eq 'retry'} | retry-queue