Назад | Перейти на главную страницу

Постфикс: что мне следует использовать - сертификат snakeoil или сертификат https?

У меня есть сайт и установлен действующий подстановочный сертификат для обслуживания страниц HTTPS. Я только что установил postfix на своем хосте Ubuntu, и по умолчанию его конфигурация включает:

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

Могу я изменить эти snakeoil сертификаты на сертификаты, которые я купил? Если я могу, должен ли я?

Вы можете и должны (если вы не хотите использовать сертификат для конкретного хоста).

Технически вы можете использовать любой сертификат, в том числе snakoil. Это просто еще один самозаверяющий сертификат с несоответствующим идентификатором. Однако лучше всего использовать сертификат, который соответствует тому, что законный клиент будет использовать для связи с хостом. Это зависит от ваших настроек. Если люди пытаются достичь mail.example.com сертификат должен соответствовать mail.example.com. Если они пытаются достичь example.com он должен соответствовать этому. *.example.com Спички mail.example.com, но нет example.com. Не то чтобы я рекомендовал использовать чистый домен для такого рода вещей.

Кроме того, вы можете не быть уязвимыми для POODLE.
smtpd_tls_protocols = !SSLv2, !SSLv3
Это имеет большее значение, если вы выполняете аутентификацию, но в любом случае это хорошая идея.

Это зависит от того, что вы хотите, и деталей вашей настройки.

smtpd служба: у сертификата есть общее имя (CN), как вы знаете, с доменом, для которого он действителен. Скажи это example.com и *.example.com, как типичный случай для сертификатов, предназначенных для Интернета.

Если имя хоста почтового сервера mail.example.com (здесь имеет значение домен в MX-записи), сертификат, предоставленный почтовым сервером, действителен для example.com включая поддомены и проверка (если она выполнена) успешно. Если имя хоста почтового сервера (в MX-записи) не совпадает (например, externalservice.example.net), это не удастся.

В случае самозаверяющего сертификата CN, надеюсь, соответствует FQDN, но определенно не подписан доверенным сертификатом.

Так что оба варианта могут потерпеть неудачу. Убедитесь, что полное доменное имя почтового сервера соответствует CN сертификата (или наоборот). Кроме того, предоставьте цепочку сертификатов корневым центрам сертификации. См. Документацию для этого.

Но к сожалению это очень распространен использовать неподписанные и ненадежные самоподписанные, устаревшие сертификаты или вообще без сертификатов для почтовых серверов. Только небольшая часть работающих почтовых серверов имеет действительные сертификаты. Недавно я видел опрос, который показывает, что только около 5% или меньше действительно имеют действующий сертификат, но я не могу его найти в данный момент. Свяжу позже, когда найду.

В случае подчинение service, проверка имеет большее значение, так как реальные пользователи подключаются к службе и могут получить предупреждение о сертификате. MUA сравнивают настроенный домен для входящей и исходящей почты с используемым CommonName. То же, что и для smtp применяется здесь, но пользователи будут жаловаться, если они получат доверять предупреждения, или соединение не работает. Поскольку у вас есть подстановочный сертификат, вы можете безопасно использовать smtp.example.com как имя хоста для такого рода задач. Без подстановочного знака это не так просто.