Cisco ESA에서 TLS 인증서 확인 및 문제 해결

소개

이 문서에서는 Cisco ESA(Email Security Appliance)에서 TLS 인증서를 생성, 구성 및 트러블슈팅하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

ESA에서 TLS를 구현하면 암호화를 통해 이메일을 포인트-투-포인트 전송할 수 있는 프라이버시가 제공됩니다. 이 구현을 통해 관리자는 CA(Certificate Authority) 서비스에서 인증서 및 개인 키를 가져오거나 자체 서명 인증서를 사용할 수 있습니다.

Cisco AsyncOS for Email Security는 SMTP(Simple Mail Transfer Protocol)로의 STARTTLS 확장(TLS를 통한 보안 SMTP)을 지원합니다.

참고: 이 문서에서는 ESA에서 중앙 집중식 관리 기능을 사용하여 클러스터 레벨에서 인증서를 설치하는 방법에 대해 설명합니다. 인증서는 시스템 수준에서 적용할 수 있습니다. 그러나 시스템을 클러스터에서 제거한 다음 다시 추가하면 시스템 레벨 인증서가 손실됩니다.

기능 개요 및 요구 사항

관리자는 다음과 같은 이유로 어플라이언스에서 인증서를 활용할 수 있습니다.

• TLS(인바운드 및 아웃바운드 대화 모두)를 사용하는 다른 MTA와의 SMTP 대화를 암호화합니다.
• HTTPS를 통해 GUI에 액세스하기 위해 어플라이언스에서 HTTPS 서비스를 활성화합니다.
• LDAP 서버에 클라이언트 인증서가 필요한 경우 LDAP(Lightweight Directory Access Protocol)에 대한 클라이언트 인증서로 사용합니다.
• 어플라이언스와 Cisco AMP(Advanced Malware Protection) Threat Grid Appliance 간의 보안 통신을 허용합니다.

ESA에는 TLS 연결을 설정하는 데 사용할 수 있는 데모 인증서가 미리 구성되어 있습니다.

주의: 데모 인증서는 보안 TLS 연결을 설정하기에 충분하지만, 확인 가능한 연결을 제공할 수 없다는 점에 유의하십시오. Cisco에서는 CA로부터 X.509 또는 PEM(Privacy Enhanced Email) 인증서를 받을 것을 권장합니다.

인증서 구성 및 할당

계속하기 전에 사용 설명서에 설명된 대로 인증서를 만들고 할당하는 단계를 완료했는지 확인하십시오. 이 링크는 필요한 지침을 제공합니다.

• 서명된 인증서 구축
• 인증서 할당

다음을 확인합니다.

HTTPS용 TLS 확인

1. GUI 액세스: HTTPS URL을 사용하여 ESA 디바이스로 이동합니다(예: https://esa.example.com).

2. 인증서 세부사항 열기: 브라우저 주소 표시줄에서 URL 왼쪽에 있는 사이트 정보 아이콘(일반적으로 자물쇠)을 클릭합니다.

3. 브라우저를 기준으로 검증:

     a. Google Chrome: 자물쇠 아이콘 > Connection is secure > Certificate is valid를 클릭합니다.

     b. Microsoft Edge: 자물쇠 아이콘 > Connection is secure > Certificate 아이콘(플라이아웃 오른쪽 상단)을 클릭합니다.

     c. Mozilla Firefox: Padlock(자물쇠) 아이콘 > Connection secure(연결 보안) > More information(추가 정보) > View Certificate(인증서 보기)를 클릭합니다.

4. 유효성 확인: 인증서 뷰어에서 "유효기간" 또는 "상태"를 검토합니다. 인증서가 Valid로 표시되면 연결이 안전하며 브라우저에서 인증서가 올바르게 인식됩니다.

이메일 전송 또는 수신용 TLS 확인

GUI의 메시지 추적에서 이 정보를 제공하지만 대량 검토나 신속한 문제 해결을 위해서는 CLI(Command Line Interface)를 사용하는 것이 더 효율적입니다.

CLI를 통해 TLS 상태를 검토하려면 다음 단계를 따르십시오.

1. CLI에 로그인합니다. 관리 자격 증명을 사용하여 SSH를 통해 어플라이언스에 액세스합니다.
2. Grep 명령 실행: TLS 관련 활동에 대한 메일 로그를 필터링하려면 greputity를 사용합니다.
3. 연결 ID 분석: 연결 유형에 따라 출력을 검토합니다.
   • ICID(Incoming Connection ID): 리스너에서 수신하는 연결에 대한 TLS를 확인하려면 이 항목을 검토합니다.
   • DCID(Delivery Connection ID): 다음 홉 MTA로 전달되는 연결에 대한 TLS를 확인하려면 이 항목을 검토하십시오.

참고: "TLS success" 또는 "TLS failed"와 같은 특정 문자열을 검색하여 결과 범위를 좁힐 수 있습니다.

메일을 받을 때의 TLS 성공 예

(Machine esa.example.com)> grep "ICID.*TLS failed" mail_logs
Sat Feb 14 19:20:28 2026 Info: ICID 111396123 TLS failed: [Errno 0] Error
Sat Feb 14 19:20:28 2026 Info: ICID 111396456 TLS failed: ('SSL routines:tls_early_post_process_client_hello:no shared cipher')

메일을 받을 때의 TLS 실패 예

(Machine esa.example.com)> grep "ICID.*TLS success" mail_logs
Sat Feb 14 19:14:38 2026 Info: ICID 111395123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384
Sat Feb 14 19:14:41 2026 Info: ICID 111395456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

메일 전달 시 TLS 성공 예

(Machine esa.example.com)> grep "DCID.*TLS success" mail_logs

Sat Feb 14 19:12:56 2026 Info: DCID 21966123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 the.cpq.host
Sat Feb 14 19:13:00 2026 Info: DCID 21966456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

메일 전달 시 TLS 실패 예

(Machine esa.example.com)> grep "DCID.*TLS failed" mail_logs

Sat Feb 14 19:58:43 2026 Info: DCID 21967123 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled
Sat Feb 14 20:58:44 2026 Info: DCID 21967456 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled

LDAP에 대한 TLS 확인

ldap_debug 로그에는 특정 TLS 문자열이 표시되지 않지만, LDAP 응답 및 사용 중인 포트를 검사하여 TLS의 성공 또는 실패 여부를 확인할 수 있습니다. LDAPS 연결의 경우 일반적으로 Active Directory용 포트 3269 또는 OpenLDAP용 포트 636을 의미합니다.

LDAP에 대한 TLS 예

(Machine esa.example.com) (SERVICE)> tail ldap_debug

Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) to server LDAP (ldaps-esa.example.com:3269)
Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) lookup success, (ldaps-esa.example.com:3269) returned 0 results timestamp=1771989863.189580

참고: LDAP 트래픽 및 TLS 활동에 대한 자세한 분석을 위해 관련 호스트 및 포트에서 네트워크 패킷을 캡처하는 것이 좋습니다.

문제 해결

이 섹션에서는 ESA에서 기본 TLS 문제를 해결하는 방법에 대해 설명합니다.

중간 인증서 확인

특히 새 인증서 생성 대신 현재 인증서가 업데이트될 경우 중복 중간 인증서를 찾습니다. 중간 인증서가 변경되거나 잘못 체인화될 수 있으며 인증서는 여러 중간 인증서를 업로드할 수 있습니다. 이로 인해 인증서 체인 및 확인 문제가 발생할 수 있습니다.

필수 TLS 연결 실패에 대한 알림 활성화

TLS 연결이 필요한 도메인에 메시지가 전달될 때 TLS 협상이 실패할 경우 알림을 전송하도록 ESA를 구성할 수 있습니다. 경고 메시지에는 실패한 TLS 협상에 대한 대상 도메인의 이름이 포함되어 있습니다. ESA는 시스템 알림 유형에 대한 경고 심각도 레벨 알림을 수신하도록 설정된 모든 수신자에게 알림 메시지를 전송합니다.

참고: 이는 전역 설정이므로 도메인별로 설정할 수 없습니다.

TLS 연결 알림을 활성화하려면 다음 단계를 완료하십시오.

1. Mail Policies(메일 정책) > Destination Controls(대상 제어)로 이동합니다.
2. Edit Global Settings를 클릭합니다.
3. Send alert when a required TLS connection fails(필수 TLS 연결 실패 시 알림 전송) 확인란을 선택합니다.

팁: destconfig > setup CLI 명령을 사용하여 이 설정을 구성할 수도 있습니다.

ESA는 도메인에 TLS가 필요하지만 어플라이언스 mail_logs에서 사용할 수 없는 인스턴스도 기록합니다. 이 문제는 다음 조건 중 하나가 충족될 때 발생합니다.

• 원격 MTA는 ESMTP를 지원하지 않습니다(예: ESA의 EHLO 명령을 이해하지 못함).
• 원격 MTA는 ESMTP를 지원하지만 STARTTLS 명령이 EHLO 응답에서 광고된 확장 목록에 없습니다.
• 원격 MTA에서 STARTTLS 확장을 광고했지만 ESA에서 STARTTLS 명령을 보낼 때 오류가 발생했습니다.

서드파티 툴을 사용한 문제 해결

• 테스트를 시작하기 전에 어플라이언스가 인바운드 메일을 수신하는 리스너에 인증서가 적용되었는지 확인합니다.

CheckTLS.com 및 SSL-Tools.net과 같은 타사 툴을 사용하여 수신 시 인증서의 올바른 체이닝을 확인할 수 있습니다. 각 도구의 설명서를 검토하여 인증서를 검증하는 방법을 이해합니다.

참고: 자체 서명 인증서가 사용 중인 경우 오류가 발생할 수 있습니다.

해결

CA 서명 인증서가 사용 중이고 TLS-verify가 실패한 경우 다음 항목이 일치하는지 확인합니다.

• 인증서 일반 이름
• 호스트 이름(GUI > Network > Interface)
• MX 레코드 호스트 이름: TestReceiver 테이블의 MX Server 열입니다.

관련 정보

• Cisco Email Security Appliance − 엔드 유저 가이드