Início / server / Perguntas / 1022772
Accepted
Caynadian
Asked: 2020-06-25 08:42:18 +0800 CST

Exchange 2016 Server rejeitando certificado como expirado

  • 772

Temos emails enviados usando TLS de um servidor Web Windows 2012R2 (não associado ao domínio) em nossa DMZ para nosso servidor Exchange 2016 interno (também em execução no Windows 2012R2). Isso estava funcionando bem até cerca de um mês atrás, quando eles pararam de chegar (só percebemos agora porque os e-mails são muito raros). Forcei um email de teste e, quando olho os logs do protocolo de função de transporte, vejo o seguinte:

2020-06-24 11:02:33.524,
  MAILSERVER\Client Frontend MAILSERVER,
  0102030405060708,
  6,
  192.168.1.44:587,
  192.168.2.3:64961,
  *,
  " CN=*.example.com CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB     
    0102030405060708090A0B0C0D0E0F10
    0102030405060708090A0B0C0D0E0F1011121314
    2020-03-17T19:00:00.000Z 
    2021-03-18T18:59:59.000Z 
    *.example.com;example.com",
  Sending certificate Subject Issuer name Serial number Thumbprint Not before Not after Subject alternate names

2020-06-24 11:02:33.540,
  MAILSERVER\Client Frontend MAILSERVER,
  0102030405060708,
  7,
  192.168.1.44:587,
  192.168.2.3:64961,
  *,
  ,
  TLS negotiation failed with error CertExpired

Você pode ver que as datas de validade do certificado são de 17 de março de 2020 a 18 de março de 2021.

O lado do cliente mostra o seguinte log de erros:

SERVER -> CLIENT: 220 mailserver.example.com Microsoft ESMTP MAIL Service ready at Wed, 24 Jun 2020 11:02:32 -0500
CLIENT -> SERVER: EHLO www.example.com
250-SIZE 36700160
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
CLIENT -> SERVER: STARTTLS
SERVER -> CLIENT: 220 2.0.0 SMTP server ready
Connection failed. Error #2: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed [E:\...\class-smtp.php line 374]SMTP Error: Could not connect to SMTP host.
CLIENT -> SERVER: QUIT
SERVER -> CLIENT: SMTP ERROR: QUIT command failed: Connection: closedSMTP Error: Could not connect to SMTP host.

O log de eventos no servidor de correio mostra o seguinte evento:

A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 45.
- System 
 - Provider 
     [ Name]  Schannel 
     [ Guid]  {1F678132-5938-4686-9FDC-C8FF68F15C85} 
   EventID 36887 
   Version 0 
   Level 2 
   Task 0 
   Opcode 0 
   Keywords 0x8000000000000000 
 - TimeCreated 
     [ SystemTime]  2020-06-24 11:02:33.540386500
   EventRecordID 417754 
   Correlation 
 - Execution 
     [ ProcessID]  484 
     [ ThreadID]  1552 
   Channel System 
   Computer mailserver.example.com 
 - Security 
     [ UserID]  S-1-5-18 
- EventData 
    AlertDesc 45

Mas, novamente, este evento indica apenas um certificado expirado.

Alguma ideia de por que o Exchange acha que o certificado expirou? Verifiquei a data/hora em ambas as máquinas e elas estão corretas ao segundo. Obrigado!

exchange ssl-certificate exchange-2016

3 respostas

  1. Suas informações não mostram os certificados de cadeia usados ​​- tente openssl s_client -connect $host:$port -servername $host -showcertsexecutar cada um dos blocos PEM resultantes openssl x509 -textou, se preferir, coloque-os em arquivos (separados) e clique duas vezes. (Se o OpenSSL 1.1.1 você não precisar mais do -servername $host.)

    Muitas CAs Comodo^WSectigo usaram uma ponte USERTrust-to-AddTrust que expirou em 30 de maio ; consulte https://security.stackexchange.com/questions/232978/how-to-fully-view-cross-signed-certificate-signatures e https://stackoverflow.com/questions/62107431/curl-error-60-ssl -certificate-problem-certificate-has-expired e como vinculado de ambos https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020 . Em particular, o único certificado com registro de transparência para o servidor Sectigo RSA DV é https://crt.sh/?id=924467861 sob USERTrust RSA, que possui quatro certificados conhecidos listados em https://crt.sh/?caid=1167portanto, se você estiver usando o AddTrust # 4860286, poderá ver que notAfter foi 30/05/2020 - apenas cerca de um mês atrás.

    • 2

  2. É exatamente o que joeqwerty disse acima, você verificou o serviço SMTP atribuído ao certificado ou vinculado ao conector?

    Você pode executar o comando abaixo para verificar:

    Get-ReceiveConnector | FL Identity,RemoteIPRanges,PermissionGroups,Auth*,TlsCertificateName

    Para obter mais detalhes: Configurando o nome do certificado TLS para conectores de recebimento do Exchange Server

    • 1
  3. Best Answer

    Então @dave_thompson_085 teve a ideia certa de que o problema era que o certificado AddTrust que estava na raiz da minha cadeia de certificados havia expirado. Depois de corrigir o problema no servidor Exchange (recriando o arquivo de certificado PFX sem a raiz AddTrust e importando-o novamente), ainda estava recebendo o mesmo erro. Eu configurei um segundo cliente e tentei enviar um e-mail e descobri que funcionou corretamente, então eu sabia que o problema tinha que ser com a máquina do cliente. Usando o WireShark no servidor Exchange, observei o tráfego TLS entre as duas máquinas e pude ver que o servidor Exchange enviaria o certificado e seu certificado pai imediato (Certigo CA cert) e, em seguida, o cliente o rejeitaria como expirado (mesmo que ambos certificados eram válidos). Eu assumi que o cliente deve estar verificando os certificados recebidos e, de alguma forma, descobrindo que eles estão encadeados na raiz AddTrust expirada. Os e-mails estavam sendo enviados pelo PHPMailer, então eu olhei nas configurações do PHP e descobri que ele tinha um pacote CA que ele usa (pois o PHP não pode usar o Windows Certificate Store aparentemente). Olhando nesse pacote de CA, encontrei e removi o certificado AddTrust e isso corrigiu o problema.

    • 0

relate perguntas