Статьи

Як убезпечити поштовий трафік SMTP | Windows IT Pro / RE | Видавництво «Відкриті системи»

  1. Як убезпечити поштовий трафік SMTP
  2. Запит на SSL-сертифікацію
  3. отримання сертифікату
  4. Використання CA незалежної компанії
  5. включення STARTTLS
  6. Проблеми при роботі з TLS
  7. Підтвердження запиту на отримання сертифіката
  8. Як убезпечити поштовий трафік SMTP
  9. Запит на SSL-сертифікацію
  10. отримання сертифікату
  11. Використання CA незалежної компанії
  12. включення STARTTLS
  13. Проблеми при роботі з TLS
  14. Як убезпечити поштовий трафік SMTP
  15. Запит на SSL-сертифікацію
  16. отримання сертифікату
  17. Використання CA незалежної компанії
  18. включення STARTTLS
  19. Проблеми при роботі з TLS
  20. Підтвердження запиту на отримання сертифіката

Як убезпечити поштовий трафік SMTP

Використання Transport Layer Security

Через те що при відправленні листів в стандарті SMTP не використовується ні шифрування, ні процедура аутентифікації, будь-яке повідомлення є доступним для перегляду. Рішення на стороні клієнта, такі, наприклад, як Secure MIME (S / MIME) або Pretty Good Privacy (PGP), можуть допомогти вирішити проблему захисту пошти, але вони вимагають участі в цій процедурі самих користувачів. Основний ділянку, де слід було б зосередити зусилля щодо забезпечення безпеки, - захист трафіку SMTP. Якщо вдасться убезпечити SMTP, то в принципі можна буде досягти стовідсоткової безпеки поштового трафіку, неважливо - породжується він на даному сервері або закінчується.

Microsoft Exchange Server передбачає кілька способів забезпечення безпеки поштового трафіку. Один з них полягає в обов'язковому використанні Secure Sockets Layer (SSL) for SMTP для наявних з'єднань. Однак застосування цього способу викликає деякі проблеми. За замовчуванням всі сервери SMTP використовують 25-й порт. Але якщо для 25-го порту застосовується SSL, то інші сервери, які не підтримують SSL, вже не зможуть встановити з'єднання з даним сервером через 25-й порт. А якщо скористатися нестандартним номером порту, решта сервери взагалі не зможуть виявити його.

Проблему можна спробувати обійти. Команда STARTTLS (вона входить до складу Extended SMTP - ESMTP) дозволяє клієнту і серверу SMTP розпізнати факт застосування Transport Layer Security (TLS) для звичайного SMTP-з'єднання. Учасник з'єднання на будь-якому його кінці може провести аутентифікацію свого партнера або ж TLS-з'єднання може використовуватися виключно як секретний канал зв'язку. Як би там не було, у такого підходу є три важливі переваги.

  • Відсутня перетин з іншими серверами і клієнтами. Ті клієнти, які підтримують функцію STARTTLS, можуть її використовувати; ті, хто не може, продовжують працювати з незахищеним трафіком SMTP.
  • Гнучкість рішення. Якщо клієнт може задіяти TLS з SMTP, сервер автоматично запитує TLS-підключення при зверненні до решти серверів і сам відгукується на запити про TLS-з'єднанні. Припустимо, що який-небудь зовнішній сервер запустив процес узгодження абонентів, в цьому випадку пошта автоматично стає захищеною. Проте я б порадив адміністраторам змушувати користувачів включати параметр SSL / TLS на поштовому клієнті.
  • TLS-шифрування SMTP захищає заголовки повідомлень, це додатковий ступінь захисту від програм-аналізаторів трафіку, без якої зловмисник зміг би без труднощів встановити, хто і як часто пов'язується один з одним.

Одне важливе попередження: TLS не захищає повідомлення на всьому протязі з'єднання, з кінця в кінець. Іншими словами, повідомлення не захищене в разі його зберігання на станції клієнта або при пересиланні з клієнта на сервер (якщо тільки клієнт сам не підтримує TLS). TLS захищає повідомлення, лише поки воно пересилається між двома серверами, що підтримують TLS.

Запит на SSL-сертифікацію

Перш ніж почати використовувати TLS з SMTP, необхідно отримати і встановити сертифікат для SMTP-сервера. Якщо у вас вже є власний центр сертифікації, Certificate Authority (CA), запит на отримання SSL-сертифіката не викликає ускладнень, якщо ж ні, тоді необхідно зберегти запит на сертифікат у файлі і передати його в кращий CA. Про те, як встановити Microsoft CA або скористатися зовнішнім CA для інфраструктури відкритого ключа (Public Key Infrastructure - PKI), розказано в статті Certificate Services в довіднику Windows Server Help. Припустимо, що у нас є доступ до CA і необхідно скласти запит і встановити сертифікат SSL для роботи з Microsoft Outlook Web Access (OWA), IMAP, POP або SMTP.

Базовий механізм видачі сертифікатів для всіх перерахованих протоколів однаковий, хоча в цій статті розглядається тільки SMTP. Процедуру запиту сертифікату ми ініціюємо з Exchange System Manager (ESM). У вікні дерева ESM потрібно відшукати свій сервер і вибрати Protocols і SMTP. Потім слід відкрити контекстне меню віртуального сервера і вибрати Properties; на вкладці Access з'явиться кнопка Certificate, яка включається щоразу при запуску ESM на сервері Exchange. Оскільки відкритий ключ, що відноситься до даного сертифікату, генерується на локальній машині, сертифікат, створений на станції адміністратора, не має ніякого сенсу.

Для формування запиту на отримання сертифіката при роботі з OWA можна використовувати Internet Services Manager (ISM) 5.0. Однак задіяти ESM для запиту POP- або IMAP-сертифіката простіше, оскільки ці сертифікати можна зажадати безпосередньо в діалоговому вікні Properties віртуального сервера, так що ми їм і скористаємося. Щоб вимагати сертифікат, потрібно просто клацнути Certificate.

отримання сертифікату

Коли кнопку Certificate клацають на сервері, у якого відсутній сертифікат для специфічного протоколу, ESM запускає IIS Certificate Wizard. Ця програма перевіряє, чи не запитували чи коли-небудь SSL-сертифікат за допомогою Microsoft IIS. Щоб запросити сертифікат для застосування в Exchange, необхідні адміністративні привілеї на сервері Exchange, а використовувана обліковий запис повинен мати право запитувати сертифікат від CA.

Після того як екран Welcome закриється, потрібно вказати, що саме слід зробити. Якщо запитується сертифікат для віртуального сервера, у якого сертифікат поки відсутня, користувачеві пропонується на вибір приєднати існуючий сертифікат до віртуального сервера, імпортувати резервну копію сертифіката або запросити новий сертифікат. Якщо вирішено модифікувати існуючий сертифікат, майстер сертифікації запропонує зробити вибір між відновленням сертифіката, видаленням сертифіката з віртуального сервера і запитом на отримання нового сертифікату. Припустимо, нам потрібен запит на отримання нового сертифікату. Після клацання Create a new certificate виконується наступна процедура.

  • На сторінці Delayed Or Immediate Request слід вибрати використання Remote Procedure Call (RPC), щоб відіслати запит в CA, якщо він включений, або зберегти запит у форматі Public-Key Cryptography Standards (PKCS) # 10 - стандартному форматі для запиту сертифіката. Якщо є власний внутрішній CA і він функціонує, потрібно вибрати Send the request immediately to an online certification authority і натиснути Next. При використанні зовнішнього центру CA або якщо внутрішній CA вимкнений, необхідно вибрати Prepare the request now, but send it later і натиснути Next для генерації файлу PKCS # 10, який згодом буде відісланий в CA.
  • Майстер пропонує заповнити ім'я та довжину ключа сертифіката, як показано на Екрані 1. Хоча Windows 2000 підтримує роботу з ключами довжиною 512 розрядів, вони занадто короткі для забезпечення безпечної роботи; завжди слід вибирати довжину ключа принаймні 1024 розряду. Потім потрібно клацнути Next.
  • Майстер просить ідентифікувати Organization і Organizational Unit (OU). Названі атрибути будуть закодовані в сертифікаті, тому дуже важливо вказати їх правильно. При введенні цієї інформації слід ще раз переконатися, що все написано правильно. І лише потім можна натиснути Next.
  • Майстер просить вказати загальне ім'я сайту, Common Name (CN). CN - це повністю певне ім'я домену сервера, Fully Qualified Domain Name (FQDN), як воно з'являється при роботі в Internet. Наприклад, якщо сервер SMTP - exch-smtp-sea-1.fabrikam.corp, а його зовнішнє DNS-ім'я - mail1.fabrikam.com, необхідно вказати mail1.fabrikam.com. Якщо CN станції зміниться, буде потрібно новий сертифікат. Необхідно переконатися, що ім'я DNS вказано вірно: якщо допустити помилку (т. Е. Якщо реальне FQDN і дані сертифікати не відповідають один одному), клієнтські програми, такі як Microsoft Internet Explorer (IE), будуть повідомляти, що сертифікат неправильний.
  • На сторінці Geographical Information потрібно вказати країну (або регіон), штат (або провінцію), а також місто, яке слід прописати в сертифікаті. Ці дані в подальшому не перевіряються, але сертифікат буде повідомляти про них.

До цього моменту процедура запиту сертифікату не залежить від того, включений CA або вимкнений. Після введення даних про географічне положення для запиту в оперативному режимі необхідно вказати CA зі списку доступних програмі - ініціатору запиту. Якщо CA, який передбачається використовувати, в списку відсутня, він не може пропонуватися для видачі сертифіката. Слід вибрати CA, потім клацнути Next. З'явиться підсумковий екран з зазначеними при формуванні запиту параметрами сертифіката; потрібно клацнути Next ще раз для відправки запиту. Якщо запит успішно виконується, сертифікат встановлюється автоматично і можна приступати до настройки TLS.

Використання CA незалежної компанії

Якщо обраний режим Prepare the request now, but send it later для сертифікації через центр CA, що знаходиться за межами мережі, або через автономний CA, який не інтегрований в Active Directory (AD), подальша процедура буде виглядати дещо інакше. Після отримання інформації про географічне положення майстер запропонує зберегти конфігурацію запиту в файлі. Вміст файлу - відкритий (незашифрований) текст в форматі Base64 Encoded Pkcs # 10. Після збереження цього файлу необхідно передати його до відповідного центру CA, зазвичай через Web-інтерфейс. Деталі самого інтерфейсу залежать від CA. Так, наприклад, розрізняють інтерфейси від Thawte, VeriSign і Comodo? S InstantSSL, виглядають вони по-різному. На більшості Web-сайтів незалежних центрів сертифікації є набір інструкцій щодо заповнення вимоги на сертифікат.

Microsoft CA також приймає запити PKCS # 10 через Web-інтерфейс. Ось як протікає процес звернення до CA і установка отриманого сертифіката.

  • На сервері Exchange слід відкрити IE і перейти на http: // yourCA / certsrv, де yourCA - це ім'я NetBIOS або ім'я DNS-центру CA. На екрані з'являється сторінка запрошення. Потрібно вибрати Request a certificate і натиснути Next.
  • На сторінці Choose Request Type (див. Екран 2) задається питання про тип запиту. Оскільки нам потрібно сертифікат для віртуального сервера і у нас є збережений запит, слід вибрати Advanced request і клацнути Next. Список User certificate request призначений для сертифікації кінцевих користувачів.
  • Сторінка Advanced Certificate Requests пропонує три можливості: сформувати новий запит за формою, що надається в інтерфейсі CA, скористатися заздалегідь підготовленим запитом PKCS # 10 або запросити сертифікат для користувачів смарт-карт. Оскільки ми хочемо задіяти існуючий запит, слід вибрати Submit для використання готового файлу Base64 Encoded Pkcs # 10 або оновити вміст запиту за допомогою файлу формату Base64 Encoded Pkcs # 7, після чого натиснути Next.
  • На сторінці Submit A Saved Request, представленої на Екрані 3, показано, звідки береться підготовлений для обробки запит. За допомогою Notepad потрібно відкрити файл PKCS # 10 на комп'ютері, з якого була запущена програма браузера. Необхідно скопіювати вміст файлу і вставити його в текстовий блок Saved Request. Якщо сервер сертифікації в настройках системи зазначений як надійний вузол, можна скористатися посиланням Browse для пошуку і вивантаження файлу запиту. Слід клацнути Submit, і система відішле запит в CA для обробки.

Як тільки на сторінці Submission Confirmation з'явиться відповідне повідомлення, необхідно буде повернутися в CA для перевірки статусу запиту і отримання створеного сертифіката. Залежно від того, використовується корпоративний або автономний CA, сертифікат може бути виданий автоматично або ж знадобиться участь адміністратора. Додаткову інформацію про відмінності корпоративного і автономного CA можна знайти в документації Certificate Services в Windows Server Help. Для цього потрібно повернутися на сторінку CA Welcome за адресою http: // servername / certsrv, де servername - ім'я вашого сервера. Необхідно вибрати Check on a pending certificate і клацнути Next. CA показує список всіх запитів, що стоять в черзі на обробку. Слід вибрати свій запит і клацнути Next.

Що з'явиться на екрані, залежить від того, чи видав CA сертифікат. Якщо ще немає, на сторінці CA буде інформація про те, що запит знаходиться в черзі на виконання. В цьому випадку треба ще раз підтвердити запит. Опис процедури підтвердження запиту за допомогою оснастки Microsoft Management Console (MMC) Certificate Services наведено в урізанні «Підтвердження запиту на отримання сертифіката» . Якщо CA видав сертифікат, з'явиться сторінка, вид якої наведено на Екрані 4.

  • Сторінка може здатися не зовсім звичайної, оскільки явної посилання на зразок Download my new certificate тут немає. Слід клацнути Download CA certificate і зберегти файл на сервері Exchange. За замовчуванням для ESM сертифікат зберігається в кодуванні Distinguished Encoding Rules (DER), тому важливо переконатися, що для збереження в файлі вказано саме цей формат сертифіката.

Після збереження сертифіката все готово для його прив'язки до віртуального сервера. Потрібно повернутися в ESM, знайти віртуальний сервер, для якого запитували сертифікат, і відкрити вікно властивостей сервера. На вкладці Access потрібно клацнути Certificate для запуску програми IIS Certificate Wizard. У цей момент майстер повідомляє статус запиту - pending; вибираємо Process the pending request and install the certificate. На наступній сторінці необхідно вказати шлях до файлу сертифіката, який був завантажений, і клацнути Next. ESM декодує сертифікат і показує підсумковий екран з його розшифровкою - додатковий засіб перевірки перед установкою сертифіката. Якщо все правильно, потрібно клацнути Next і Finish для запуску процедури встановлення продукта. Потрібно переконатися, що сертифікат встановлено. Для цього на вкладці Access слід перевірити статус кнопки Communications - вона доступна тільки в тому випадку, коли сертифікат встановлений на віртуальному сервері.

включення STARTTLS

Отримавши сертифікат, можна приступати до захисту трафіку SMTP. Тут є три варіанти: задати використання TLS для всієї вихідної пошти, для зазначених доменів або ж вимагати, щоб всі сервери, що встановлюють з вами з'єднання, використовували TLS. Ці настройки не залежать одна від одної, тому їх можна задіяти як окремо, так і в різних поєднаннях. Щоб включити TLS для всього вихідного поштового трафіку на обраному віртуальному сервері SMTP, слід перейти на вкладку Delivery на сторінці Properties віртуального сервера. Потім потрібно натиснути кнопку Outbound Security - на екрані з'явиться однойменне вікно (див. Екран 5). Необхідно встановити прапорець TLS encryption і натиснути ОК. Однак слід пам'ятати, що ця настройка проявить себе тільки при обміні повідомленнями Exchange з хостами, що підтримують TLS. Встановлене обмеження має небажаний ефект, який виражається в тому, що поштові повідомлення, відправлені на інші хости (без підтримки TLS), залишаються в черзі на доставку необмежений час або до тих пір, поки не закінчиться інтервал повторного відправлення і не буде отримано звіт про неможливість доставки відправленого повідомлення (Nondelivery Report - NDR).

Самий розумний підхід - використовувати коннектори SMTP з підтримкою TLS для зазначених доменів. Практично у всіх ситуаціях краще обмежувати вихідний трафік для тих доменів, про які напевно відомо, що вони підтримують TLS. Встановити, чи підтримує домен TLS, можна в режимі telnet станом 25-го порту поштового сервера домена, запустивши команду SMTP EHLO з командного рядка. Якщо у відповіді присутній STARTTLS, значить, домен підтримує TLS. Найпростіший спосіб організувати використання TLS полягає в створенні конекторів SMTP для доменів, що підтримують TLS. Зробити це можна в контейнері ESM Routing Groups. При створенні нового коннектора (або зміні властивостей існуючого) необхідно виконати два дуже важливих дії: переконатися, що на вкладці Address Space домени вказані вірно, і встановити підтримку TLS на вкладці Advanced (для цього потрібно перейти на вкладку Advanced, клацнути Outbound Security і встановити прапорець TLS encryption).

Активізація TLS для вхідного трафіку не складніше щойно описаної процедури. Потрібно перейти на вкладку Access у вікні властивостей віртуального сервера і клацнути Communication в командній групі Secure Communication. У вікні Security, як показано на Екрані 6, можна включити підтримку TLS з довжиною ключа 40 розрядів (за замовчуванням) або вказати використання довжини ключа 128 розрядів, що я і рекомендую зробити. Потрібно мати на увазі, що установка прапорця Require secure channel означає буквально наступне: сервери, які не підтримують TLS або не можуть прочитати настройки TLS вашого сервера, не передаватимуть на нього поштові повідомлення. Слід бути уважним, встановлюючи Require secure channel; якщо вихідні повідомлення регулярно пропадають, треба задуматися, а чи варто підвищена секретність втрачених повідомлень.

Проблеми при роботі з TLS

Після засекречування вихідного трафіку потрібно звернути увагу на серверні черзі. Деякі системи (в основному це стосується варіацій на тему UNIX Sendmail) будуть відмовлятися встановлювати TLS-з'єднання з системами, які мають «самоподпісанного» сертифікати, тоді як інші спочатку сприймуть STARTTLS, але потім з різних причин не зможуть виконати умов і налаштувань безпеки. Якщо який-небудь сервер не зможе виконати TLS-підключення та якщо він або інші системи при цьому вимагають використання TLS, поштові повідомлення на такі системи відправити не вдасться.

Якщо після включення TLS виявилося, що для поштових повідомлень при відправленні їх на певну систему створюються резервні копії, потрібно перевірити, чи не відбувається це через збої TLS. В такому випадку слід встановити, чому TLS дає збій. Необхідно перевірити журнали SMTP і журнали System і Application. Якщо це не прояснить ситуацію, потрібно зв'язатися з адміністратором віддаленої системи.

Якщо вирішити проблему не вдається, можна спробувати не допустити її. Хоча ядро ​​Exchange SMTP не підтримує установки TLS для доменів, можна створити ще один віртуальний сервер SMTP, в якому не використовується TLS, а потім зв'язати його з SMTP-коннектором. У властивостях коннектора потрібно вказати домен, з яким є проблеми зв'язку. Оскільки Exchange завжди віддає пріоритет явно прописаним маршрутами, пошта почне вирушати за вказаною адресою через даний коннектор, і все запрацює.

Поль Робішо - старший системний архітектор компанії EntireNet, має сертифікати MCSE і MCT. З ним можна зв'язатися за адресою: [email protected] .

Підтвердження запиту на отримання сертифіката

Якщо поштова статус самого першого запиту на отримання сертифіката, може виявитися, що статус запиту - pending (в процесі рішення). Тоді адміністратор повинен підтвердити обробку запиту. Це досить типова ситуація, оскільки при установці центру сертифікації Windows Certificate Authority (CA) в автономному режимі видача сертифікатів затримується до тих пір, поки адміністратор не видасть відповідний дозвіл (підтвердження). Такі установки CA за замовчуванням. Для перевірки статусу і підтвердження запиту використовується оснащення Microsoft Management Console (MMC) Certification Authority, яку необхідно запустити на сервері - центрі CA. Щоб перевірити стан очікують виконання запитів для підтвердження або відмови від їх подальшої обробки, потрібно виконати наступні дії.

  1. Запустити оснащення Certificate Services (Start, Programs, Administrative Tools, Certificate Authority).
  2. Перейти до вузла CA (дерево консолі, ліве вікно) і розкрити його. У вузлі п'ять каталогів: Revoked Certificates, Issued Certificates, Pending Requests, Failed Requests і Policy Settings.
  3. Клацнути Pending Requests. У правій частині консолі перераховані всі запити зі статусом pending. Слід відкрити контекстне меню запиту і вибрати в залежності від поставленого завдання All Tasks, Issue або All Tasks, Deny. Важливо переконатися, що зазначений саме той запит, який потрібен.

Оснащення Certificate Authority дозволяє виконати багато різних завдань, в тому числі відгук індивідуальних сертифікатів (контекстне меню сертифіката в каталозі Issued Certificates, потім All Tasks, Revoke Certificate) і настройку політики при видачі сертифікатів. Детальний опис можливостей оснащення Certificate Authority приведено в Windows 2000 Online Help.

Як убезпечити поштовий трафік SMTP

Використання Transport Layer Security

Через те що при відправленні листів в стандарті SMTP не використовується ні шифрування, ні процедура аутентифікації, будь-яке повідомлення є доступним для перегляду. Рішення на стороні клієнта, такі, наприклад, як Secure MIME (S / MIME) або Pretty Good Privacy (PGP), можуть допомогти вирішити проблему захисту пошти, але вони вимагають участі в цій процедурі самих користувачів. Основний ділянку, де слід було б зосередити зусилля щодо забезпечення безпеки, - захист трафіку SMTP. Якщо вдасться убезпечити SMTP, то в принципі можна буде досягти стовідсоткової безпеки поштового трафіку, неважливо - породжується він на даному сервері або закінчується.

Microsoft Exchange Server передбачає кілька способів забезпечення безпеки поштового трафіку. Один з них полягає в обов'язковому використанні Secure Sockets Layer (SSL) for SMTP для наявних з'єднань. Однак застосування цього способу викликає деякі проблеми. За замовчуванням всі сервери SMTP використовують 25-й порт. Але якщо для 25-го порту застосовується SSL, то інші сервери, які не підтримують SSL, вже не зможуть встановити з'єднання з даним сервером через 25-й порт. А якщо скористатися нестандартним номером порту, решта сервери взагалі не зможуть виявити його.

Проблему можна спробувати обійти. Команда STARTTLS (вона входить до складу Extended SMTP - ESMTP) дозволяє клієнту і серверу SMTP розпізнати факт застосування Transport Layer Security (TLS) для звичайного SMTP-з'єднання. Учасник з'єднання на будь-якому його кінці може провести аутентифікацію свого партнера або ж TLS-з'єднання може використовуватися виключно як секретний канал зв'язку. Як би там не було, у такого підходу є три важливі переваги.

  • Відсутня перетин з іншими серверами і клієнтами. Ті клієнти, які підтримують функцію STARTTLS, можуть її використовувати; ті, хто не може, продовжують працювати з незахищеним трафіком SMTP.
  • Гнучкість рішення. Якщо клієнт може задіяти TLS з SMTP, сервер автоматично запитує TLS-підключення при зверненні до решти серверів і сам відгукується на запити про TLS-з'єднанні. Припустимо, що який-небудь зовнішній сервер запустив процес узгодження абонентів, в цьому випадку пошта автоматично стає захищеною. Проте я б порадив адміністраторам змушувати користувачів включати параметр SSL / TLS на поштовому клієнті.
  • TLS-шифрування SMTP захищає заголовки повідомлень, це додатковий ступінь захисту від програм-аналізаторів трафіку, без якої зловмисник зміг би без труднощів встановити, хто і як часто пов'язується один з одним.

Одне важливе попередження: TLS не захищає повідомлення на всьому протязі з'єднання, з кінця в кінець. Іншими словами, повідомлення не захищене в разі його зберігання на станції клієнта або при пересиланні з клієнта на сервер (якщо тільки клієнт сам не підтримує TLS). TLS захищає повідомлення, лише поки воно пересилається між двома серверами, що підтримують TLS.

Запит на SSL-сертифікацію

Перш ніж почати використовувати TLS з SMTP, необхідно отримати і встановити сертифікат для SMTP-сервера. Якщо у вас вже є власний центр сертифікації, Certificate Authority (CA), запит на отримання SSL-сертифіката не викликає ускладнень, якщо ж ні, тоді необхідно зберегти запит на сертифікат у файлі і передати його в кращий CA. Про те, як встановити Microsoft CA або скористатися зовнішнім CA для інфраструктури відкритого ключа (Public Key Infrastructure - PKI), розказано в статті Certificate Services в довіднику Windows Server Help. Припустимо, що у нас є доступ до CA і необхідно скласти запит і встановити сертифікат SSL для роботи з Microsoft Outlook Web Access (OWA), IMAP, POP або SMTP.

Базовий механізм видачі сертифікатів для всіх перерахованих протоколів однаковий, хоча в цій статті розглядається тільки SMTP. Процедуру запиту сертифікату ми ініціюємо з Exchange System Manager (ESM). У вікні дерева ESM потрібно відшукати свій сервер і вибрати Protocols і SMTP. Потім слід відкрити контекстне меню віртуального сервера і вибрати Properties; на вкладці Access з'явиться кнопка Certificate, яка включається щоразу при запуску ESM на сервері Exchange. Оскільки відкритий ключ, що відноситься до даного сертифікату, генерується на локальній машині, сертифікат, створений на станції адміністратора, не має ніякого сенсу.

Для формування запиту на отримання сертифіката при роботі з OWA можна використовувати Internet Services Manager (ISM) 5.0. Однак задіяти ESM для запиту POP- або IMAP-сертифіката простіше, оскільки ці сертифікати можна зажадати безпосередньо в діалоговому вікні Properties віртуального сервера, так що ми їм і скористаємося. Щоб вимагати сертифікат, потрібно просто клацнути Certificate.

отримання сертифікату

Коли кнопку Certificate клацають на сервері, у якого відсутній сертифікат для специфічного протоколу, ESM запускає IIS Certificate Wizard. Ця програма перевіряє, чи не запитували чи коли-небудь SSL-сертифікат за допомогою Microsoft IIS. Щоб запросити сертифікат для застосування в Exchange, необхідні адміністративні привілеї на сервері Exchange, а використовувана обліковий запис повинен мати право запитувати сертифікат від CA.

Після того як екран Welcome закриється, потрібно вказати, що саме слід зробити. Якщо запитується сертифікат для віртуального сервера, у якого сертифікат поки відсутня, користувачеві пропонується на вибір приєднати існуючий сертифікат до віртуального сервера, імпортувати резервну копію сертифіката або запросити новий сертифікат. Якщо вирішено модифікувати існуючий сертифікат, майстер сертифікації запропонує зробити вибір між відновленням сертифіката, видаленням сертифіката з віртуального сервера і запитом на отримання нового сертифікату. Припустимо, нам потрібен запит на отримання нового сертифікату. Після клацання Create a new certificate виконується наступна процедура.

  • На сторінці Delayed Or Immediate Request слід вибрати використання Remote Procedure Call (RPC), щоб відіслати запит в CA, якщо він включений, або зберегти запит у форматі Public-Key Cryptography Standards (PKCS) # 10 - стандартному форматі для запиту сертифіката. Якщо є власний внутрішній CA і він функціонує, потрібно вибрати Send the request immediately to an online certification authority і натиснути Next. При використанні зовнішнього центру CA або якщо внутрішній CA вимкнений, необхідно вибрати Prepare the request now, but send it later і натиснути Next для генерації файлу PKCS # 10, який згодом буде відісланий в CA.
  • Майстер пропонує заповнити ім'я та довжину ключа сертифіката, як показано на Екрані 1. Хоча Windows 2000 підтримує роботу з ключами довжиною 512 розрядів, вони занадто короткі для забезпечення безпечної роботи; завжди слід вибирати довжину ключа принаймні тисячу двадцять чотири розряду. Потім потрібно клацнути Next.
  • Майстер просить ідентифікувати Organization і Organizational Unit (OU). Названі атрибути будуть закодовані в сертифікаті, тому дуже важливо вказати їх правильно. При введенні цієї інформації слід ще раз переконатися, що все написано правильно. І лише потім можна натиснути Next.
  • Майстер просить вказати загальне ім'я сайту, Common Name (CN). CN - це повністю певне ім'я домену сервера, Fully Qualified Domain Name (FQDN), як воно з'являється при роботі в Internet. Наприклад, якщо сервер SMTP - exch-smtp-sea-1.fabrikam.corp, а його зовнішнє DNS-ім'я - mail1.fabrikam.com, необхідно вказати mail1.fabrikam.com. Якщо CN станції зміниться, буде потрібно новий сертифікат. Необхідно переконатися, що ім'я DNS вказано вірно: якщо допустити помилку (т. Е. Якщо реальне FQDN і дані сертифікати не відповідають один одному), клієнтські програми, такі як Microsoft Internet Explorer (IE), будуть повідомляти, що сертифікат неправильний.
  • На сторінці Geographical Information потрібно вказати країну (або регіон), штат (або провінцію), а також місто, яке слід прописати в сертифікаті. Ці дані в подальшому не перевіряються, але сертифікат буде повідомляти про них.

До цього моменту процедура запиту сертифікату не залежить від того, включений CA або вимкнений. Після введення даних про географічне положення для запиту в оперативному режимі необхідно вказати CA зі списку доступних програмі - ініціатору запиту. Якщо CA, який передбачається використовувати, в списку відсутня, він не може пропонуватися для видачі сертифіката. Слід вибрати CA, потім клацнути Next. З'явиться підсумковий екран з зазначеними при формуванні запиту параметрами сертифіката; потрібно клацнути Next ще раз для відправки запиту. Якщо запит успішно виконується, сертифікат встановлюється автоматично і можна приступати до настройки TLS.

Використання CA незалежної компанії

Якщо обраний режим Prepare the request now, but send it later для сертифікації через центр CA, що знаходиться за межами мережі, або через автономний CA, який не інтегрований в Active Directory (AD), подальша процедура буде виглядати дещо інакше. Після отримання інформації про географічне положення майстер запропонує зберегти конфігурацію запиту в файлі. Вміст файлу - відкритий (незашифрований) текст в форматі Base64 Encoded Pkcs # 10. Після збереження цього файлу необхідно передати його до відповідного центру CA, зазвичай через Web-інтерфейс. Деталі самого інтерфейсу залежать від CA. Так, наприклад, розрізняють інтерфейси від Thawte, VeriSign і Comodo? S InstantSSL, виглядають вони по-різному. На більшості Web-сайтів незалежних центрів сертифікації є набір інструкцій щодо заповнення вимоги на сертифікат.

Microsoft CA також приймає запити PKCS # 10 через Web-інтерфейс. Ось як протікає процес звернення до CA і установка отриманого сертифіката.

  • На сервері Exchange слід відкрити IE і перейти на http: // yourCA / certsrv, де yourCA - це ім'я NetBIOS або ім'я DNS-центру CA. На екрані з'являється сторінка запрошення. Потрібно вибрати Request a certificate і натиснути Next.
  • На сторінці Choose Request Type (див. Екран 2) задається питання про тип запиту. Оскільки нам потрібно сертифікат для віртуального сервера і у нас є збережений запит, слід вибрати Advanced request і клацнути Next. Список User certificate request призначений для сертифікації кінцевих користувачів.
  • Сторінка Advanced Certificate Requests пропонує три можливості: сформувати новий запит за формою, що надається в інтерфейсі CA, скористатися заздалегідь підготовленим запитом PKCS # 10 або запросити сертифікат для користувачів смарт-карт. Оскільки ми хочемо задіяти існуючий запит, слід вибрати Submit для використання готового файлу Base64 Encoded Pkcs # 10 або оновити вміст запиту за допомогою файлу формату Base64 Encoded Pkcs # 7, після чого натиснути Next.
  • На сторінці Submit A Saved Request, представленої на Екрані 3, показано, звідки береться підготовлений для обробки запит. За допомогою Notepad потрібно відкрити файл PKCS # 10 на комп'ютері, з якого була запущена програма браузера. Необхідно скопіювати вміст файлу і вставити його в текстовий блок Saved Request. Якщо сервер сертифікації в настройках системи зазначений як надійний вузол, можна скористатися посиланням Browse для пошуку і вивантаження файлу запиту. Слід клацнути Submit, і система відішле запит в CA для обробки.

Як тільки на сторінці Submission Confirmation з'явиться відповідне повідомлення, необхідно буде повернутися в CA для перевірки статусу запиту і отримання створеного сертифіката. Залежно від того, використовується корпоративний або автономний CA, сертифікат може бути виданий автоматично або ж знадобиться участь адміністратора. Додаткову інформацію про відмінності корпоративного і автономного CA можна знайти в документації Certificate Services в Windows Server Help. Для цього потрібно повернутися на сторінку CA Welcome за адресою http: // servername / certsrv, де servername - ім'я вашого сервера. Необхідно вибрати Check on a pending certificate і клацнути Next. CA показує список всіх запитів, що стоять в черзі на обробку. Слід вибрати свій запит і клацнути Next.

Що з'явиться на екрані, залежить від того, чи видав CA сертифікат. Якщо ще немає, на сторінці CA буде інформація про те, що запит знаходиться в черзі на виконання. В цьому випадку треба ще раз підтвердити запит. Опис процедури підтвердження запиту за допомогою оснастки Microsoft Management Console (MMC) Certificate Services наведено в урізанні «Підтвердження запиту на отримання сертифіката» . Якщо CA видав сертифікат, з'явиться сторінка, вид якої наведено на Екрані 4.

  • Сторінка може здатися не зовсім звичайної, оскільки явної посилання на зразок Download my new certificate тут немає. Слід клацнути Download CA certificate і зберегти файл на сервері Exchange. За замовчуванням для ESM сертифікат зберігається в кодуванні Distinguished Encoding Rules (DER), тому важливо переконатися, що для збереження в файлі вказано саме цей формат сертифіката.

Після збереження сертифіката все готово для його прив'язки до віртуального сервера. Потрібно повернутися в ESM, знайти віртуальний сервер, для якого запитували сертифікат, і відкрити вікно властивостей сервера. На вкладці Access потрібно клацнути Certificate для запуску програми IIS Certificate Wizard. У цей момент майстер повідомляє статус запиту - pending; вибираємо Process the pending request and install the certificate. На наступній сторінці необхідно вказати шлях до файлу сертифіката, який був завантажений, і клацнути Next. ESM декодує сертифікат і показує підсумковий екран з його розшифровкою - додатковий засіб перевірки перед установкою сертифіката. Якщо все правильно, потрібно клацнути Next і Finish для запуску процедури встановлення продукта. Потрібно переконатися, що сертифікат встановлено. Для цього на вкладці Access слід перевірити статус кнопки Communications - вона доступна тільки в тому випадку, коли сертифікат встановлений на віртуальному сервері.

включення STARTTLS

Отримавши сертифікат, можна приступати до захисту трафіку SMTP. Тут є три варіанти: задати використання TLS для всієї вихідної пошти, для зазначених доменів або ж вимагати, щоб всі сервери, що встановлюють з вами з'єднання, використовували TLS. Ці настройки не залежать одна від одної, тому їх можна задіяти як окремо, так і в різних поєднаннях. Щоб включити TLS для всього вихідного поштового трафіку на обраному віртуальному сервері SMTP, слід перейти на вкладку Delivery на сторінці Properties віртуального сервера. Потім потрібно натиснути кнопку Outbound Security - на екрані з'явиться однойменне вікно (див. Екран 5). Необхідно встановити прапорець TLS encryption і натиснути ОК. Однак слід пам'ятати, що ця настройка проявить себе тільки при обміні повідомленнями Exchange з хостами, що підтримують TLS. Встановлене обмеження має небажаний ефект, який виражається в тому, що поштові повідомлення, відправлені на інші хости (без підтримки TLS), залишаються в черзі на доставку необмежений час або до тих пір, поки не закінчиться інтервал повторного відправлення і не буде отримано звіт про неможливість доставки відправленого повідомлення (Nondelivery Report - NDR).

Самий розумний підхід - використовувати коннектори SMTP з підтримкою TLS для зазначених доменів. Практично у всіх ситуаціях краще обмежувати вихідний трафік для тих доменів, про які напевно відомо, що вони підтримують TLS. Встановити, чи підтримує домен TLS, можна в режимі telnet станом 25-го порту поштового сервера домена, запустивши команду SMTP EHLO з командного рядка. Якщо у відповіді присутній STARTTLS, значить, домен підтримує TLS. Найпростіший спосіб організувати використання TLS полягає в створенні конекторів SMTP для доменів, що підтримують TLS. Зробити це можна в контейнері ESM Routing Groups. При створенні нового коннектора (або зміні властивостей існуючого) необхідно виконати два дуже важливих дії: переконатися, що на вкладці Address Space домени вказані вірно, і встановити підтримку TLS на вкладці Advanced (для цього потрібно перейти на вкладку Advanced, клацнути Outbound Security і встановити прапорець TLS encryption).

Активізація TLS для вхідного трафіку не складніше щойно описаної процедури. Потрібно перейти на вкладку Access у вікні властивостей віртуального сервера і клацнути Communication в командній групі Secure Communication. У вікні Security, як показано на Екрані 6, можна включити підтримку TLS з довжиною ключа 40 розрядів (за замовчуванням) або вказати використання довжини ключа 128 розрядів, що я і рекомендую зробити. Потрібно мати на увазі, що установка прапорця Require secure channel означає буквально наступне: сервери, які не підтримують TLS або не можуть прочитати настройки TLS вашого сервера, не передаватимуть на нього поштові повідомлення. Слід бути уважним, встановлюючи Require secure channel; якщо вихідні повідомлення регулярно пропадають, треба задуматися, а чи варто підвищена секретність втрачених повідомлень.

Проблеми при роботі з TLS

Після засекречування вихідного трафіку потрібно звернути увагу на серверні черзі. Деякі системи (в основному це стосується варіацій на тему UNIX Sendmail) будуть відмовлятися встановлювати TLS-з'єднання з системами, які мають «самоподпісанного» сертифікати, тоді як інші спочатку сприймуть STARTTLS, але потім з різних причин не зможуть виконати умов і налаштувань безпеки. Якщо який-небудь сервер не зможе виконати TLS-підключення та якщо він або інші системи при цьому вимагають використання TLS, поштові повідомлення на такі системи відправити не вдасться.

Якщо після включення TLS виявилося, що для поштових повідомлень при відправленні їх на певну систему створюються резервні копії, потрібно перевірити, чи не відбувається це через збої TLS. В такому випадку слід встановити, чому TLS дає збій. Необхідно перевірити журнали SMTP і журнали System і Application. Якщо це не прояснить ситуацію, потрібно зв'язатися з адміністратором віддаленої системи.

Як убезпечити поштовий трафік SMTP

Використання Transport Layer Security

Через те що при відправленні листів в стандарті SMTP не використовується ні шифрування, ні процедура аутентифікації, будь-яке повідомлення є доступним для перегляду. Рішення на стороні клієнта, такі, наприклад, як Secure MIME (S / MIME) або Pretty Good Privacy (PGP), можуть допомогти вирішити проблему захисту пошти, але вони вимагають участі в цій процедурі самих користувачів. Основний ділянку, де слід було б зосередити зусилля щодо забезпечення безпеки, - захист трафіку SMTP. Якщо вдасться убезпечити SMTP, то в принципі можна буде досягти стовідсоткової безпеки поштового трафіку, неважливо - породжується він на даному сервері або закінчується.

Microsoft Exchange Server передбачає кілька способів забезпечення безпеки поштового трафіку. Один з них полягає в обов'язковому використанні Secure Sockets Layer (SSL) for SMTP для наявних з'єднань. Однак застосування цього способу викликає деякі проблеми. За замовчуванням всі сервери SMTP використовують 25-й порт. Але якщо для 25-го порту застосовується SSL, то інші сервери, які не підтримують SSL, вже не зможуть встановити з'єднання з даним сервером через 25-й порт. А якщо скористатися нестандартним номером порту, решта сервери взагалі не зможуть виявити його.

Проблему можна спробувати обійти. Команда STARTTLS (вона входить до складу Extended SMTP - ESMTP) дозволяє клієнту і серверу SMTP розпізнати факт застосування Transport Layer Security (TLS) для звичайного SMTP-з'єднання. Учасник з'єднання на будь-якому його кінці може провести аутентифікацію свого партнера або ж TLS-з'єднання може використовуватися виключно як секретний канал зв'язку. Як би там не було, у такого підходу є три важливі переваги.

  • Відсутня перетин з іншими серверами і клієнтами. Ті клієнти, які підтримують функцію STARTTLS, можуть її використовувати; ті, хто не може, продовжують працювати з незахищеним трафіком SMTP.
  • Гнучкість рішення. Якщо клієнт може задіяти TLS з SMTP, сервер автоматично запитує TLS-підключення при зверненні до решти серверів і сам відгукується на запити про TLS-з'єднанні. Припустимо, що який-небудь зовнішній сервер запустив процес узгодження абонентів, в цьому випадку пошта автоматично стає захищеною. Проте я б порадив адміністраторам змушувати користувачів включати параметр SSL / TLS на поштовому клієнті.
  • TLS-шифрування SMTP захищає заголовки повідомлень, це додатковий ступінь захисту від програм-аналізаторів трафіку, без якої зловмисник зміг би без труднощів встановити, хто і як часто пов'язується один з одним.

Одне важливе попередження: TLS не захищає повідомлення на всьому протязі з'єднання, з кінця в кінець. Іншими словами, повідомлення не захищене в разі його зберігання на станції клієнта або при пересиланні з клієнта на сервер (якщо тільки клієнт сам не підтримує TLS). TLS захищає повідомлення, лише поки воно пересилається між двома серверами, що підтримують TLS.

Запит на SSL-сертифікацію

Перш ніж почати використовувати TLS з SMTP, необхідно отримати і встановити сертифікат для SMTP-сервера. Якщо у вас вже є власний центр сертифікації, Certificate Authority (CA), запит на отримання SSL-сертифіката не викликає ускладнень, якщо ж ні, тоді необхідно зберегти запит на сертифікат у файлі і передати його в кращий CA. Про те, як встановити Microsoft CA або скористатися зовнішнім CA для інфраструктури відкритого ключа (Public Key Infrastructure - PKI), розказано в статті Certificate Services в довіднику Windows Server Help. Припустимо, що у нас є доступ до CA і необхідно скласти запит і встановити сертифікат SSL для роботи з Microsoft Outlook Web Access (OWA), IMAP, POP або SMTP.

Базовий механізм видачі сертифікатів для всіх перерахованих протоколів однаковий, хоча в цій статті розглядається тільки SMTP. Процедуру запиту сертифікату ми ініціюємо з Exchange System Manager (ESM). У вікні дерева ESM потрібно відшукати свій сервер і вибрати Protocols і SMTP. Потім слід відкрити контекстне меню віртуального сервера і вибрати Properties; на вкладці Access з'явиться кнопка Certificate, яка включається щоразу при запуску ESM на сервері Exchange. Оскільки відкритий ключ, що відноситься до даного сертифікату, генерується на локальній машині, сертифікат, створений на станції адміністратора, не має ніякого сенсу.

Для формування запиту на отримання сертифіката при роботі з OWA можна використовувати Internet Services Manager (ISM) 5.0. Однак задіяти ESM для запиту POP- або IMAP-сертифіката простіше, оскільки ці сертифікати можна зажадати безпосередньо в діалоговому вікні Properties віртуального сервера, так що ми їм і скористаємося. Щоб вимагати сертифікат, потрібно просто клацнути Certificate.

отримання сертифікату

Коли кнопку Certificate клацають на сервері, у якого відсутній сертифікат для специфічного протоколу, ESM запускає IIS Certificate Wizard. Ця програма перевіряє, чи не запитували чи коли-небудь SSL-сертифікат за допомогою Microsoft IIS. Щоб запросити сертифікат для застосування в Exchange, необхідні адміністративні привілеї на сервері Exchange, а використовувана обліковий запис повинен мати право запитувати сертифікат від CA.

Після того як екран Welcome закриється, потрібно вказати, що саме слід зробити. Якщо запитується сертифікат для віртуального сервера, у якого сертифікат поки відсутня, користувачеві пропонується на вибір приєднати існуючий сертифікат до віртуального сервера, імпортувати резервну копію сертифіката або запросити новий сертифікат. Якщо вирішено модифікувати існуючий сертифікат, майстер сертифікації запропонує зробити вибір між відновленням сертифіката, видаленням сертифіката з віртуального сервера і запитом на отримання нового сертифікату. Припустимо, нам потрібен запит на отримання нового сертифікату. Після клацання Create a new certificate виконується наступна процедура.

  • На сторінці Delayed Or Immediate Request слід вибрати використання Remote Procedure Call (RPC), щоб відіслати запит в CA, якщо він включений, або зберегти запит у форматі Public-Key Cryptography Standards (PKCS) # 10 - стандартному форматі для запиту сертифіката. Якщо є власний внутрішній CA і він функціонує, потрібно вибрати Send the request immediately to an online certification authority і натиснути Next. При використанні зовнішнього центру CA або якщо внутрішній CA вимкнений, необхідно вибрати Prepare the request now, but send it later і натиснути Next для генерації файлу PKCS # 10, який згодом буде відісланий в CA.
  • Майстер пропонує заповнити ім'я та довжину ключа сертифіката, як показано на Екрані 1. Хоча Windows 2000 підтримує роботу з ключами довжиною 512 розрядів, вони занадто короткі для забезпечення безпечної роботи; завжди слід вибирати довжину ключа принаймні тисячу двадцять чотири розряду. Потім потрібно клацнути Next.
  • Майстер просить ідентифікувати Organization і Organizational Unit (OU). Названі атрибути будуть закодовані в сертифікаті, тому дуже важливо вказати їх правильно. При введенні цієї інформації слід ще раз переконатися, що все написано правильно. І лише потім можна натиснути Next.
  • Майстер просить вказати загальне ім'я сайту, Common Name (CN). CN - це повністю певне ім'я домену сервера, Fully Qualified Domain Name (FQDN), як воно з'являється при роботі в Internet. Наприклад, якщо сервер SMTP - exch-smtp-sea-1.fabrikam.corp, а його зовнішнє DNS-ім'я - mail1.fabrikam.com, необхідно вказати mail1.fabrikam.com. Якщо CN станції зміниться, буде потрібно новий сертифікат. Необхідно переконатися, що ім'я DNS вказано вірно: якщо допустити помилку (т. Е. Якщо реальне FQDN і дані сертифікати не відповідають один одному), клієнтські програми, такі як Microsoft Internet Explorer (IE), будуть повідомляти, що сертифікат неправильний.
  • На сторінці Geographical Information потрібно вказати країну (або регіон), штат (або провінцію), а також місто, яке слід прописати в сертифікаті. Ці дані в подальшому не перевіряються, але сертифікат буде повідомляти про них.

До цього моменту процедура запиту сертифікату не залежить від того, включений CA або вимкнений. Після введення даних про географічне положення для запиту в оперативному режимі необхідно вказати CA зі списку доступних програмі - ініціатору запиту. Якщо CA, який передбачається використовувати, в списку відсутня, він не може пропонуватися для видачі сертифіката. Слід вибрати CA, потім клацнути Next. З'явиться підсумковий екран з зазначеними при формуванні запиту параметрами сертифіката; потрібно клацнути Next ще раз для відправки запиту. Якщо запит успішно виконується, сертифікат встановлюється автоматично і можна приступати до настройки TLS.

Використання CA незалежної компанії

Якщо обраний режим Prepare the request now, but send it later для сертифікації через центр CA, що знаходиться за межами мережі, або через автономний CA, який не інтегрований в Active Directory (AD), подальша процедура буде виглядати дещо інакше. Після отримання інформації про географічне положення майстер запропонує зберегти конфігурацію запиту в файлі. Вміст файлу - відкритий (незашифрований) текст в форматі Base64 Encoded Pkcs # 10. Після збереження цього файлу необхідно передати його до відповідного центру CA, зазвичай через Web-інтерфейс. Деталі самого інтерфейсу залежать від CA. Так, наприклад, розрізняють інтерфейси від Thawte, VeriSign і Comodo? S InstantSSL, виглядають вони по-різному. На більшості Web-сайтів незалежних центрів сертифікації є набір інструкцій щодо заповнення вимоги на сертифікат.

Microsoft CA також приймає запити PKCS # 10 через Web-інтерфейс. Ось як протікає процес звернення до CA і установка отриманого сертифіката.

  • На сервері Exchange слід відкрити IE і перейти на http: // yourCA / certsrv, де yourCA - це ім'я NetBIOS або ім'я DNS-центру CA. На екрані з'являється сторінка запрошення. Потрібно вибрати Request a certificate і натиснути Next.
  • На сторінці Choose Request Type (див. Екран 2) задається питання про тип запиту. Оскільки нам потрібно сертифікат для віртуального сервера і у нас є збережений запит, слід вибрати Advanced request і клацнути Next. Список User certificate request призначений для сертифікації кінцевих користувачів.
  • Сторінка Advanced Certificate Requests пропонує три можливості: сформувати новий запит за формою, що надається в інтерфейсі CA, скористатися заздалегідь підготовленим запитом PKCS # 10 або запросити сертифікат для користувачів смарт-карт. Оскільки ми хочемо задіяти існуючий запит, слід вибрати Submit для використання готового файлу Base64 Encoded Pkcs # 10 або оновити вміст запиту за допомогою файлу формату Base64 Encoded Pkcs # 7, після чого натиснути Next.
  • На сторінці Submit A Saved Request, представленої на Екрані 3, показано, звідки береться підготовлений для обробки запит. За допомогою Notepad потрібно відкрити файл PKCS # 10 на комп'ютері, з якого була запущена програма браузера. Необхідно скопіювати вміст файлу і вставити його в текстовий блок Saved Request. Якщо сервер сертифікації в настройках системи зазначений як надійний вузол, можна скористатися посиланням Browse для пошуку і вивантаження файлу запиту. Слід клацнути Submit, і система відішле запит в CA для обробки.

Як тільки на сторінці Submission Confirmation з'явиться відповідне повідомлення, необхідно буде повернутися в CA для перевірки статусу запиту і отримання створеного сертифіката. Залежно від того, використовується корпоративний або автономний CA, сертифікат може бути виданий автоматично або ж знадобиться участь адміністратора. Додаткову інформацію про відмінності корпоративного і автономного CA можна знайти в документації Certificate Services в Windows Server Help. Для цього потрібно повернутися на сторінку CA Welcome за адресою http: // servername / certsrv, де servername - ім'я вашого сервера. Необхідно вибрати Check on a pending certificate і клацнути Next. CA показує список всіх запитів, що стоять в черзі на обробку. Слід вибрати свій запит і клацнути Next.

Що з'явиться на екрані, залежить від того, чи видав CA сертифікат. Якщо ще немає, на сторінці CA буде інформація про те, що запит знаходиться в черзі на виконання. В цьому випадку треба ще раз підтвердити запит. Опис процедури підтвердження запиту за допомогою оснастки Microsoft Management Console (MMC) Certificate Services наведено в урізанні «Підтвердження запиту на отримання сертифіката» . Якщо CA видав сертифікат, з'явиться сторінка, вид якої наведено на Екрані 4.

  • Сторінка може здатися не зовсім звичайної, оскільки явної посилання на зразок Download my new certificate тут немає. Слід клацнути Download CA certificate і зберегти файл на сервері Exchange. За замовчуванням для ESM сертифікат зберігається в кодуванні Distinguished Encoding Rules (DER), тому важливо переконатися, що для збереження в файлі вказано саме цей формат сертифіката.

Після збереження сертифіката все готово для його прив'язки до віртуального сервера. Потрібно повернутися в ESM, знайти віртуальний сервер, для якого запитували сертифікат, і відкрити вікно властивостей сервера. На вкладці Access потрібно клацнути Certificate для запуску програми IIS Certificate Wizard. У цей момент майстер повідомляє статус запиту - pending; вибираємо Process the pending request and install the certificate. На наступній сторінці необхідно вказати шлях до файлу сертифіката, який був завантажений, і клацнути Next. ESM декодує сертифікат і показує підсумковий екран з його розшифровкою - додатковий засіб перевірки перед установкою сертифіката. Якщо все правильно, потрібно клацнути Next і Finish для запуску процедури встановлення продукта. Потрібно переконатися, що сертифікат встановлено. Для цього на вкладці Access слід перевірити статус кнопки Communications - вона доступна тільки в тому випадку, коли сертифікат встановлений на віртуальному сервері.

включення STARTTLS

Отримавши сертифікат, можна приступати до захисту трафіку SMTP. Тут є три варіанти: задати використання TLS для всієї вихідної пошти, для зазначених доменів або ж вимагати, щоб всі сервери, що встановлюють з вами з'єднання, використовували TLS. Ці настройки не залежать одна від одної, тому їх можна задіяти як окремо, так і в різних поєднаннях. Щоб включити TLS для всього вихідного поштового трафіку на обраному віртуальному сервері SMTP, слід перейти на вкладку Delivery на сторінці Properties віртуального сервера. Потім потрібно натиснути кнопку Outbound Security - на екрані з'явиться однойменне вікно (див. Екран 5). Необхідно встановити прапорець TLS encryption і натиснути ОК. Однак слід пам'ятати, що ця настройка проявить себе тільки при обміні повідомленнями Exchange з хостами, що підтримують TLS. Встановлене обмеження має небажаний ефект, який виражається в тому, що поштові повідомлення, відправлені на інші хости (без підтримки TLS), залишаються в черзі на доставку необмежений час або до тих пір, поки не закінчиться інтервал повторного відправлення і не буде отримано звіт про неможливість доставки відправленого повідомлення (Nondelivery Report - NDR).

Самий розумний підхід - використовувати коннектори SMTP з підтримкою TLS для зазначених доменів. Практично у всіх ситуаціях краще обмежувати вихідний трафік для тих доменів, про які напевно відомо, що вони підтримують TLS. Встановити, чи підтримує домен TLS, можна в режимі telnet станом 25-го порту поштового сервера домена, запустивши команду SMTP EHLO з командного рядка. Якщо у відповіді присутній STARTTLS, значить, домен підтримує TLS. Найпростіший спосіб організувати використання TLS полягає в створенні конекторів SMTP для доменів, що підтримують TLS. Зробити це можна в контейнері ESM Routing Groups. При створенні нового коннектора (або зміні властивостей існуючого) необхідно виконати два дуже важливих дії: переконатися, що на вкладці Address Space домени вказані вірно, і встановити підтримку TLS на вкладці Advanced (для цього потрібно перейти на вкладку Advanced, клацнути Outbound Security і встановити прапорець TLS encryption).

Активізація TLS для вхідного трафіку не складніше щойно описаної процедури. Потрібно перейти на вкладку Access у вікні властивостей віртуального сервера і клацнути Communication в командній групі Secure Communication. У вікні Security, як показано на Екрані 6, можна включити підтримку TLS з довжиною ключа 40 розрядів (за замовчуванням) або вказати використання довжини ключа 128 розрядів, що я і рекомендую зробити. Потрібно мати на увазі, що установка прапорця Require secure channel означає буквально наступне: сервери, які не підтримують TLS або не можуть прочитати настройки TLS вашого сервера, не передаватимуть на нього поштові повідомлення. Слід бути уважним, встановлюючи Require secure channel; якщо вихідні повідомлення регулярно пропадають, треба задуматися, а чи варто підвищена секретність втрачених повідомлень.

Проблеми при роботі з TLS

Після засекречування вихідного трафіку потрібно звернути увагу на серверні черзі. Деякі системи (в основному це стосується варіацій на тему UNIX Sendmail) будуть відмовлятися встановлювати TLS-з'єднання з системами, які мають «самоподпісанного» сертифікати, тоді як інші спочатку сприймуть STARTTLS, але потім з різних причин не зможуть виконати умов і налаштувань безпеки. Якщо який-небудь сервер не зможе виконати TLS-підключення та якщо він або інші системи при цьому вимагають використання TLS, поштові повідомлення на такі системи відправити не вдасться.

Якщо після включення TLS виявилося, що для поштових повідомлень при відправленні їх на певну систему створюються резервні копії, потрібно перевірити, чи не відбувається це через збої TLS. В такому випадку слід встановити, чому TLS дає збій. Необхідно перевірити журнали SMTP і журнали System і Application. Якщо це не прояснить ситуацію, потрібно зв'язатися з адміністратором віддаленої системи.

Якщо вирішити проблему не вдається, можна спробувати не допустити її. Хоча ядро ​​Exchange SMTP не підтримує установки TLS для доменів, можна створити ще один віртуальний сервер SMTP, в якому не використовується TLS, а потім зв'язати його з SMTP-коннектором. У властивостях коннектора потрібно вказати домен, з яким є проблеми зв'язку. Оскільки Exchange завжди віддає пріоритет явно прописаним маршрутами, пошта почне вирушати за вказаною адресою через даний коннектор, і все запрацює.

Поль Робішо - старший системний архітектор компанії EntireNet, має сертифікати MCSE і MCT. З ним можна зв'язатися за адресою: [email protected] .

Підтвердження запиту на отримання сертифіката

Якщо поштова статус самого першого запиту на отримання сертифіката, може виявитися, що статус запиту - pending (в процесі рішення). Тоді адміністратор повинен підтвердити обробку запиту. Це досить типова ситуація, оскільки при установці центру сертифікації Windows Certificate Authority (CA) в автономному режимі видача сертифікатів затримується до тих пір, поки адміністратор не видасть відповідний дозвіл (підтвердження). Такі установки CA за замовчуванням. Для перевірки статусу і підтвердження запиту використовується оснащення Microsoft Management Console (MMC) Certification Authority, яку необхідно запустити на сервері - центрі CA. Щоб перевірити стан очікують виконання запитів для підтвердження або відмови від їх подальшої обробки, потрібно виконати наступні дії.

  1. Запустити оснащення Certificate Services (Start, Programs, Administrative Tools, Certificate Authority).
  2. Перейти до вузла CA (дерево консолі, ліве вікно) і розкрити його. У вузлі п'ять каталогів: Revoked Certificates, Issued Certificates, Pending Requests, Failed Requests і Policy Settings.
  3. Клацнути Pending Requests. У правій частині консолі перераховані всі запити зі статусом pending. Слід відкрити контекстне меню запиту і вибрати в залежності від поставленого завдання All Tasks, Issue або All Tasks, Deny. Важливо переконатися, що зазначений саме той запит, який потрібен.

Оснащення Certificate Authority дозволяє виконати багато різних завдань, в тому числі відгук індивідуальних сертифікатів (контекстне меню сертифіката в каталозі Issued Certificates, потім All Tasks, Revoke Certificate) і настройку політики при видачі сертифікатів. Детальний опис можливостей оснащення Certificate Authority приведено в Windows 2000 Online Help.

Так, наприклад, розрізняють інтерфейси від Thawte, VeriSign і Comodo?
Так, наприклад, розрізняють інтерфейси від Thawte, VeriSign і Comodo?
Так, наприклад, розрізняють інтерфейси від Thawte, VeriSign і Comodo?

Новости