Якщо припустити, що властивість Subject Alternative Name (SAN) сертифіката SSL містить два імена DNS
domain.tldhost.domain.tldале Common Name (CN) встановлено тільки один з обох: CN=domain.tld.
host.domain.tldзапитується інший ,?Зокрема, як OpenSSL 0.9.8b + обробляє даний сценарій?
Відповіді:
Це залежить від реалізації, але загальним правилом є те, що домен перевіряється на відповідність всім SAN і загальному імені. Якщо там знайдено домен, то сертифікат нормальний для підключення.
RFC 5280 , розділ 4.1.2.6, говорить: "Назва теми МОЖЕ міститись у полі теми та / або розширенні subjectAltName". Це означає, що доменне ім'я повинно перевірятися як на розширення SubjectAltName, так і на властивість Subject (а саме це загальний параметр імені) сертифіката. Ці два місця доповнюють одне одного, а не дублюють його. І SubjectAltName - це належне місце для розміщення додаткових імен, таких як www .domain.com або www2 .domain.com
Оновлення: згідно з RFC 6125 , опублікованим у 2011 році, валідатор повинен спочатку перевірити SAN, а якщо SAN існує, то CN не слід перевіряти. Зверніть увагу, що RFC 6125 є відносно недавнім, і все ще існують сертифікати та сертифікаційні центри, які видають сертифікати, які включають "основне" доменне ім'я в CN та альтернативні імена доменів у SAN. Тобто, виключивши CN із перевірки, якщо присутній SAN, ви можете відмовити в наявності деяких інших чинних сертифікатів.
Щоб бути абсолютно правильним, ви повинні помістити всі імена в поле SAN.
Поле CN повинно містити Ім'я суб'єкта, а не доменне ім'я, але коли Netscape виявив цю річ SSL, вони пропустили визначення його найбільшого ринку. Просто для URL-адреси сервера не було визначено поле сертифіката.
Це було вирішено, щоб домен потрапив у поле CN, і сьогодні використання поля CN застаріло, але все ще широко використовується. CN може містити лише одне доменне ім'я.
Загальні правила для цього: CN - розмістіть тут свою основну URL-адресу (для сумісності) SAN - помістіть сюди весь свій домен, повторіть CN, оскільки він там не в потрібному місці, але використовується для цього ...
Якщо ви знайшли правильну реалізацію, відповіді на ваші запитання будуть такими:
Чи має це налаштування особливе значення або якісь [диз] переваги перед встановленням обох CN? Ви не можете встановити обидва CN, оскільки CN може містити лише одне ім'я. Ви можете зробити 2 простих сертифікати CN замість одного сертифікату CN + SAN, але для цього вам потрібні 2 IP-адреси.
Що відбувається на стороні сервера, якщо запитується інший, host.domain.tld? Неважливо, що відбувається на стороні сервера.
Коротше кажучи: Коли клієнт браузера підключається до цього сервера, тоді браузер надсилає зашифровані пакети, які зашифровані за допомогою відкритого ключа сервера. Сервер розшифровує пакет, і якщо сервер може розшифрувати, то він був зашифрований для сервера.
Сервер нічого не знає від клієнта до дешифрування, оскільки лише IP-адреса не зашифрована через з'єднання. Ось чому вам потрібні 2 IP-адреси для 2 сертифікатів. (Забудьте про SNI, зараз там занадто багато XP.)
На стороні клієнта браузер отримує CN, а потім SAN, поки не буде перевірено всі. Якщо одне з імен збігається з сайтом, то перевірка URL-адреси була здійснена браузером. (я не розмовляю про перевірку сертифіката, звичайно, багато запитів ocsp, crl, aia та відповідей щоразу подорожує по мережі)
Бачу, ще ніхто не згадав цей розділ у Базових вимогах. Я відчуваю, що вони важливі.
Питання: SSL - Як спільні імена (CN) та тематичні альтернативні імена (SAN) працюють разом?
В: Зовсім не. Якщо є SAN, тоді CN можна ігнорувати. - Принаймні, якщо програмне забезпечення, яке виконує перевірку, дуже суворо дотримується базових вимог CABForum.
(Отже, це означає, що я не можу відповісти на ваше запитання "Редагувати". Тільки оригінальне запитання.)
Базові вимоги CABForum, v. 1.2.5 (станом на 2 квітня 2015 р.), Стор. 9-10 :
9.2.2 Поля розрізнених предметних назв
a. Тема Поле загального імені Поле
сертифіката: subject: commonName (OID 2.5.4.3)
Обов’язково / Необов’язково: Застаріле (не рекомендується, але не забороняється)
Зміст: Якщо воно присутнє, це поле ПОВИННО містити одну IP-адресу або повністю кваліфіковане доменне ім’я, яке є одним значень, що містяться в розширенні subjectAltName сертифіката (див. Розділ 9.2.1).
RFC 2818: HTTP Over TLS , 2000, Розділ 3.1: Ідентифікація сервера :
Якщо присутнє розширення subjectAltName типу dNSName, це ПОВИННО використовуватись як ідентичність. В іншому випадку ПОВИННО використовуватись (найбільш конкретне) поле Загальне ім'я в полі Тема сертифіката. Хоча використання загальної назви є існуючою практикою, вона застаріла, і Центрам сертифікації рекомендується використовувати dNSName замість цього.
RFC 6125: Представлення та перевірка ідентифікації служби додатків на основі доменів в Інфраструктурі Інтернет-відкритого ключа за допомогою сертифікатів X.509 (PKIX) у контексті безпеки транспортного рівня (TLS) , 2011, Розділ 6.4.4: Перевірка загальних імен :
[...] лише тоді, коли представлені ідентифікатори не включають DNS-ID, SRV-ID, URI-ID або будь-які типи специфічних ідентифікаторів, що підтримуються клієнтом, тоді клієнт МОЖЕ як останню перевірку для рядок, форма якого відповідає формі повністю кваліфікованого доменного імені DNS у полі Загальне ім'я поля теми (тобто CN-ID).