Как шифровать письма S/MIME

Version 1.0
Author: Christian Schmalfeld
Подписывайтесь на меня в Twitter

Кратко (TL;DR)

S/MIME использует пару ключей (публичный/приватный) для подписи и шифрования писем. Чтобы принимать зашифрованные письма, вам нужен приватный ключ и публичный ключ отправителя. Вы можете создать самоподписанный сертификат с помощью OpenSSL или сделать CA и подписать им сертификат. Для почтовых клиентов обычно нужен файл в формате .p12. В этой статье — пошагово, с проверками, сценариями отказа и практическими рекомендациями по безопасности.

Важно: самоподписанные сертификаты подходят для личного использования и тестов. Для массового доверия используйте сертификат от доверенного центра сертификации.

Основные варианты запроса (поисковое намерение)

Как зашифровать письмо S/MIME
Настройка SSL‑сертификата для почты
Создать самоподписанный сертификат для S/MIME
Экспорт .p12 для Thunderbird/Outlook
Как подписывать электронные письма

1 Предварительное замечание

S/MIME работает не так, как многие ожидают. Наличие собственного действительного сертификата не позволяет вам автоматически отправлять зашифрованные письма всем. Сертификат даёт вам возможность принимать письма, зашифрованные вашим публичным ключом. Если вы хотите отправить зашифрованное письмо другому человеку, вам нужен его публичный ключ. Публичный ключ можно отправить как часть подписанного письма.

S/MIME — это парная криптосистема: публичный и приватный ключ. Публичный ключ передаётся отправителю, приватный хранится у вас и используется для расшифровки входящих сообщений.

Шаги по импорту сертификатов в Thunderbird одинаковы на Linux, Windows и macOS.

2 Создание SSL‑сертификата самостоятельно

Собственная генерация сертификата даёт приватность ваших персональных данных. Для подписи и расшифровки писем создание отдельного центра сертификации (CA) не обязательно, но при необходимости можно его создать и подписывать сертификаты локально.

2.1 Установка OpenSSL

На Debian/Ubuntu-подобных системах:

sudo apt-get install openssl

После установки можно войти в интерактивную оболочку OpenSSL командой:

openssl

В этой статье команды выполняются в обычном shell. Если вы используете другую дистрибутив или ОС, команды установки отличаются.

2.2 Создание самоподписанного сертификата

Создайте папку для файлов сертификата и перейдите в неё. Пример для пользователя ctest:

mkdir /home/ctest/ssl
cd /home/ctest/ssl

Сгенерируйте приватный ключ (RSA 4096 бит с шифрованием паролем):

openssl genrsa -des3 -out cert.key 4096

Вы будете запрошены ввести passphrase для ключа.

Создайте запрос на подпись сертификата (CSR):

openssl req -new -key cert.key -out cert.csr

При вводе данных в поле Common Name не указывайте общепринятые имена серверов (например, smtp.gmail.com), чтобы клиент не воспринял ваш сертификат как попытку выдать себя за известный сервер. Вводите корректный адрес электронной почты.

Подпишите CSR собственным ключом и получите сертификат (действителен 365 дней в примере):

openssl x509 -req -days 365 -in cert.csr -signkey cert.key -out cert.crt

Почтовые клиенты ожидают формат PKCS#12 (.p12). Экспортируйте сертификат и ключ в один файл:

openssl pkcs12 -export -in cert.crt -inkey cert.key -name "Your Name" -out cert.p12

Запомните пароль экспорта — он понадобится при импорте в почтовый клиент.

Проверьте наличие файлов:

ls -l

Пример вывода (оставлен как справочный вывод команды):

ctest-System-Product-Name ssl # ls -l  
total 20  
-rw-r--r-- 1 root root 2004 2011-11-28 12:52 cert.crt  
-rw-r--r-- 1 root root 1752 2011-11-28 12:32 cert.csr  
-rw-r--r-- 1 root root 3311 2011-11-28 12:31 cert.key  
-rw-r--r-- 1 root root 4290 2011-11-28 12:53 cert.p12  
ctest-System-Product-Name ssl #

Если каких‑то файлов не хватает — вернитесь к предыдущим шагам и повторите их.

2.3 Вариант: создать собственный центр сертификации и подписывать сертификаты

Если вы хотите централизованно выпускать сертификаты для группы пользователей или тестовой инфраструктуры, можете создать свой CA. Это необязательно для простого шифрования/подписи почты, но даёт большую гибкость в локальной среде.

Сгенерируйте ключ для CA:

openssl genrsa -des3 -out ca.key 4096

Создайте самоподписанный сертификат CA:

openssl req -new -x509 -days 365 -key ca.key -out ca.crt

Задайте отличающийся Common Name для CA, который не совпадает с Common Name создаваемого пользователя.

Сгенерируйте ключ и CSR для пользователя (как в разделе 2.2):

openssl genrsa -des3 -out cert.key 4096
openssl req -new -key cert.key -out cert.csr

Подпишите CSR вашим CA:

openssl x509 -req -days 365 -in cert.csr -CA ca.crt -CAkey ca.key -set_serial 00 -out cert.crt

Экспортируйте в .p12 как ранее:

openssl pkcs12 -export -in cert.crt -inkey cert.key -name "Your Name" -out cert.p12

Проверьте папку:

ls -l

Пример вывода:

ctest-System-Product-Name ssl # ls -l  
total 28  
-rw-r--r-- 1 root root 2041 2011-11-28 13:44 ca.crt  
-rw-r--r-- 1 root root 3311 2011-11-28 13:43 ca.key  
-rw-r--r-- 1 root root 1793 2011-11-28 13:45 cert.crt  
-rw-r--r-- 1 root root 1651 2011-11-28 13:44 cert.csr  
-rw-r--r-- 1 root root 3311 2011-11-28 13:44 cert.key  
-rw-r--r-- 1 root root 4122 2011-11-28 13:45 cert.p12  
ctest-System-Product-Name ssl #

Если что‑то отсутствует — проверьте предыдущие шаги.

3 Импорт сертификата в почтовый клиент (общие замечания)

Почтовые клиенты (Thunderbird, Outlook, Apple Mail) обычно импортируют .p12 и требуют пароль экспорта.
Чтобы отправлять зашифрованные письма конкретному адресату, у вас должен быть его сертификат (публичный ключ). Получить его проще всего — попросить контакт прислать вам подписанное письмо.
Для приёма зашифрованных писем достаточно корректно импортировать .p12, содержащий ваш приватный ключ и сертификат.

Важно проверять, что почтовый клиент использует ваш сертификат как «идентификацию» для подписи и отдельно для шифрования. В некоторых клиентах это разные настройки.

4 Рекомендации по безопасности

Используйте длину ключа не менее 2048 бит; для большей безопасности — 3072 или 4096 бит.
Храните приватный ключ в защищённом месте и не передавайте его никому.
Используйте сильные пароли на экспорт .p12 и на сам ключ.
Для рабочей среды рассмотрите аппаратные токены (YubiKey, смарт‑карты) для хранения приватных ключей.
Ограничьте срок действия сертификата (например, 1 год) и планируйте ротацию.

5 Когда метод не работает или ограничен

Если у получателя нет вашего публичного ключа, он не сможет прочесть зашифрованное вами письмо.
Серверы web‑mail (например, Gmail в веб‑интерфейсе) могут не поддерживать S/MIME в базовой конфигурации. Часто требуется корпоративный тариф или дополнительная настройка.
Самоподписанные сертификаты не будут автоматически доверены другими, пока их не добавят в доверенные хранилища.

6 Альтернативные подходы

PGP/OpenPGP: альтернатива S/MIME с другим методом управления ключами.
TLS для транспорта (STARTTLS): защищает канал между серверами, но не хранит письмо зашифрованным в почтовом ящике.
End‑to‑end шифрование через мессенджеры: для быстрых конфиденциальных сообщений.

7 Практическая методология (мини‑план внедрения)

Сформируйте политику: кто в организации будет использовать S/MIME.
Выберите модель выдачи: централизованный CA или самоподписанные сертификаты пользователей.
Сгенерируйте ключи и сертификаты по инструкции.
Экспортируйте .p12 и импортируйте в почтовые клиенты.
Обработайте обучение пользователей: как обмениваться подписанными письмами.
Настройте ротацию и отзыв сертификатов.

8 Чек‑лист для администратора и для пользователя

Администратор:

Определить модель выпуска сертификатов.
Настроить каталог хранения CA (если применяется).
Подготовить инструкции по экспорту/импорту .p12.
Проверить совместимость почтового сервера/клиентов.

Пользователь:

Сгенерировать ключ и сертификат (или получить от CA).
Экспортировать .p12 и сохранить пароль.
Импортировать .p12 в почтовый клиент.
Отправить подписанное письмо контакту для обмена публичными ключами.

9 Критерии приёмки

Пользователь может подписывать исходящие письма.
Пользователь может расшифровывать входящие письма, зашифрованные его публичным ключом.
Получатели доверяют сертификат или добавили самоподписанный сертификат в доверенные.
Процесс создания и импорта документирован и воспроизводим.

10 Отладка и частые ошибки

Не открывается .p12 при импорте — проверьте пароль экспорта.
Клиент не видит сертификат для шифрования — проверьте, что в контакте есть подписанное письмо от получателя (публичный ключ).
Сертификат отмечен как недоверенный — добавьте CA в доверенные хранилища, либо используйте сертификат от доверенного центра.

11 Тонкости для популярных клиентов (общие советы)

Thunderbird: импорт .p12 через настройки учётной записи → Безопасность → Просмотр сертификатов.
Outlook (Windows): импорт .p12 через «Сертификаты пользователей» в управлении Windows либо через Outlook → Trust Center.
Apple Mail: импорт .p12 в Keychain Access, затем назначить сертификат учётной записи в Mail.

Пошаговые UI-инструкции зависят от версии клиента; всегда проверяйте официальную документацию.

12 Мини‑глоссарий

S/MIME: стандарт для подписания и шифрования email.
CSR: запрос на подпись сертификата.
CA: центр сертификации.
PKCS#12 (.p12): формат, объединяющий приватный ключ и сертификат.

13 Безопасное использование и рекомендации по политике

Отключайте экспорт приватных ключей для критичных пользователей (используйте аппаратные носители).
Установите процедуру отзыва сертификатов при компрометации.
Логируйте и проверяйте использование сертификатов в корпоративной почтовой инфраструктуре.

14 Шаблон простой процедуры (SOP) по созданию и импорту сертификата

Создать рабочую папку и установить OpenSSL.
Сгенерировать приватный ключ и CSR.
Подписать CSR (самоподпись или CA).
Экспорт в .p12.
Сохранить резервную копию cert.key в зашифрованном хранилище.
Импортировать .p12 в почтовый клиент и проверить подпись/шифрование тестовым письмом.

15 Часто задаваемые вопросы

Как отправить кому‑то мой публичный ключ?
Отправьте подписанное письмо — в нём будет ваш публичный ключ, и контакту останется добавить его в адресную книгу.

Может ли злоумышленник подделать мой сертификат?
Самоподписанный сертификат проще подделать, если злоумышленник пытается выдать себя за вас для тех, кто вам не доверяет. Для повышения доверия используйте сертификаты от зарекомендовавших себя CA.

Конец и основные выводы

S/MIME — простой и надёжный способ подписывать и шифровать почту при условии правильной организации обмена публичными ключами. Для личного использования достаточно самоподписанных сертификатов, для корпоративного — централизованного CA и политики управления ключами. Поддерживайте высокую гигиену управления приватными ключами и планируйте ротацию сертификатов.

Краткие выводы: