Come risolvere gli errori relativi ai certificati di trust diretto 1037 e 2019

  • Articolo

 

Si applica a: Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2007-09-13

Questo argomento descrive come risolvere l'evento 1037 e l'evento 2019. Questi eventi sono associati con i certificati di trust diretto.

L'evento 1037 e l'evento 2019 sono avvisi che segnalano il verificarsi di un problema quando Microsoft Exchange prova a convalidare un certificato di trasporto interno (definito anche certificato di trust diretto) per il computer sul quale si sono verificati gli eventi. In Microsoft Exchange Server 2007, trust diretto significa che la presenza del certificato nel servizio directory di Active Directory o di Active Directory Application Mode (ADAM) convalida il certificato. Active Directory è considerata un meccanismo di archiviazione attendibile. Inoltre, in questi casi è irrilevante che il certificato sia autofirmato o firmato da un'Autorità di certificazione.

Per impostazione predefinita, Microsoft Exchange utilizza un certificato autofirmato installato da Microsoft Exchange invece di utilizzare un certificato personalizzato di terze parti. Tuttavia, è possibile utilizzare un certificato personalizzato per il trust diretto.

Il problema segnalato dall'evento 1037 e dall'evento 2019 è causato da una o più delle seguenti condizioni:

  • Il servizio SMTP (Simple Mail Transfer Protocol) non è attivato per il certificato. Per impostazione predefinita, i certificati di trasporto interno autofirmati presentano il servizio SMTP attivato. Di conseguenza, è più probabile che il servizio SMTP non possa essere attivato se è installato un certificato personalizzato utilizzato per il trust diretto.

  • L'account Servizio di rete potrebbe non possedere le autorizzazioni corrette nelle chiavi di crittografia della seguente directory: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, dove C:\ è la directory in cui è stato installato Exchange 2007.

  • La query del nome host durante il processo di selezione del certificato può fallire a causa di una configurazione DNS o nome macchina errate.

  • Il ruolo del server Trasporto Hub è configurato per l'utilizzo di NLB (Network Load Balancing). Il ruolo del server Trasporto Hub non è supportato per l'autenticazione Exchange Server in un cluster o in una configurazione NLB, per scenari come la comunicazione tra server Trasporto Hub. L'utilizzo di NLB può causare l'errore della query nome host durante la convalida del certificato.

Informazioni preliminari

Per eseguire questa procedura, è necessario utilizzare un account che disponga della seguente delega:

  • Ruolo Amministratore di Exchange con diritti di sola visualizzazione per eseguire il cmdlet Get-ExchangeCertificate

  • Ruolo Exchange Server Administrator e gruppo Administrators locale per il server di destinazione per eseguire il cmdlet New-ExchangeCertificate o il cmdlet Enable-ExchangeCertificate.

  • Gruppo Administrators locale per il server di destinazione per eseguire Filemon (Filemon.exe)

Per eseguire uno di questi cmdlet o Filemon su un computer in cui è installato il ruolo del server Trasporto Edge, è necessario accedere al sistema utilizzando un account che sia membro del gruppo Administrators locale del computer.

Per ulteriori informazioni sulle autorizzazioni, sulla delega dei ruoli e sui diritti necessari per l'amministrazione di Exchange 2007, vedere Considerazioni sulle autorizzazioni.

Procedura

Per risolvere gli eventi di avviso, eseguire una o più delle seguenti operazioni

  • Assicurarsi che il servizio SMTP sia attivato sul certificato.

    Eseguire il seguente cmdlet in Exchange Management Shell.

    Get-ExchangeCertificate | fl *

    Nota

    Se si sta eseguendo Exchange 2007 Service Pack 1 o versioni successive, non includere l'asterisco (*) nell'argomento del comando.

    Il risultato mostrerà i dettagli di tutti i certificati installati sul computer.

    • Se il valore dell'attributo IsSelfSign è True, il certificato è un certificato autofirmato installato da Microsoft Exchange. È possibile avere più di un certificato autofirmato installato sul server. Tuttavia, verrà utilizzato soltanto il certificato valido con il timestamp più recente.

    • Se il valore dell'attributo IsSelfSign è False, il certificato è un certificato di terze parti o un certificato personalizzato.

    Se l'attributo Services non comprende il valore SMTP, eseguire il seguente cmdlet in Exchange Management Shell.

    Enable-ExchangeCertificate -Thumbprint <insert_certificate_thumbprint> -Services:SMTP

    Nota

    Questo comando aggiungerà il servizio SMTP a tutti i servizi già attivati sul certificato. Non annullerà nessuno dei servizi presenti.

  • Stabilire se l'account Servizio di rete possiede le autorizzazioni corrette. Assicurarsi che l'account Servizio di rete abbia le autorizzazioni di lettura sulle chiavi nella seguente directory: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, dove C:\ è la directory in cui è stato installato Exchange 2007.

    Nota

    Anche Filemon può essere utilizzato per stabilire se sussiste un problema di autorizzazioni.

  • Avviare Filemon e acquisire il caso dell'errore. Analizzare il file di registro prodotto in cerca di eventi access denied. Verificare che i parametri configurati nella configurazione DNS locale corrispondano ai criteri utilizzati nel processo di convalida per i certificati di trust diretto. La configurazione DNS locale deve essere confrontata con il certificato autofirmato installato da Microsoft Exchange dal momento che il certificato è necessario per il trust diretto. Il processo di convalida per i certificati di trasporto interno controlla le seguenti impostazioni di configurazione DNS:

    • DnsFullyQualifiedDomainName

    • DnsHostName

    • DnsPhysicalFullyQualifiedDomainName

    • DnsPhysicalHostName

    È possibile analizzare i criteri per il certificato utilizzando l'analisi di Exchange Troubleshooting Assistant. A tale scopo, utilizzare le seguenti schede e i seguenti comandi:

    • Common\Certificate

    • NetworkingLayer\Certificate

    • Transport\Certificate

    L'analisi di Exchange Troubleshooting Assistant genera un rapporto che può aiutare a stabilire se il nome di dominio completo (FQDN) corrisponde ai domini configurati sul certificato autofirmato. Se il FQDN non corrisponde, è probabile che sia configurato in maniera non corretta. In questo scenario, si deve provare a stabilire da quale percorso il certificato sta ricavando i dati.

  • Se il server Exchange è in funzione in un ambiente NLB, un FQDN inatteso può essere aggiunto durante il processo di convalida per i certificati di trust diretto. Se si nota un dominio inatteso, controllare la configurazione NLB per capire se il dominio inatteso è configurato qui. Se la configurazione NLB contiene un FQDN inatteso, modificare la configurazione NLB in modo che non impedisca la convalida del certificato.

Ulteriori informazioni

Per ulteriori informazioni, vedere i seguenti argomenti: