[alibek]

Есть у меня сайт на Apache, сконфигурированный примерно так:

<VirtualHost *:443>
    ...
    ServerName "My Site"
    ServerAlias site.ru www.site.ru

Сертификат я использую от Let's Encrypt, на перечисленные домены, с использованием certbot.

В логах веб-сервера сабжевые ошибки:

[warn] RSA server certificate CommonName (CN) `site.ru' does NOT match server name!?

Текстово-описательный ServerName сделан так специально, мне это удобно.

Обычно я, когда использовал собственные сертификаты, задавал аналогичный CN, а в AltNames указывал собственно домены.

Можно ли сохранить ту же схему, настроив certbot на описательный CN?

Или придется от этой схемы отказаться и в ServerName указывать доменное имя?

[stalker86]

Собственно или хакать код апача или смириться. Модуль ссл апача сравнивает сервер нейм и основное имя в сертификате, что в общем-то вполне логично. А писать отсебятину в сервен нейм.. скажем к плохая идея. Не для этого он.

[alibek]

С апачем понятно.

Я имею ввиду, можно ли в Let's Encrypt сделать описательный CN? Может есть какой волшебный параметр у certbot?

 

33 минуты назад, stalker86 сказал:

А писать отсебятину в сервен нейм.. скажем к плохая идея

Не я это придумал, я это уже где-то видел и задумка кажется толковой.

В ServerName и CN указывается нормальное имя сервиса (например "User Portal" или "Company LLC"), а доменные имена перечисляются в ServerAlias и AltNames. Это изящно и максимально совместимо.

[vop]

Честно говоря, не встречал, что бы в ServerName писали Site Name. Но Апач будет всегда писать в логи про несовпадение имен сервера и CN. Если они на совпадают.

 

 if (strNE(s->server_hostname, cn)) {
            ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
                         "%s server certificate CommonName (CN) `%s' "
                         "does NOT match server name!?",
                         ssl_asn1_keystr(type), cn);
  }

Простой там код.

[stalker86]

1 час назад, alibek сказал:

Не я это придумал, я это уже где-то видел и задумка кажется толковой.

В ServerName и CN указывается нормальное имя сервиса (например "User Portal" или "Company LLC"), а доменные имена перечисляются в ServerAlias и AltNames. Это изящно и максимально совместимо.

Абсолютно бестолковая и скорее всего тот кто сиё придумал даже маны читать не умеет. Ну не предназначен он для этого.

Опять  же Вы не знаете на каком имени у Вас какой сервис живёт?
что насчёт запихать  это в сертификат -тоже из области ненаучной фантастики, LE прежде чем выписать сертификат проверяет доменные имена, посредством challenge-tokens

Соответственно если это имя не найдено в DNS то сертификат просто не будет выпущен

[rm_]

2 hours ago, alibek said:

CN указывается нормальное имя сервиса (например "User Portal" или "Company LLC")

Откуда Let's Encrypt знать, что ваш Portal это именно User Portal, а не какой-либо другой? Откуда ему знать что вы представляете Company LLC?

С чего вдруг они обязаны под этим подписываться?
В автоматическом режиме они проверяют домены, соотв-но в серте нигде ничего кроме проверенных ими доменов быть не может.
 

2 hours ago, alibek said:

Это изящно и максимально совместимо.

Это дрочерство на пустом месте, вам заняться нечем.

[stalker86]

Ну или попытка забивания гвоздей микроскопом. Но полностью согласен что  это абсолютно никому не нужное занятие.

[alibek]

16 часов назад, vop сказал:

Если они на совпадают.

Так они совпадают.

 

15 часов назад, stalker86 сказал:

LE прежде чем выписать сертификат проверяет доменные имена, посредством challenge-tokens

Это как раз не проблема, я использую ключ --webroot и задаю корень сайта вручную.

 

15 часов назад, rm_ сказал:

Откуда ему знать что вы представляете Company LLC?

А вот с этим согласен, это будет уязвимостью.

Да, значит с текстовым CN не судьба.

 

15 часов назад, stalker86 сказал:

Опять  же Вы не знаете на каком имени у Вас какой сервис живёт?

Сервис может жить на разных доменах и они даже могут меняться.

А вот имя сервиса будет постоянным.

Например сайт "Provider" может обитать на доменах prov.ru, provider.ru, www.prov.ru, w3.prov.ru, m.prov.ru, www.prov.com, prov.net — какой из них считать основным и записать в CN? А с использованием текстового ServerName все очень логично и красиво.

Но текстовый ServerName действительно несет потенциальную уязвимость, про это я как-то не подумал.

[stalker86]

1 час назад, alibek сказал:

Это как раз не проблема, я использую ключ --webroot и задаю корень сайта вручную.

 

Причём здесь вебрут? Имя которое Вы прописываете в servername не доступно в ПРИНЦИПЕ и на него сертификат не может быть выписан от слова НИКАК.

 

1 час назад, alibek сказал:

Сервис может жить на разных доменах и они даже могут меняться.

А вот имя сервиса будет постоянным.

Например сайт "Provider" может обитать на доменах prov.ru, provider.ru, www.prov.ru, w3.prov.ru, m.prov.ru, www.prov.com, prov.net — какой из них считать основным и записать в CN? А с использованием текстового ServerName все очень логично и красиво.

Но текстовый ServerName действительно несет потенциальную уязвимость, про это я как-то не подумал.

и что? Вы не знаете какие имена у Вас относятся к тому или иному сервису? Вы пытаетесь изобре6сти велосипед с квадратными колёсами

[alibek]

18 минут назад, stalker86 сказал:

Вы не знаете какие имена у Вас относятся к тому или иному сервису?

Я перечислил 7 доменов и они все относятся к одному и тому же сервису и являются одним и тем же сайтом.

Какой именно домен из семи выбрать в качестве CN? Даже если выбирать домены нижнего уровня, таких четыре, какой из четырех выбрать?

Нет критериев, по которым какой-то один домен был бы более важным, поэтому и нет критериев выбора домена в CN.

В таком случае какой-то синтетический принципиально недоступный домен (текстовое название) для CN — хороший выбор.

[stalker86]

Как сказали чуть выше - "Это дрочерство на пустом месте, вам заняться нечем. "

 

Блин. ну выберите самое короткое или легко произносимое имя как основное. 

CN изначально подразумевает, что это основное имя и оно доступно. А не отсебятина/ патчьте вручную апач и прочие веб-сервисы, поддерживаете это  самостоятельно в актуальном виде...или не страдайте ненужной фигнёй.

 

P.S. Никто Вам не запрещает и не мешает давать осмысленные имена для конфигов  того или иного виртхоста, исходя из назначения вот этого виртхоста/сервиса

[zhenya`]

вам придется разделять. браузеры ругаются когда домен не такой как CN в сертификате.

[stalker86]

20 часов назад, zhenya` сказал:

браузеры ругаются когда домен не такой как CN в сертификате.

Опять же LE не выпишет сертификат на левый CN..

[alibek]

22 часа назад, zhenya` сказал:

браузеры ругаются когда домен не такой как CN в сертификате.

Если домен есть в AltNames, то не ругаются, все прекрасно работает.

1 час назад, stalker86 сказал:

Опять же LE не выпишет сертификат на левый CN

Да, это аргумент. Так же как потенциальная уязвимость с подделкой текстового CN.

Остальное — так не делают, ServerName не для этого — это не аргументы, а привычка и вкусовщина, никаких технических препятствий тут нет.

На внутренних служебных сервисах, которые подписываются самоподписанным CA, текстовый CN прекрасно работает и выглядит вполне серьезно.

[vop]

2 hours ago, alibek said:

Остальное — так не делают, ServerName не для этого — это не аргументы, а привычка и вкусовщина, никаких технических препятствий тут нет.

На внутренних служебных сервисах, которые подписываются самоподписанным CA, текстовый CN прекрасно работает и выглядит вполне серьезно.

Если вы напишите в ServerName что-то типа "Мой крутой ://Сервер\\: на антресолях", то ваш сертификат не будет скушан. Знаете почему? И какой CN в этом случае будет "срабатывать"?

 

[alibek]

16 минут назад, vop сказал:

то ваш сертификат не будет скушан

Я ведь уже с этим согласился.

Но для служебных сервисов, где допустим самоподписанный CA, это удобно.

[vop]

7 hours ago, alibek said:

Я ведь уже с этим согласился.

Но для служебных сервисов, где допустим самоподписанный CA, это удобно.

Я просто хотел сказать, что как раз технические ограничения и есть, ибо апач делает разбор написанного в ServerName, выдергивая отуда дамен/ip и номер порта.

 

Кстати, не совсем понятно, в чем удобство в "Именах собственных" для серверов, и чем они лучше доменных имен, если учесть, что домены доступны в сети по DNS?

[alibek]

1 минуту назад, vop сказал:

Кстати, не совсем понятно, в чем удобство в "Именах собственных" для серверов, и чем они лучше доменных имен, если учесть, что домены доступны в сети по DNS?

Я уже приводил выше пример — у домена может быть несколько доменных имен, из которых нельзя выделить один главный, они все равнозначны. Почему в CN указан prov.ru, а не prov.net или provider.ru? Монетку кидали?

Ну и запись в сертификате "Сертификат выдан для: Абонентский портал Мегателеком" на мой взгляд смотрится лучше, чем "Сертификат выдан для: portal.megatelecom.ru" (или, если хорошие домены разобрали, "Сертификат выдан для: portal.megatelecom-moscow.ru").

[vop]

1 hour ago, alibek said:

Я уже приводил выше пример — у домена может быть несколько доменных имен, из которых нельзя выделить один главный, они все равнозначны. Почему в CN указан prov.ru, а не prov.net или provider.ru? Монетку кидали?

Ну и запись в сертификате "Сертификат выдан для: Абонентский портал Мегателеком" на мой взгляд смотрится лучше, чем "Сертификат выдан для: portal.megatelecom.ru" (или, если хорошие домены разобрали, "Сертификат выдан для: portal.megatelecom-moscow.ru").

Не имеет значения, какой именно домен будет записан в cn (от слова - вообще), лишь бы это был домен или URL (как ни странно звучит). Я даже не совсем понял, в чем был вопрос про выделение домена для cn записи. Для "абонентского портала" есть более естественное место -  organizational unit, где ему самое место, и где его ожидает любой софт. разбирающий x509. Ну и последнее, я не уверен, что все клиенты нормально будут отдавать сертификаты с произвольным CN.

 

RFC 6125 в принципе предполагает такой варинат с текстом в CN и с доменом в alt names URI,  но крайне не рекомендует это делать по нескольким причинам, в том числе и из-за возможных граблей.

[rm_]

7 hours ago, alibek said:

"Сертификат выдан для: Абонентский портал Мегателеком" на мой взгляд смотрится лучше

У публичных CA это называется EV-сертификаты, и стоит отдельные деньги.
 

7 hours ago, alibek said:

несколько доменных имен, из которых нельзя выделить один главный, они все равнозначны.

Выберите один и не путайте абонентов.

 

5 hours ago, vop said:

Почему в CN указан prov.ru, а не prov.net или provider.ru?

Потому что именно он указывался вами на внешней рекламе, на листовках, на визитках. Или на всём этом тоже по семь доменов? Бред какой-то.

[tokra]

Зачем разводить треп бессмысленный? 

Цитата

 SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. 

https://www.ssl.com/faqs/common-name/