Як правильно задавати ім’я сертифіката під час використання розширення Subject Alternative Name (SAN
Досить часто адміністратори займаються випуском сертифікатів із використанням кількох імен. Наприклад, коли потрібно прив'язати один сертифікат до кількох імен: mail.company.com та owa.compny.com. Однак полеSubject може містити лише одне ім'я. Для вирішення цієї проблеми використовується розширення Subject Alternative Name (SAN ). У цьому розширенні можна використовувати скільки завгодно додаткових імен для сертифіката.
Але як правильно оформити кілька імен у сертифікаті на прикладі mail.company.com та owa.company.com? Тут варіанти всього 2:
- Використовувати поле Subject та розширення SAN
Цей спосіб використовується найчастіше для зовнішніх сертифікатів. Поле Subject заповнюється так (червоним виділені обов'язкові компоненти):
Тобто. включається основне ім'я сертифіката (чесно кажучи, при використанні SAN, поняття основного імені відсутнє, тому що всі імена вважаються рівноцінними. Тут слід вказувати ім'я, яке буде використовуватися найчастіше додатками, що не підтримують розширення SAN) і опціонально можна задати додаткові суфікси DN , що відображають належність сертифіката І розширення SAN заповнюється так:
DNS Name=mail.company.com DNS Name=owa.company.com
Як бачите, ім'я Subject продубльовано в SAN. Справа в тому, що якщо в сертифікаті є розширення SAN і програма вміє його обробляти, програма зазвичай налаштовується тільки на перевірку розширення SAN і в Subject вони не заглядають. Але це завжди так. Іноді програма дивиться і в Subject і в SAN. У такому разі імена дублювати необов'язково. Але для забезпечення сумісності слід ЗАВЖДИ дублювати ім'я з Subject у розширенні SAN.
- Використовувати тількирозширення SAN
Цей спосіб рідко застосовується у зовнішніх сертифікатах, лише внутрішніх. У цьому випадку поле Subject не заповнюється зовсім і залишається порожнім. А розширення SAN включатиме всі необхідні імена:
DNS Name=mail.company.com DNS Name=owa.company.com
Така форма заповнення підтримується в Internet PKI і описана в RFC 5280. Відповідно до цього RFC, якщо поле Subject не визначено (порожньо), ім'я для сертифіката вибирається з розширення SAN, а розширення позначається як критичне (див. RFC 5280 §4.2.1.6) . Ось зразкові пруфпіки, як це виглядає в житті:
Тут продемонстровано пусте поле Subject.
І перелік необхідних імен розширення SAN. Критичність розширення визначається за наявності жовтого трикутничка та знака оклику.
На замітку : що таке критичне розширення (critical extension)? Це просто розширення, яке програма повинна перевірити в обов'язковому порядку. Якщо програма бачить таке розширення, програма повинна вміти її обробити та зрозуміти значення в цьому розширенні. Якщо програма не знає, що робити з цим розширенням або програма не може розібрати значення цього розширення, програма зобов'язана відхилити цей сертифікат. Докладніше про порядок поведінки програми.
Примітка: хоч і заявляється, що програма повинна відхилити сертифікат, якщо значення розширення незрозуміле, це не повною мірою стосується розширення SAN. Програма не повинна підтримувати всі форми SAN, а може підтримувати лише деякі форми, наприклад, лише DNS Name. Але якщо підтримувана форма не може бути розпізнаною, сертифікат повинен бути відхилений.
Оскільки розширення SAN є єдиним засобомідентифікації імені сертифіката, цілком логічно очікувати, що це розширення буде позначено як критичне та обов'язкове для обробки додатком.
Який спосіб із двох вибрати? А який вважаєте більш прийнятним. Якщо це сертифікат зовнішнього веб-сервера, доцільно використовувати перший варіант, оскільки за допомогою DN суфіксів можна конкретизувати належність сертифіката до вашої компанії. А так само якщо передбачається доступ із додатків, що не підтримують розширення SAN. Це не обов'язково комп'ютерні програми, це можуть бути програми мобільних пристроїв. З метою уникнення надмірного піару VeriSign'a в моєму бложнику представляю зразково-показовий сертифікат виконаний першим способом на сайті Thawte: https://www.thawte.com/