직접 신뢰 인증서 오류 1037 및 2019 문제를 해결하는 방법

  • 아티클

 

적용 대상: Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2007-09-13

이 항목에서는 이벤트 1037 및 이벤트 2019를 해결하는 방법에 대해 설명합니다. 이들 이벤트는 직접 신뢰 인증서와 관련되어 있습니다.

이벤트 1037 및 이벤트 2019는 Microsoft Exchange가 이벤트가 발생한 컴퓨터에서 내부 전송 인증서(직접 신뢰 인증서라고도 부름)의 유효성을 검사하려고 할 때 문제가 발생했음을 나타내는 경고 이벤트입니다. Microsoft Exchange Server 2007에서 직접 신뢰란 Active Directory 디렉터리 서비스 또는 ADAM(Active Directory 응용 프로그램 모드) 디렉터리 서비스에 있는 인증서의 존재 여부로 인증서의 유효성을 검사하는 것입니다. Active Directory는 신뢰할 수 있는 저장소 메커니즘으로 간주됩니다. 직접 신뢰를 사용하는 경우 인증서가 자체 서명한 것인지 아니면 인증 기관에서 서명한 것인지는 관계가 없습니다.

기본적으로 Microsoft Exchange는 타사 사용자 지정 인증서를 사용하지 않고 Microsoft Exchange에 의해 설치되는 자체 서명 인증서를 사용합니다. 그러나 사용자 지정 인증서를 직접 신뢰에 사용할 수도 있습니다.

이벤트 1037 및 이벤트 2019가 나타내는 문제는 다음 조건 중 하나 이상에 의해 발생합니다.

  • 인증서에 SMTP(Simple Mail Transfer Protocol) 서비스가 사용되도록 설정되어 있지 않습니다. 기본적으로 자체 서명 내부 전송 인증서에는 SMTP 서비스가 사용되도록 설정되어 있습니다. 그러므로 직접 신뢰용으로 사용 중인 사용자 지정 인증서가 설치되어 있는 경우에는 SMTP 서비스가 사용되도록 설정되어 있지 않을 수 있습니다.

  • 네트워크 서비스 계정에 C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys 디렉터리의 키에 대한 올바른 권한이 없습니다. 여기서 C:\는 Exchange 2007이 설치된 디렉터리입니다.

  • 잘못된 DNS 또는 컴퓨터 이름 구성으로 인해 인증서 선택 프로세스의 호스트 이름 쿼리가 실패할 수 있습니다.

  • 허브 전송 서버 역할이 NLB(네트워크 로드 균형 조정)를 사용하도록 구성되어 있습니다. 허브 전송 서버 역할은 허브 전송 서버 간의 통신 등과 같은 시나리오에 대해 클러스터 또는 NLB 구성에서 Exchange Server 인증용으로 지원되지 않습니다. 그러므로 NLB를 사용하면 인증서 확인 중에 호스트 이름 쿼리가 실패할 수 있습니다.

시작하기 전에

이 절차를 수행하려면 사용하는 계정이 다음을 위임받아야 합니다.

  • Get-ExchangeCertificate cmdlet를 실행하기 위한 Exchange 보기 권한만 있는 관리자 역할

  • New-ExchangeCertificate cmdlet 또는 Enable-ExchangeCertificate cmdlet를 실행하기 위한 대상 서버에 대한 Exchange Server 관리자 역할 및 로컬 관리자 그룹

  • Filemon(filemon.exe)을 실행하기 위한 대상 서버에 대한 로컬 관리자 그룹

Edge 전송 서버 역할이 설치된 컴퓨터에서 이러한 cmdlet 또는 Filemon을 실행하려면 해당 컴퓨터의 로컬 관리자 그룹에 속한 계정을 사용하여 로그온해야 합니다.

사용 권한, 역할 위임 및 Exchange 2007 관리에 필요한 권한에 대한 자세한 내용은 사용 권한 고려 사항을 참조하십시오.

절차

경고 이벤트를 해결하려면 다음 중 하나를 수행합니다.

  • 인증서에서 SMTP 서비스를 사용하도록 설정했는지 확인합니다.

    Exchange 관리 셸에서 다음 cmdlet를 실행합니다.

    Get-ExchangeCertificate | fl *

    참고

    Exchange Server 2007 서비스 팩 1 이상 버전을 실행하고 있는 경우 명령 인수에 별표(*)를 넣지 않습니다.

    명령 실행 결과에는 컴퓨터에 설치된 모든 인증서에 대한 자세한 정보가 표시됩니다.

    • IsSelfSign 특성의 값이 True인 인증서는 Microsoft Exchange에서 설치한 자체 서명 인증서입니다. 자체 서명 인증서는 서버에 여러 개 설치할 수 있습니다. 그러나 최신 타임스탬프가 포함된 유효한 인증서만이 사용됩니다.

    • IsSelfSign 특성의 값이 False인 인증서는 타사 인증서이거나 사용자 지정된 인증서입니다.

    Services 특성에 SMTP 값이 포함되어 있지 않으면 Exchange 관리 셸에서 다음 cmdlet를 실행합니다.

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

    참고

    이 명령을 실행하면 이미 인증서에 사용하도록 설정되어 있는 모든 서비스에 SMTP가 추가되지만, 기존 서비스가 제거되지는 않습니다.

  • 네트워크 서비스 계정에 올바른 권한이 있는지 확인합니다. 네트워크 서비스 계정에 C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys 디렉터리의 모든 키에 대한 읽기 권한이 있는지 확인합니다. 여기서 C:\는 Exchange 2007이 설치된 디렉터리입니다.

    참고

    Filemon을 사용하여 권한 문제인지 확인할 수도 있습니다.

  • Filemon을 시작하여 오류 발생을 캡처합니다. 모든 access denied 이벤트에 대한 결과 로그 파일을 검토합니다. 로컬 DNS 구성에 구성되어 있는 매개 변수가 직접 신뢰 인증서의 확인 프로세스에서 사용 중인 조건과 일치하는지 확인합니다. 그리고 로컬 DNS 구성을 Microsoft Exchange에서 설치되는 자체 서명 인증서와 비교해야 하고, 이는 직접 신뢰용으로 이 인증서가 필요하기 때문입니다. 내부 전송 인증서에 대한 유효성 검사 프로세스에서는 다음 DNS 구성 설정을 확인합니다.

    • DnsFullyQualifiedDomainName

    • DnsHostName

    • DnsPhysicalFullyQualifiedDomainName

    • DnsPhysicalHostName

    Exchange Troubleshooting Assistant의 추적 기능을 사용하여 인증서 조건을 검토할 수 있습니다. 이 작업에는 다음 구성 요소 및 태그를 사용합니다.

    • Common\Certificate

    • NetworkingLayer\Certificate

    • Transport\Certificate

    Exchange Troubleshooting Assistant 추적 기능에서는 FQDN(정규화된 도메인 이름)이 자체 서명 인증서에 구성되어 있는 도메인과 일치하는지 여부를 확인할 수 있는 출력을 생성합니다. FQDN이 일치하지 않으면 잘못 구성된 경우일 수 있습니다. 이 시나리오에서는 인증서가 데이터를 가져오는 위치를 확인해야 합니다.

  • Exchange 서버가 NLB 환경에서 실행되고 있으면, 직접 신뢰 인증서의 확인 프로세스 중에 예기치 않은 FQDN이 추가될 수 있습니다. 예기치 않은 도메인이 발견되는 경우에는 이 도메인이 NLB 구성에 구성되어 있는지 확인합니다. NLB 구성에 예기치 않은 FQDN이 포함되어 있으면 이로 인해 인증서 확인이 실패하지 않도록 NLB 구성을 수정합니다.

자세한 내용

자세한 내용은 다음 항목을 참조하십시오.