- Введение
- Что такое ssl и что такое tls?
- Что происходит на практике
- Безопасность
- Выпускаем собственные сертификаты
- Дополнительные сведения
- Закрытый ключ
- Запрос csr
- Имена доменов в сертификатах
- Логика сопоставления имен для функции безопасности домена
- Рекомендации по доменным именам для smtp-серверов в интернете
- Рекомендации по доменным именам для сервера клиентского доступа
- Доменные имена с подстановочными знаками
- Имена субъектов и имена доменов
- Имя субъекта
- Реализация относительных различающихся имен
- Клонирование существующего сертификата
- Логика сопоставления имен для функции безопасности домена
- Настройка apache на использование клиентских сертификатов
- Настройка nginx на использование клиентских сертификатов
- Общие сведения о полях, используемых сертификатами для служб tls
- Имя субъекта
- Реализация относительных различающихся имен
- Международные имена субъектов
- Имена субъектов и имена доменов
- Имена доменов в сертификатах
- Логика сопоставления имен для функции безопасности домена
- Рекомендации по доменным именам для smtp-серверов в интернете
- Рекомендации по доменным именам для сервера клиентского доступа
- Доменные имена с подстановочными знаками
- Откуда берутся сертификаты?
- Реализация относительных различающихся имен
- Рекомендации по доменным именам для smtp-серверов в интернете
- Рекомендации по доменным именам для сервера клиентского доступа
- Словарный запас
- Сценарий №1 — найти следующего в связке
- Установка ssl/tls-сертификата на сервер с nginx
Введение
SSL-сертификат — это уникальная цифровая подпись, которая однозначно указывает на определенный сайт в сети интернет. Также сертификат является частью системы шифрования и необходим для организации защищенного соединения между клиентом и сервером.
Сертификаты выпускаются двух видов:
- Самозаверенный (самоподписанный) сертификат — создаётся самим субъектом, обычно им же и используется. Такой тип сертификатов не подписан удостоверяющими центрами.
- Сертификат, выпущенный удостоверяющим центром — создаётся в виде цепочки корневого сертификата удостоверяющего центра, самого сертификата и возможных промежуточных сертификатов.
Удостоверяющий центр — организация, которая заявляет о своей честности, и, на основе своей честности, подтверждает подлинность ключа сертификата.
Обычно корневые сертификаты удостоверяющих центров широко известны и предустановлены производителем на устройства пользователей или в операционные системы.
Что такое ssl и что такое tls?
SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications.
Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.
Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере.
SSL 1.0 — никогда не публиковалсяSSL 2.0 — февраль 1995 годаSSL 3.0 — 1996 годTLS 1.0 — январь 1999 годаTLS 1.1 — апрель 2006 годаTLS 1.2 — август 2008 года
Что происходит на практике
Client Hello – клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.
Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA – Риверт-Шамир-Адлеман, DH – Диффи-Хеллмана, ECDH – Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES – Advanced Encryption Standard, 3DES – Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 – Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).
Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
Server Hello – сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.
Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
Certificate – сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.
Что представляет из себя сертификат? Сертификат – это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.
Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, – вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.
Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA – Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом – это цепочка подписания.
Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
Server Key Exchange – этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Ys=gслучайно выбранное сервером числоmod p, где mod – это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Yc=gслучайно выбранное клиентом числоmod p. После этого сервер считает Ycслучайно выбранное сервером числоmod p, а клиент Ysслучайно выбранное клиентом числоmod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:
Server Hello Done – сервер сообщает, что начальный этап установки соединения завершен
Client Key Exchange – как было уже сказано выше, когда сервер передал числа p, g, Ys в Server Key Echange, клиент передает свое число Yc в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret – предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.
Change Cipher Spec – клиент говорит серверу, что он готов перейти на защищенное соединение.
Finished – клиент зашифровывает симметричным ключом первое сообщение с MAC.
Change Cipher Spec – сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.
Finished – аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение
После этого соединение считается установленным, и происходит передача полезной информации
close_notify – служебное сообщение, которое одна сторона отправляет другой, как уведомление о том, что считаетсоединение разорванным и не будет принимать больше сообщения. Другая сторона в ответ обязана послать аналогичное сообщение close_notify.
Безопасность
При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент.
Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.
Выпускаем собственные сертификаты
Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем “password” длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:
openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096
Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:
Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте “CN=Certificate authority” (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password – все поля, кроме CN опциональны), приватный ключ и пароль от него:
openssl req -new -key CA-private-key.key -passin pass:password -subj "/CN=Certificate authority/" -out CA-certificate-signing-request.csr t $3
Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.
openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key.key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE
Теперь у нас есть сертификат, которому в будущем будут доверять наши клиент и сервер. Похожим образом сделаем приватные ключи и запросы на подпись сертификата для них:
openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj "/CN=localhost/" -out Server-certificate-signing-request.csrt $3
openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj "/CN=Client/" -out Client-certificate-signing-request.csr
Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.
openssl x509 -req -in Server-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem
После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем “password”:
openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12
Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:
keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt
Для удобства, все описанные выше действия упакованы в bash script.
Дополнительные сведения
Дополнительные сведения о центрах сертификации,
поддерживающих веб-узлы Exchange, см. в статье 929395 базы знаний
Майкрософт Партнеры по предоставлению сертификатов для
объединенных коммуникаций для сервера Exchange Server 2007 и
Communications Server 2007 (эта ссылка может указывать на
содержимое полностью или частично на английском языке).
Дополнительные сведения о технологиях криптографии и
сертификатов, а также об используемых понятиях см. в следующих
публикациях:
- Housley, Russ and Tim Polk (Хаусли, Русс и Тим Полк).
Planning for PKI: Best Practices Guide for Deploying Public Key
Infrastructure (Планирование инфраструктуры открытого ключа:
руководство по развертыванию инфраструктуры открытого ключа).
New York (Нью-Йорк): John Wiley & Son, Inc., 2001. - Adams, Carlisle and Steve Lloyd (Адамс, Карлайл и Стив Ллойд).
Applied Cryptography: Protocols, Algorithms, and Source Code in
C (Прикладная криптография: протоколы, алгоритмы и исходный код на
Си), 2nd Edition (2-е издание). New York (Нью-Йорк): John Wiley
& Son, Inc., 1996. - Рекомендации по реализации инфраструктуры открытого
ключа Microsoft Windows Server 2003 (могут быть на английском
языке)
Закрытый ключ
bash-4.3$ cat ~/cert.key -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEAylakszTwOBsBU26fazE2T717SMH/muzOEu69cZUi/C aw eR wJD95y5LDnsu9fk5eUg/JQokcsTncgF8aJybokt72E8bIl1wSBTR3P4ADGtYvSkN P1C88J26GGX3P4cbTMTugi2Tb2xFi5I5aSdRuvsiGZuDAy3nF3kg5cajJG9rUVG ZNNsLvh3lBdnIel3U0RYrZervtcvpEnhz8M5Rx onaKnTMLp5PVkXEEjpSv6bXCf iYVUPRtjY1SWibI0h CrmRp52efIBqAsvA3IDK2dRGj0Bj56TzxKES8he0Ygk3qc u6rztDGGMvvIWcBZUSdCR/E3KmbFjyzlFxEv2QIDAQABAoIBADB YYzdxDD L wq GCUdr1GfLRv7 uHLnXwmIdtGDhN46VPIfUM0vNWaX7zBwziKmb66lP wlZm4HWxS dNmxpw9Xnf/yvaMX1 A tSmM6sAPPj5fx4yETnaTheId cKqWG/HjRPKIL8zFm0l fK0lLdiglJkAS6GxrpPYYPs0zNUhbzELh4hyEQ7rMvrX30mIHsLVMh27fxuK2VI3 6Tptv7/sErF0iwwROc5fnFnkYjrtNsNvnjPQvHgr7q8H 6OeFAZN/wQzIZZr1rjY CKddLqznPGecVUhZrrRHiKohWF5yGrJHVe93EuQak216pnMuu8a7QVsOw8b 1DUJ kQJozgECgYEA/HDpVGbQMm614q zx1oJqfP8u aQCdtwAfOLgZQ6K7kMqLlzP28u D92M3TUrE2ynG1N/x4SAa yMK0fgE2/LKlOWpH/hNVtJK2ys5AKzz39i5RZI0hQR KAm7nodj3qnn7tnb5sE26qC5dH5tlckzZRKCuTvMyxANDecoIcHcHcECgYEAzTDn 6DasLv6IRodHR2uRwqo0WTSHeusD38hbOZ2vYk/2sgZkTWc3sRPSKaw7kGthGfX2 v/CQyuW/wiO5UDUkT8ayrMkZGQzZbjiag7fORq90dG4RlG58arxx55Ir1muPXUjd 3SnAUqDNPHzlGiLPXvnMJ85BSh/hzmlBxHU0SBkCgYBMkVrUVNL1WQsmFLDs2Gxx 9iVEQOyTcNGKZfp8dR8nv9sNGiLQrMJF4acmOUg1fhE5gpwRQilJktf5ELXwb0oq LmxUvMzsSCHrX 0Yw5EScMroPVgdECUcBce4j8xE7zgABGhkl1o21EUsBmTqt7o0 / ZSlMbLGLU88E4F3y0KgQKBgG8elAhCS16rwtsG Yfo7ifQisbgVpovWYq/8v8x sL/58 wW4Ay24AcKZ97fgeZE8HHhrL3nJlJqtz0IoZuZG9AEF9DQmsHhHoK9Lpg0 WwYWkGdZEDYk20XmRX0VwJ2 5AWtp1DVAmz83ghqzpsnzMtvVasc3Giq VsRz2b3 3ddJAoGAcef0eCevT4GQR5kDjICXjKyNnVsWVDYl9dOaXFizxEL 4Nl7unppMeQI cJnZcO5shoXd7PoVI5iByyK6aaMA9GLxAZcsbZJngkzF3u0uk4Ako7NM03iMxdaQ FaJb1SnGcSWGwQKVqdBv5FGpCblISlk9DkVFKUB2PjQnp6xs0TQ= -----END RSA PRIVATE KEY-----
Запрос csr
bash-4.3$ cat ~/cert.csr -----BEGIN CERTIFICATE REQUEST----- MIIDFzCCAf8CAQAwgdExCzAJBgNVBAYTAlJVMTEwLwYDVQQIDCjDkMKcw5DCvsOR woHDkMK6w5DCvsOQwrLDkcKBw5DCusOQwrDDkcKPMSEwHwYDVQQHDBjDkMKcw5DC vsORwoHDkMK6w5DCssOQwrAxNzA1BgNVBAoMLsOQwqDDkMK w5DCs8OQwrAgw5DC uCDDkMK6w5DCvsOQwr/DkcKLw5HCgsOQwrAxEzARBgNVBAMMCmRvbWFpbi5jb20x HjAcBgkqhkiG9w0BCQEWD2luZm9AZG9tYWluLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMpWpLM08DgbAVNun2sxNk 9e0jB/5rszhLuvXGVIvwv msPnkcCQ/ecuSw57LvX5OXlIPyUKJHLE53IBfGicm6JLe9hPGyJdcEgU0dz AAxr WL0pDfj9QvPCduhhl9z HG0zE7oItk29sRYuSOWknUbr7IhmbgwMt5xd5IOXGoyR va1FRmTTbC74d5QXZyHpd1NEWK2Xq77XL6RJ4c/DOUcfqJ2ip0zC6eT1ZFxBI6Ur m1wn4mFVD0bY2NUlomyNIfgq5kaednnyAagLLwNyAytnURo9AY ek88ShEvIXtG IJN6nLuq87QxhjL7yFnAWVEnQkfxNypmxY8s5RcRL9kCAwEAAaAAMA0GCSqGSIb3 DQEBCwUAA4IBAQCI V1vbHu1KajJ6VHFq4 eDMjcdYPsazkQfYGASTb7vTpBuyMn x00DMFxra zMxL8zwMFAuoxtJiPut36nkRj5iCfpnZUK5W9Skq/jjum3bJ2mgTGa nuJ23IXWJgrk Tpr1F0/mVIjlHoNksQQy94gXZY2VgO/kQdxsc3yATqfQcCfzgeT D/rvS0Fpl9b1Pb7b0abN3KbVkFRkMYR24oEmEN0k2Fk Z FtyWxBFLq1I/FX0qP6 wk axH569n6VpztTXEICHqE KE2nzFXqNWSMVrfJ2gBCXvIl6Qeb3t4cfVEHE6R FBUamOn3bBzo7yC/i4Y0ksxM4oPHkdDmiduD -----END CERTIFICATE REQUEST-----
Имена
доменов в сертификатах
Для протокола TLS сертификаты должны содержать
DNS-имена, поскольку TLS является протоколом, работающим на основе
службы DNS. Клиенты проверяют, чтобы DNS-имя сервера, к которому
они подключаются с помощью DNS-имени, позволяло подключиться к
требуемому серверу. Это верно для веб-обозревателей, которые
подключаются к веб-узлу по протоколу HTTPS, и для SMTP-серверов,
передающих электронную почту через Интернет или корпоративную
локальную сеть.
Одиночный сервер может поддерживать несколько DNS-имен
по следующим причинам:
- SMTP-сервер поддерживает несколько принятых доменов.
- Клиент может получать доступ к серверу электронной почты по
имени сервера, по имени домена, по локальному имени полного
доменного имени или по имени, определяемому по сбалансированной
нагрузке.
Если после установки TLS-подключения клиент обнаружит
искомое имя, клиент игнорирует другие имена в сертификате.
Несколько имен домена и сервера могут добавляться в поле
дополнительного имени субъекта TLS-сертификата. Сертификат,
содержащий несколько дополнительных имен субъекта, можно создать с
помощью параметра DomainName командлета
New-ExchangeCertificate. Параметр DomainName является
многозначным, так что он может принимать несколько имен.
Сертификаты X.509 могут содержать в расширении
сертификата «Дополнительное имя субъекта» (SubjectAltName) одно или
несколько DNS-имен либо вообще не содержать DNS-имен. DNS-имена в
расширении SubjectAltName точно соблюдают ограничения, существующие
для DNS-имен. Они не должны содержать более 255 символов, и, кроме
того, должны состоять только из символов A-Z, a-z, 0-9 и тире
(-).
Логика
сопоставления имен для функции безопасности домена
Логика сопоставления имен сертификатов для функции
безопасности домена проверяет соответствие имени домена в
полученному сертификате имени домена, в который отправляется почта.
В качестве примера рассмотрим полное доменное имя домена получателя
woodgrovebank.com. Логика сопоставления имен сертификатов выполняет
поиск всех DNS-имен в сертификатах, и если одно из DNS-имен
совпадает, сертификат считается соответствующим указанному
домену.
В данном примере логика сопоставления имен сертификатов
принимает сертификат с полностью совпадающим именем домена, таким
как woodgrovebank.com. Кроме того, в сертификатах могут
использоваться подстановочные знаки для имен доменов, поэтому
сертификат с DNS-именем *.woodgrovebank.com считается
соответствующим. Дополнительные сведения об именах домена с
подстановочными знаками в подразделе «Имена домена с
подстановочными знаками» ниже в данном разделе.
Логика сопоставления имен сертификатов также выполняет
поиск в DNS глубиной в один узел. Поэтому mail1.woodgrovebank.com
также считается соответствующим woodgrovebank.com. Тем не менее
DNS-имена с глубиной более двух узлов пне принимаются. Поэтому,
например, mail1.us.woodgrovebank.com не будет считаться
соответствующим woodgrovebank.com.
Дополнительные сведения о том, как Exchange выбирает
сертификаты, см. в разделе Выбор TLS-сертификата
SMTP.
Рекомендации по доменным именам для smtp-серверов в интернете
При создании сертификата или запроса сертификата для
пограничного транспортного сервера, осуществляющего
TLS-взаимодействие по протоколу SMTP через Интернет, в запрос
необходимо включить следующий набор имен доменов:
- Полное доменное имя сервера в Интернете — это имя может
отличаться от внутреннего полного доменного имени, которое
используется между пограничными транспортными серверами и
транспортными серверами-концентраторами, и должно соответствовать
записи «А», публикуемой на общедоступном DNS-сервере в Интернете.
Это имя должно вводиться как общее имя в параметр
SubjectName командлета New-ExchangeCertificate. - Все имена обслуживаемых доменов организации — чтобы
заполнить дополнительное имя субъекта для конечного сертификата,
используйте параметр IncludeAcceptedDomain командлета
New-ExchangeCertificate. - Полное доменное имя соединителя, если для него не
используется любой из предыдущих элементов — чтобы заполнить
дополнительное имя субъекта для конечного сертификата, используйте
параметр DomainName командлета
New-ExchangeCertificate.
Рекомендации по доменным именам для сервера клиентского
доступа
Когда создается сертификат или запрос сертификата для
сервера клиентского доступа, в запрос следует включать следующий
набор доменных имен:
- локальное имя или NetBIOS-имя сервера, например,
owa1; - все имена обслуживаемых доменов для организации, например,
contoso.com; - полное доменное имя для сервера, например,
owa1.contoso.com; - доменное имя службы автоматического обнаружения для домена,
например, Autodiscover.contoso.com; - идентификатор балансировки нагрузки сервера, если такой
используется, например, owa.contoso.com.
Доменные
имена с подстановочными знаками
Доменные имена с подстановочными знаками относятся к
специальному типу доменных имен, представляющих несколько
подчиненных доменов. Доменные имена с подстановочными знаками
помогают упростить сертификаты, так как одно доменное имя с
подстановочными знаками представляет все подчиненные домены этого
домена. Эти имена представляются символом звездочки ( * )
в DNS-узле. Например, *.contoso.com представляет
contoso.com и все подчиненные домены для contoso.com.
Если при создании сертификата или запроса сертификата для всех
принятых доменов использовать подстановочный знак, можно
существенно упростить запрос.
Имена
субъектов и имена доменов
По соглашению общее имя может содержать полное доменное
имя (FQDN). Хотя это широко практикуется и рекомендуется,
необходимо ясно представлять себе следующие две проблемы.
Во-первых, максимальный размер поля общего имени равен
64 символам. Это меньше, чем максимальный размер полного доменного
имени. Поэтому в случае полного доменного имени, содержащего более
64 символов, необходимо поместить доменное имя в дополнительное имя
субъекта. Параметр DomainName — это параметр, отображающий
дополнительное имя субъекта в конечный сертификат.
Во-вторых, полное доменное имя ограничено подмножеством
набора символов ASCII. Однако общее имя (CN) поддерживает Юникод.
Поэтому можно создать действительный сертификат с общим именем,
которое выглядит как DNS-имя, но является недопустимым DNS-именем.
Программное обеспечение, ищущее полное доменное имя в общем имени
сертификата, не вернет правильный результат, если общее имя
содержит символы, отличные от ASCII-символов. Например, если
создать сертификат с именем субъекта, где CN=mail.microsoft.com,
данное имя не будет считаться полным доменным именем, поскольку оно
содержит символ Юникода — «i» с диакритическим знаком (x00ef).
Общее имя в Юникоде легко спутать с полным доменным именем ввиду
незначительных различий между символом «i» с диакритическим знаком
(x00ef) и знаком «i» из ASCII (x0069). Задачей сертификата Echange
не устанавливается требование и не вводится правило, чтобы общее
имя субъекта было допустимым полным доменным именем. По умолчанию
это означает, что командлет включает полное доменное имя сервера в
качестве общего имени по умолчанию.
Имя
субъекта
«Имя субъекта» TLS-сертификата — это поле, используемое
службами, взаимодействующими с DNS. Поле «Имя субъекта» привязывает
сертификат к определенному имени сервера или домена.
Имя субъекта — это различающееся имя X.500, которое
состоит из одного или нескольких относительных различающихся имен,
которые также упоминаются как RDN (relative distinguished names). В
следующей таблице перечисляются относительные различающиеся имена,
часто используемые для идентификации организаций или объектов
серверов.
Имя | Аббревиатура | Тип | Макс. размер | Частота Макс.рекомендуемая в сертификатезапросе | Порядок в субъекте |
---|---|---|---|---|---|
Страна/регион | C | ASCII | 2 | 11 | 1 |
Компонент домена | DC | ASCII | 255 | Несколько | 1 |
Область или район | S | Юникод | 128 | 1 | 2 |
Местность | L | Юникод | 128 | 1 | 3 |
Организация | O | Юникод | 64 | 11 | 4 |
Подразделение | OU | Юникод | 64 | НесколькоНесколько | 5 |
Общее имя | CN | Юникод | 64 | Несколько1 | 6 |
Коды страны/региона являются кодами ISO 3166-1.
Дополнительные сведения см. по ссылке Английские названия стран и элементы
кода.
«Компонент домена» и «Страна/регион» согласно
соглашению являются взаимно исключающими. Рекомендуется ссылаться
на имя по стране/региону или по имени, существующем в службе имен
доменов (Domain Name System, DNS). Также следует иметь в ввиду, что
максимальный размер компонента домена (255 символов) является
суммой всех значений компонента домена.
Реализация
относительных различающихся имен
Имена субъектов представляются в командлете
New-ExchangeCertificate в виде одного параметра, состоящего
из последовательности имен, разделенных запятыми. Каждое имя
идентифицируется аббревиатурой относительного различающегося имени.
Например, следующее имя субъекта представляется как
«Страна/регион» = US
,
«Организация» = Contoso Corp
и «Общее
имя» = mail1.contoso.com
:
Другие имена субъектов, которые могут представлять тот
же самый сервер, приводятся в следующих примерах:
Если имеется зарегистрированное DNS-имя, которое
применяется для отправки SMTP-почты, рекомендуется использовать
соглашение по компонентам доменов и DNS-имя для имени сертификата,
например, DC=contoso, DC=com, CN=mail1.contoso.com.
Однако при создании запроса сертификата для поставщика
центра сертификации необходимо ясно понимать требования центра
сертификации, предъявляемые к полю «Имя субъекта», и потребности
своей уникальной инфраструктуры открытого ключа. В некоторых
случаях, возможно, потребуется использовать код страны/региона
(«C»). Если это так, необходимо зарегистрировать свое относительное
различающееся имя в центре регистрации X.500.
Клонирование существующего
сертификата
Приложение Exchange 2007 создает во время установки
самозаверенный сертификат, который использует все имена серверов и
доменов, известные приложению Exchange на момент установки. Эти
сертификаты действительны в течение 12 месяцев. В некоторых случаях
имеет смысл клонировать эти сертификаты, если имена субъектов и
дополнительные имена субъектов могут использоваться для других
компьютеров. Имейте в виду, что клонируются только метаданные
сертификата, а не наборы ключей.
Чтобы выполнить следующий командлет на компьютере с
установленной ролью пограничного транспортного сервера, необходимо
войти в систему с учетной записью, входящей в локальную группу
администраторов на этом компьютере.
Чтобы клонировать новый сертификат из существующего
сертификата, необходимо сначала определить текущий сертификат,
используемый по умолчанию для домена, выполнив следующий
командлет:
Где mail1.contoso.com
— имя сервера или
полное доменное имя, для которого требуется создать клонированный
сертификат.
Первый сертификат, приводимый в выходных данных,
является TLS-сертификатом службы SMTP, используемым по умолчанию
для сервера.
Чтобы клонировать сертификат, выполните следующую
команду:
Где значение параметра Thumbprint берется из
первого сертификата, приведенного в выходных данных для
Get-ExchangeCertificate.
Эта команда извлекает из существующего сертификата
имена, которые идентифицируются по отпечатку, и использует их в
новом самозаверенном сертификате.
Логика
сопоставления имен для функции безопасности домена
Логика сопоставления имен сертификатов для функции
безопасности домена проверяет соответствие имени домена в
полученному сертификате имени домена, в который отправляется почта.
В качестве примера рассмотрим полное доменное имя домена получателя
woodgrovebank.com. Логика сопоставления имен сертификатов выполняет
поиск всех DNS-имен в сертификатах, и если одно из DNS-имен
совпадает, сертификат считается соответствующим указанному
домену.
В данном примере логика сопоставления имен сертификатов
принимает сертификат с полностью совпадающим именем домена, таким
как woodgrovebank.com. Кроме того, в сертификатах могут
использоваться подстановочные знаки для имен доменов, поэтому
сертификат с DNS-именем *.woodgrovebank.com считается
соответствующим. Дополнительные сведения об именах домена с
подстановочными знаками в подразделе «Имена домена с
подстановочными знаками» ниже в данном разделе.
Логика сопоставления имен сертификатов также выполняет
поиск в DNS глубиной в один узел. Поэтому mail1.woodgrovebank.com
также считается соответствующим woodgrovebank.com. Тем не менее
DNS-имена с глубиной более двух узлов пне принимаются. Поэтому,
например, mail1.us.woodgrovebank.com не будет считаться
соответствующим woodgrovebank.com.
Дополнительные сведения о том, как Exchange выбирает
сертификаты, см. в разделе Выбор TLS-сертификата
SMTP.
Настройка apache на использование клиентских сертификатов
Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:
# Директория, содержащая корневые сертификаты для проверки клиентов SSLCARevocationPath /etc/apache2/ssl.crl/ # или файл, содержащий сертификаты SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опция верификации клиента. Возможные варианты: # none, optional, require and optional_no_ca SSLVerifyClient require # Глубина просмотра цепочки подписей. По умолчанию 1 SSLVerifyDepth 2
Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.
Настройка nginx на использование клиентских сертификатов
Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:
# Корневой сертификат(ы), которым(и) подписан клиентский ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Возможные варианты: on | off | optional | optional_no_ca ssl_verify_client optional; # Глубина проверки цепочки сертификатов, которыми подписан клиентский ssl_verify_depth 2;
После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.
Общие сведения о полях,
используемых сертификатами для служб tls
Если для создания запроса сертификата от стороннего
центра сертификации или другого центра сертификации инфраструктуры
открытого ключа используется командлет
New-ExchangeCertificate, убедитесь, что выполнена проверка
полей сертификата и формата сертификата, которые запрашиваются
центром сертификации.
В этом разделе описываются наиболее важные поля
сертификатов и предоставляются некоторые рекомендации по созданию
сертификатов и запросов сертификатов.
Имя
субъекта
«Имя субъекта» TLS-сертификата — это поле, используемое
службами, взаимодействующими с DNS. Поле «Имя субъекта» привязывает
сертификат к определенному имени сервера или домена.
Имя субъекта — это различающееся имя X.500, которое
состоит из одного или нескольких относительных различающихся имен,
которые также упоминаются как RDN (relative distinguished names). В
следующей таблице перечисляются относительные различающиеся имена,
часто используемые для идентификации организаций или объектов
серверов.
Имя | Аббревиатура | Тип | Макс. размер | Частота Макс.рекомендуемая в сертификатезапросе | Порядок в субъекте |
---|---|---|---|---|---|
Страна/регион | C | ASCII | 2 | 11 | 1 |
Компонент домена | DC | ASCII | 255 | Несколько | 1 |
Область или район | S | Юникод | 128 | 1 | 2 |
Местность | L | Юникод | 128 | 1 | 3 |
Организация | O | Юникод | 64 | 11 | 4 |
Подразделение | OU | Юникод | 64 | НесколькоНесколько | 5 |
Общее имя | CN | Юникод | 64 | Несколько1 | 6 |
Коды страны/региона являются кодами ISO 3166-1.
Дополнительные сведения см. по ссылке Английские названия стран и элементы
кода.
«Компонент домена» и «Страна/регион» согласно
соглашению являются взаимно исключающими. Рекомендуется ссылаться
на имя по стране/региону или по имени, существующем в службе имен
доменов (Domain Name System, DNS). Также следует иметь в ввиду, что
максимальный размер компонента домена (255 символов) является
суммой всех значений компонента домена.
Реализация
относительных различающихся имен
Имена субъектов представляются в командлете
New-ExchangeCertificate в виде одного параметра, состоящего
из последовательности имен, разделенных запятыми. Каждое имя
идентифицируется аббревиатурой относительного различающегося имени.
Например, следующее имя субъекта представляется как
«Страна/регион» = US
,
«Организация» = Contoso Corp
и «Общее
имя» = mail1.contoso.com
:
Другие имена субъектов, которые могут представлять тот
же самый сервер, приводятся в следующих примерах:
Если имеется зарегистрированное DNS-имя, которое
применяется для отправки SMTP-почты, рекомендуется использовать
соглашение по компонентам доменов и DNS-имя для имени сертификата,
например, DC=contoso, DC=com, CN=mail1.contoso.com.
Однако при создании запроса сертификата для поставщика
центра сертификации необходимо ясно понимать требования центра
сертификации, предъявляемые к полю «Имя субъекта», и потребности
своей уникальной инфраструктуры открытого ключа. В некоторых
случаях, возможно, потребуется использовать код страны/региона
(«C»). Если это так, необходимо зарегистрировать свое относительное
различающееся имя в центре регистрации X.500.
Международные имена субъектов
Имена
субъектов и имена доменов
По соглашению общее имя может содержать полное доменное
имя (FQDN). Хотя это широко практикуется и рекомендуется,
необходимо ясно представлять себе следующие две проблемы.
Во-первых, максимальный размер поля общего имени равен
64 символам. Это меньше, чем максимальный размер полного доменного
имени. Поэтому в случае полного доменного имени, содержащего более
64 символов, необходимо поместить доменное имя в дополнительное имя
субъекта. Параметр DomainName — это параметр, отображающий
дополнительное имя субъекта в конечный сертификат.
Во-вторых, полное доменное имя ограничено подмножеством
набора символов ASCII. Однако общее имя (CN) поддерживает Юникод.
Поэтому можно создать действительный сертификат с общим именем,
которое выглядит как DNS-имя, но является недопустимым DNS-именем.
Программное обеспечение, ищущее полное доменное имя в общем имени
сертификата, не вернет правильный результат, если общее имя
содержит символы, отличные от ASCII-символов. Например, если
создать сертификат с именем субъекта, где CN=mail.microsoft.com,
данное имя не будет считаться полным доменным именем, поскольку оно
содержит символ Юникода — «i» с диакритическим знаком (x00ef).
Общее имя в Юникоде легко спутать с полным доменным именем ввиду
незначительных различий между символом «i» с диакритическим знаком
(x00ef) и знаком «i» из ASCII (x0069). Задачей сертификата Echange
не устанавливается требование и не вводится правило, чтобы общее
имя субъекта было допустимым полным доменным именем. По умолчанию
это означает, что командлет включает полное доменное имя сервера в
качестве общего имени по умолчанию.
Имена
доменов в сертификатах
Для протокола TLS сертификаты должны содержать
DNS-имена, поскольку TLS является протоколом, работающим на основе
службы DNS. Клиенты проверяют, чтобы DNS-имя сервера, к которому
они подключаются с помощью DNS-имени, позволяло подключиться к
требуемому серверу. Это верно для веб-обозревателей, которые
подключаются к веб-узлу по протоколу HTTPS, и для SMTP-серверов,
передающих электронную почту через Интернет или корпоративную
локальную сеть.
Одиночный сервер может поддерживать несколько DNS-имен
по следующим причинам:
- SMTP-сервер поддерживает несколько принятых доменов.
- Клиент может получать доступ к серверу электронной почты по
имени сервера, по имени домена, по локальному имени полного
доменного имени или по имени, определяемому по сбалансированной
нагрузке.
Если после установки TLS-подключения клиент обнаружит
искомое имя, клиент игнорирует другие имена в сертификате.
Несколько имен домена и сервера могут добавляться в поле
дополнительного имени субъекта TLS-сертификата. Сертификат,
содержащий несколько дополнительных имен субъекта, можно создать с
помощью параметра DomainName командлета
New-ExchangeCertificate. Параметр DomainName является
многозначным, так что он может принимать несколько имен.
Сертификаты X.509 могут содержать в расширении
сертификата «Дополнительное имя субъекта» (SubjectAltName) одно или
несколько DNS-имен либо вообще не содержать DNS-имен. DNS-имена в
расширении SubjectAltName точно соблюдают ограничения, существующие
для DNS-имен. Они не должны содержать более 255 символов, и, кроме
того, должны состоять только из символов A-Z, a-z, 0-9 и тире
(-).
Логика
сопоставления имен для функции безопасности домена
Логика сопоставления имен сертификатов для функции
безопасности домена проверяет соответствие имени домена в
полученному сертификате имени домена, в который отправляется почта.
В качестве примера рассмотрим полное доменное имя домена получателя
woodgrovebank.com. Логика сопоставления имен сертификатов выполняет
поиск всех DNS-имен в сертификатах, и если одно из DNS-имен
совпадает, сертификат считается соответствующим указанному
домену.
В данном примере логика сопоставления имен сертификатов
принимает сертификат с полностью совпадающим именем домена, таким
как woodgrovebank.com. Кроме того, в сертификатах могут
использоваться подстановочные знаки для имен доменов, поэтому
сертификат с DNS-именем *.woodgrovebank.com считается
соответствующим. Дополнительные сведения об именах домена с
подстановочными знаками в подразделе «Имена домена с
подстановочными знаками» ниже в данном разделе.
Логика сопоставления имен сертификатов также выполняет
поиск в DNS глубиной в один узел. Поэтому mail1.woodgrovebank.com
также считается соответствующим woodgrovebank.com. Тем не менее
DNS-имена с глубиной более двух узлов пне принимаются. Поэтому,
например, mail1.us.woodgrovebank.com не будет считаться
соответствующим woodgrovebank.com.
Дополнительные сведения о том, как Exchange выбирает
сертификаты, см. в разделе Выбор TLS-сертификата
SMTP.
Рекомендации по доменным именам для smtp-серверов в интернете
При создании сертификата или запроса сертификата для
пограничного транспортного сервера, осуществляющего
TLS-взаимодействие по протоколу SMTP через Интернет, в запрос
необходимо включить следующий набор имен доменов:
- Полное доменное имя сервера в Интернете — это имя может
отличаться от внутреннего полного доменного имени, которое
используется между пограничными транспортными серверами и
транспортными серверами-концентраторами, и должно соответствовать
записи «А», публикуемой на общедоступном DNS-сервере в Интернете.
Это имя должно вводиться как общее имя в параметр
SubjectName командлета New-ExchangeCertificate. - Все имена обслуживаемых доменов организации — чтобы
заполнить дополнительное имя субъекта для конечного сертификата,
используйте параметр IncludeAcceptedDomain командлета
New-ExchangeCertificate. - Полное доменное имя соединителя, если для него не
используется любой из предыдущих элементов — чтобы заполнить
дополнительное имя субъекта для конечного сертификата, используйте
параметр DomainName командлета
New-ExchangeCertificate.
Рекомендации по доменным именам для сервера клиентского
доступа
Когда создается сертификат или запрос сертификата для
сервера клиентского доступа, в запрос следует включать следующий
набор доменных имен:
- локальное имя или NetBIOS-имя сервера, например,
owa1; - все имена обслуживаемых доменов для организации, например,
contoso.com; - полное доменное имя для сервера, например,
owa1.contoso.com; - доменное имя службы автоматического обнаружения для домена,
например, Autodiscover.contoso.com; - идентификатор балансировки нагрузки сервера, если такой
используется, например, owa.contoso.com.
Доменные
имена с подстановочными знаками
Доменные имена с подстановочными знаками относятся к
специальному типу доменных имен, представляющих несколько
подчиненных доменов. Доменные имена с подстановочными знаками
помогают упростить сертификаты, так как одно доменное имя с
подстановочными знаками представляет все подчиненные домены этого
домена. Эти имена представляются символом звездочки ( * )
в DNS-узле. Например, *.contoso.com представляет
contoso.com и все подчиненные домены для contoso.com.
Если при создании сертификата или запроса сертификата для всех
принятых доменов использовать подстановочный знак, можно
существенно упростить запрос.
Откуда берутся сертификаты?
Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.
- Создать свой собственный сертификат и самому же его подписать. Плюсы — это бесплатно, минусы — сертификат будет принят лишь вами и, в лучшем случае, вашей организацией.
- Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
- Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.
Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS < 1.2.
openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem
Далее, создает CSR — запрос на подписание сертификата.
openssl req -new -sha256 -key private.key -out server.csr -days 730
И подписываем.
openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt
Результат можно посмотреть командой:
openssl x509 -text -noout -in public.crt
Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:
openssl -help
openssl x509 -help
openssl s_client -help
Ровно то же самое можно сделать с помощью java утилиты keytool.
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
Следует серия вопросов, чтобы было чем запомнить поля owner и issuer
What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?
Конвертируем связку ключей из проприетарного формата в PKCS12.
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12
Смотрим на результат:
Alias name: selfsigned
Creation date: 20.01.2022
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2022 until: Tue Jan 15 18:33:42 MSK 2022
Certificate fingerprints:
MD5: B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB 92 44 9D 95 47 94 E4 97 0.X..v...D..G...
0010: C8 1E F1 92 ....
]
]
Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.
subjectKeyIdentifier EXTENSION ::= {
SYNTAX SubjectKeyIdentifier
IDENTIFIED BY id-ce-subjectKeyIdentifier
}
SubjectKeyIdentifier ::= KeyIdentifier
Реализация
относительных различающихся имен
Имена субъектов представляются в командлете
New-ExchangeCertificate в виде одного параметра, состоящего
из последовательности имен, разделенных запятыми. Каждое имя
идентифицируется аббревиатурой относительного различающегося имени.
Например, следующее имя субъекта представляется как
«Страна/регион» = US
,
«Организация» = Contoso Corp
и «Общее
имя» = mail1.contoso.com
:
Другие имена субъектов, которые могут представлять тот
же самый сервер, приводятся в следующих примерах:
Если имеется зарегистрированное DNS-имя, которое
применяется для отправки SMTP-почты, рекомендуется использовать
соглашение по компонентам доменов и DNS-имя для имени сертификата,
например, DC=contoso, DC=com, CN=mail1.contoso.com.
Однако при создании запроса сертификата для поставщика
центра сертификации необходимо ясно понимать требования центра
сертификации, предъявляемые к полю «Имя субъекта», и потребности
своей уникальной инфраструктуры открытого ключа. В некоторых
случаях, возможно, потребуется использовать код страны/региона
(«C»). Если это так, необходимо зарегистрировать свое относительное
различающееся имя в центре регистрации X.500.
Рекомендации по доменным именам для smtp-серверов в интернете
При создании сертификата или запроса сертификата для
пограничного транспортного сервера, осуществляющего
TLS-взаимодействие по протоколу SMTP через Интернет, в запрос
необходимо включить следующий набор имен доменов:
- Полное доменное имя сервера в Интернете — это имя может
отличаться от внутреннего полного доменного имени, которое
используется между пограничными транспортными серверами и
транспортными серверами-концентраторами, и должно соответствовать
записи «А», публикуемой на общедоступном DNS-сервере в Интернете.
Это имя должно вводиться как общее имя в параметр
SubjectName командлета New-ExchangeCertificate. - Все имена обслуживаемых доменов организации — чтобы
заполнить дополнительное имя субъекта для конечного сертификата,
используйте параметр IncludeAcceptedDomain командлета
New-ExchangeCertificate. - Полное доменное имя соединителя, если для него не
используется любой из предыдущих элементов — чтобы заполнить
дополнительное имя субъекта для конечного сертификата, используйте
параметр DomainName командлета
New-ExchangeCertificate.
Рекомендации по доменным именам для сервера клиентского
доступа
Когда создается сертификат или запрос сертификата для
сервера клиентского доступа, в запрос следует включать следующий
набор доменных имен:
- локальное имя или NetBIOS-имя сервера, например,
owa1; - все имена обслуживаемых доменов для организации, например,
contoso.com; - полное доменное имя для сервера, например,
owa1.contoso.com; - доменное имя службы автоматического обнаружения для домена,
например, Autodiscover.contoso.com; - идентификатор балансировки нагрузки сервера, если такой
используется, например, owa.contoso.com.
Словарный запас
Определение X.509 сертификатов есть в архиве ITU-T
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.
Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.
Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.
Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией.
Сценарий №1 — найти следующего в связке
Связка сертификатов — Объединение нескольких X.509 сертификатов в один файл, чаще всего в формате PEM. Связка передается по сети в момент протокола рукопожатия SSL/TLS.
Самый сок начинается, когда имеете дело со связкой сертификатов, a. k. a certificate chain. Часто просматривая лапшу в связке ключей jks непросто понять как найти родительский сертификат, когда там россыпь новых и старых сертификатов на несколько доменных имен.
Установка ssl/tls-сертификата на сервер с nginx
Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:
1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private
2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):