Я купил два SSL-сертификата с подстановочными знаками для одного домена у Namecheap/Sectigo/Comodo. Я сгенерировал свои CSR обычным способом, используя openssl.
$ openssl req -newkey rsa:4096 -keyout example.com.rsa.key -out example.com.rsa.csr
$ openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out example.com.ecdsa.pem
$ openssl req -newkey ec:example.com.ecdsa.pem -keyout example.com.ecdsa.key -out example.com.ecdsa.csr
Я отправил CSR и получил каждый пакет сертификатов, включая .crt и .ca-bundle, все, как и ожидалось.
Мне удалось установить оба сертификата для использования Postfix. Каждому требовалась незашифрованная версия закрытого ключа с сохраненными безопасными разрешениями.
$ openssl rsa -in example.com.rsa.key -out example.com.rsa.key.unencrypted
$ openssl ec -in example.com.ecdsa.key -out example.com.ecdsa.key.unencrypted
Я правильно настроил SPF, DKIM, DMARC и DNSSEC, каждый из которых подтвержден сторонними инструментами и отправил и получил почту с проходными баллами в заголовках.
Я снова использовал openssl для создания хэшей сертификатов для моих записей DANE TLSA. Я создал два набора, по одному для каждого алгоритма и для портов 25 и 587. Они были добавлены в мой файл зоны, проверены с помощью named-checkzone, подписаны с помощью dnssec-signzone и опубликованы в DNS.
Я начал с использования двух внешних инструментов для проверки конфигурации. датчанинчек а второй в датчанин.sys4.de. Оба сообщили об общем успехе с использованием сертификата RSA, но о конкретной ошибке сертификата ECDSA.
Первый преуспел, частично сообщив:
DANE TLSA 3 1 1 [9679fc29..]: Сертификат EE соответствует ОК
DANE TLSA 3 1 1 [ecd29ffd..]: FAIL не соответствует сертификату EE
Последний преуспел, сообщив, в частности:
3, 1, 1 9679fc296960a23c[...]149b990a680cad8b *зеленым цветом*
3, 1, 1 ecd29ffd76d61326[...]dadbcfa42eae9158 - невозможно получить сертификат локального эмитента: (20) *выделено красным*
Я попытался исправить это, изменив различные поля использования, селектора и сопоставления, 3 0 1, 3 1 1 и т. д. Я попытался сгенерировать хэши локально с помощью openssl и с помощью онлайн-инструментов, таких как gen_tlsa. Оба инструмента дали идентичные результаты хеширования для обоих сертификатов. Опять же, RSA TLSA удалось, а записи ECDSA не удалось. В конце концов я нашел сценарий chaingen, который генерирует все хэши 3 0 1, 3 1 1, 3 0 2 и 3 1 2, которые я включил для каждого порта без каких-либо улучшений для записей ECDSA.
Я провел несколько часов, пробуя различные перестановки каждого сертификата, записей TLSA, портов и т. д. Я попытался добавить записи TLSA (2 0 1) для родительских ключей записей ECDSA в DNS. Я попытался изменить сертификат, доступный для Postfix, чтобы включить ca-bundle вместе с сертификатом в файл .pem.
Исследуя, я нашел этот пост на exim-users под названием «Как использовать сертификат ec с сертификатами DANE и ec+rsa» Виктора Духовни, который не нуждается в представлении в кругу Postfix/DANE.Он предположил, что, возможно, онлайн-инструменты были оппортунистическими, и как только они преуспели с сертификатами RSA, они не удосужились протестировать сертификаты ECDSA. Он предоставил очень ценные вызовы openssl, чтобы показать, что ключи действительно были правильными в ситуации автора. Я продублировал эту работу с двумя короткими сценариями оболочки, используя код Виктора, заменяющий мою информацию, один назывался checkrsa, а другой — checkecdsa.
Два сценария выполняют по две команды каждый со следующей настройкой для checkrsa (для IPv4):
$ кот чекерса
эхо "выйти" | openssl s_client -starttls smtp -connect mail.example.com:25 -4 -verify 9 \
-dane_tlsa_domain mail.example.com \
-dane_tlsa_rrdata "3 0 1 c487cdb079b49d12ee357d9547c6f67448a2ec2e789c86c65d213a57aaec4ac9" \
-dane_tlsa_rrdata "3 1 1 9679fc296960a23c89fed73d8e6a6d0ab33f0abc99d48c44149b990a680cad8b" \
-sigalgs rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss12pss
И проверьте ecdsa (для IPv6):
$ cat checkecdsa
эхо "выйти" | openssl s_client -starttls smtp -connect mail.example.com:25 -6 -verify 9 \
-dane_tlsa_domain mail.example.com \
-dane_tlsa_rrdata "3 0 1 87a8c75581c9d022062416a37387de1ec30d311e4d7afbeb892be287fb13bfc5" \
-dane_tlsa_rrdata "3 1 1 ecd29ffd76d6132629ddbf7ccd31460e23ac3b4a50d47bccdadbcfa42eae9158" \
-sigalgs ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384:ecdsa_secp521r1_sha512
Результаты, достижения:
root@server:~/bin# ./checkrsa
проверить глубину 9
ПОДКЛЮЧЕН(00000003)
глубина=0 CN = *.example.com
проверить возврат: 1
---
Цепочка сертификатов
0 s:CN = *.example.com
i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
Сертификат сервера
-----НАЧАТЬ СЕРТИФИКАТ-----
MIIHNDCCBhygAwIBAgIQAzfJZrX65NjG2FvLmk0I0jANBgkqhkiG9w0BAQsFADCB
...
Xw8UgZDYihDaIxT8SUQUgV9weQg5Lkru
-----КОНЕЦ СЕРТИФИКАТА-----
тема = CN = * .example.com
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
---
Имена ЦС сертификата клиента не отправлены
Дайджест одноранговой подписи: SHA256
Тип одноранговой подписи: RSA-PSS
Временный ключ сервера: X25519, 253 бита
---
Рукопожатие SSL прочитало 2904 байта и записало 386 байтов
Проверка: ОК
Подтвержденное имя узла: *.example.com
DANE TLSA 3 1 1 ...99d48c44149b990a680cad8b соответствует сертификату EE на глубине 0
---
Новый, TLSv1.3, шифр TLS_AES_256_GCM_SHA384.
Открытый ключ сервера 4096 бит.
Безопасное повторное согласование НЕ поддерживается
Сжатие: НЕТ
Расширение: НЕТ
ALPN не согласован
Предварительные данные не были отправлены
Подтвердите код возврата: 0 (хорошо)
---
250 РАЗБИВКА
СДЕЛАНО
root@server:~/bin# ./checkecdsa
проверить глубину 9
ПОДКЛЮЧЕН(00000003)
глубина=0 CN = *.example.com
проверить возврат: 1
---
Цепочка сертификатов
0 s:CN = *.example.com
i: C = Великобритания, ST = Большой Манчестер, L = Солфорд, O = Sectigo Limited, CN = Sectigo
ЦС безопасного сервера проверки домена ECC
---
Сертификат сервера
-----НАЧАТЬ СЕРТИФИКАТ-----
MIIEqDCCBE6gAwIBAgIRAIIKQBNWh2R9wwvn2/j30PgwCgYIKoZIzj0EAwIwgY8x
...
ЙемреHq/Cd5HPgIgE6InSF5ko6mWo9GMpR7w1ijpbsnShlS6EiYrpZozD0s=
-----КОНЕЦ СЕРТИФИКАТА-----
тема = CN = * .example.com
эмитент = C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
---
Имена ЦС сертификата клиента не отправлены
Дайджест одноранговой подписи: SHA256
Тип одноранговой подписи: ECDSA
Временный ключ сервера: X25519, 253 бита
---
Рукопожатие SSL прочитало 1811 байт и записало 348 байт.
Проверка: ОК
Подтвержденное имя узла: *.example.com
DANE TLSA 3 1 1 ...50d47bccdadbcfa42eae9158 соответствует сертификату EE на глубине 0
---
Новый, TLSv1.3, шифр TLS_AES_256_GCM_SHA384.
Открытый ключ сервера 256 бит.
Безопасное повторное согласование НЕ поддерживается
Сжатие: НЕТ
Расширение: НЕТ
ALPN не согласован
Предварительные данные не были отправлены
Подтвердите код возврата: 0 (хорошо)
---
250 РАЗБИВКА
СДЕЛАНО
Таким образом, оба сертификата проверяются локально, но продолжают сбой извне.
Увидев, что в сообщении Виктора указано, что, возможно, инструменты, добившиеся успеха с RSA, отказались от хэшей ECDSA, я также попытался просто опубликовать записи ECDSA TLSA. Результаты показали полный сбой только с хэшами ECDSA.
Итак, я согласен с этой ситуацией:
У меня есть два набора SSL-сертификатов, один RSA, другой ECDSA.
Оба сертификата преуспевают в Postfix.
Проверка обоих сертификатов с помощью openssl.
Публикация обоих сертификатов проходит в целом, на основе сертификатов RSA, с учетом того, что сертификаты ECDSA терпят неудачу.
Сертификаты ECDSA успешны локально, но не работают извне.
Я не знаю, что делать дальше, и мне нужна помощь в настройке моего сертификата ECDSA параллельно с моими записями RSA для DANE.
