Безопасность : устройства безопасности электронной почты Cisco ESA

Гарантируйте, что может быть проверено ваше свидетельство ESA

17 октября 2015 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает, как гарантировать, что может быть проверено ваше свидетельство Почтового прибора безопасности (ESA) Cisco.

Внесенный Cisco инженеры TAC.

Процедура

С почтовой обработкой через Cisco ESA иногда другие области могут проверять ваше свидетельство, когда они посылают вам почту (например, Если они используют что-то подобное "Необходимому" TLS). Когда та область проверяет ваше свидетельство, все проверки должны преуспеть (с обеих сторон). Даже если одна проверка потерпит неудачу, то целая связь TLS прервется. Это - передовая практика для имения свидетельства, поддающегося проверке даже при подтверждении других областей (например, если вы используете "Необходимый" TLS, "Необходимый - Проверяют", или "Предпочтительный - Проверяют" в Средствах управления Местом назначения). Информация в этой статье объясняет основные контрольно-пропускные пункты для покрытия, чтобы знать, может ли быть успешно проверено свидетельство.

Прежде, чем объяснить фактический процесс проверки свидетельства важно сначала понять то, что может произойти на уровне связи:

Почтовый сервер отправки будет поиск DNS область получения для отчетов MX (hostnames). Почтовый сервер отправки будет тогда поиск DNS hostname почтового сервера получения для его IP-адреса (hostname с самым низким Приоритетом DNS). Наиболее вероятно сервер отправки полностью изменит поиск DNS, что IP-адрес, чтобы видеть, возвращает ли это тот же самый hostname, который это возвратило в оригинальном поиске DNS. Если сервер отправки проверит область получения, и это не возвращает тот же самый hostname, то отправитель, вероятно, пропустит связь.

Основные контрольно-пропускные пункты для подтверждения свидетельства показывают здесь:

  1. Если связь преуспеет, то почтовый сервер получения пошлет баннер. Баннер будет состоять из фактического (220-mailhost.example.com) hostname почтового сервера получения. Почтовый сервер отправки будет помнить этот hostname за когда его время для подтверждения свидетельства. Почтовый сервер отправки пошлет команду EHLO наряду со своей собственной областью как аргумент (e.g.ehloesa.com). Почтовый сервер получения ответит своими параметрами, и  STARTTLS приказывают, чтобы он предложил.

    Примечание: Если вы делаете ручной тест TELNET на порту 25 к почтовому серверу получения, и вы не видите, что STARTTLS предлагается, то тот почтовый сервер не может сделать TLS.

    Сервер отправки должен тогда выполнить команду STARTTLS. Почтовый сервер получения скажет, "Продолжают TLS".

    myesa.local> telnet mailhost.example.com 25
    Trying 1.1.1.1...
    Connected to mailhost.example.com.
    Escape character is '^]'.
    220-mailhost.example.com ESMTP
    220 Welcome to this mail server. You may proceed to communicate.
     
    ehlo esa.com
    250-mailhost.example.com
    250-8BITMIME
    250-SIZE 33554432
    250 STARTTLS
     
    starttls
    220 Go ahead with TLS
  2. Эти два почтовых сервера выберут Силу Шифра сначала. После этого почтовый сервер отправки начнет проверять свидетельство о почтовом сервере получения. 
  3. Сервер отправки будет видеть Общее название свидетельства. Почтовый сервер отправки проверит это Общее название, чтобы видеть, соответствует ли это (точно) hostname от (220-mailhost.example.com) баннера связи. Обратите внимание на то, что, если у вас есть дикая карта как ваше Общее название в свидетельстве (например, *.example.com), тогда это точно не соответствует, hostname в баннере (mailhost.example.com точно не соответствует *.example.com). Если Общее название свидетельства не будет точно соответствовать hostname в этих 220 баннерах, то эта проверка потерпит неудачу. Поэтому, связь TLS прервется.
  4. Последняя основная проверка, которая сделана, проверяет, что свидетельство должным образом приковано цепью. Некоторым почтовым серверам отправки не нравятся Самоподписанные Свидетельства. Кроме того, некоторым почтовым серверам отправки не нравятся свидетельства, которые были подписаны неизвестным Центром сертификации (CA) (CA, который почтовый сервер отправителя не знает). Если сервер отправки не любит ваше Самоподписанное Свидетельство или не знает, кто ваш CA, то TLS потерпит неудачу.
  5. Другая часть к подтверждению цепи вашего свидетельства должна видеть, может ли ваша Область (Компания) Свидетельство быть связана назад с вашим Центром сертификации (CA). Обычно при покупке свидетельства от CA тогда у вас были бы Свидетельство Компании, Промежуточное Свидетельство и Корень (CA) Свидетельство (в некоторых случаях, вы, возможно, только получили одно свидетельство, но это свидетельство должно все еще содержать все три). Эти три свидетельства должны быть должным образом загружены в ESA отдельно (но все еще на той же самой странице расположенная Сеть> Свидетельства). Если у вас не будет всех трех свидетельств загруженными к ESA отдельно (или в надлежащем заказе), то почтовый сервер отправки не будет в состоянии проверить, что у вас есть должным образом цепочечное свидетельство. Поэтому, TLS потерпит неудачу.

    Если сервер отправки проверит ваше свидетельство, и любая из вышеупомянутых проверок терпит неудачу, то TLS потерпит неудачу.

Соответствующая информация


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 118572