Перейдите в каталог / Volumes / Server1 / Craft / 2OQ / Dom_Curr / EN
:
cd /Volumes/Server1/Craft/2OQ/Dom_Curr/EN
Затем выполните следующее:
for D in CT_*
do
mkdir -p ${D}/5Misc/Permissions
done
Это добавит подкаталоги в каждый каталог в Каталог EN
, который начинается с CT_
Вы видите саму цель сертификатов: предотвращение случайного подключения к серверу, который не соответствует вашим ожиданиям (mail.example.com
вместо beta.example.com
). Вы должны настроить сертификат, выданный для домена, к которому вы подключаетесь, т.е. если почтовый клиент подключается к beta.example.com
, вам потребуется сертификат для beta.example.com
.
Либо получите другой сертификат для beta.example.com
(или включите его в качестве альтернативного имени субъекта) или укажите mail.example.com
на IP-адрес beta.example.com
.
Клиент настроен на подключение к mail.example.com
.
Сервер, к которому он подключается, утверждает (в сертификате), что это beta.example.com
.
Поскольку mail.example.com
не совпадает с beta.example.com
, клиент жалуется на несоответствие. Это полностью задумано.
Чтобы это работало, вам нужно настроить почтовый сервер для предоставления сертификата, который включает альтернативное имя субъекта, совпадающее с именем хоста, на которое указывает клиент. Вопрос о том, как это имя хоста преобразуется в IP-адрес, не имеет значения.
Раньше имя хоста помещалось в поле «Общее имя» сертификата, но эта практика устарела. Вы по-прежнему можете указать имя хоста в качестве CN сертификата, если хотите, но для лучшей совместимости вам необходимо также указать его как SAN. Я полагаю, что большинство ЦС представят вам CN как SAN как услугу, если вы сами этого не сделаете в своем CSR, но есть риск, что некоторые этого не сделают; проверьте свой сертификат.
Если вы должны использовать один и тот же сертификат для Postfix и Dovecot, но по какой-то причине вы хотите опубликовать для них разные имена хостов (например, smtp.example .com
и pop.example.com
), то вам нужен сертификат, действительный для обоих задействованных имен хостов. Это можно сделать с помощью сертификата с несколькими именами хостов или сертификата с подстановочными знаками (*.example.com
).
Кроме того, MX (почтовый обменник) DNS RR действительно важны только для входящих SMTP-соединений с почтовым сервером, обрабатывающим почту для определенного домена, где удаленный почтовый сервер изначально знает только домен получателя. Вполне допустимо иметь, например,
example.com. MX 0 mail.example.com.
mail.example.com. CNAME beta.example.com.
beta.example.com. A 192.0.2.123
, хотя на самом деле это не рекомендуется, потому что указание RR на неканонический RR может привести к тому, что некоторые распознаватели захлебнутся.Однако, если резолвер удаленной системы принимает его (большинство так и делает), вышеописанное практически аналогично тому, как если бы вы имели
example.com. MX 0 mail.example.com.
mail.example.com. A 192.0.2.123
В обоих случаях удаленный MTA (агент пересылки почты; в наши дни к другим почтовым серверам) будет подключаться к mail.example.com (поскольку это имя хоста MX, указанное в MX RR), и, следовательно, будет ожидать сертификат, действительный для mail.example.com.
Ваш MUA не будет обращаться к записям MX и в любом случае не узнает об этом; он будет сверяться с адресом (A
, AAAA
и в редких случаях может быть также A6
; A6 RR устарели, но какое-то время использовались для IPv6) записи любого имени хоста, которое вы ему даете в качестве сервера входящей (POP/IMAP) или исходящей (SMTP) почты.