1

У меня дома есть Synology NAS, у которого есть веб-интерфейс, который я открываю для общего доступа в Интернет. Внутри моей локальной сети мой NAS имеет имя хоста nas.domain.local. и в общедоступном Интернете у меня есть доменное имя home.notarealdomainname.com. указывая на мой домашний маршрутизатор (который затем перенаправляет порт 7000 на сервер HTTPS моего NAS на порт 443).

Мой NAS поставляется с самозаверяющим сертификатом, который не совсем подходит для этой цели, я хотел бы установить сертификат SNI, который поддерживает оба имени хоста nas.domain.local. в дополнение к home.notarealdomainname.com. - однако все основные CA выполняют некоторую форму проверки домена (как они должны!) но они не могут проверить мой .local. доменное имя, чтобы они не выпустили этот сертификат.

Я не хочу выдавать свой собственный сертификат, так как для удобства использования я бы хотел, чтобы браузеры доверяли этому сертификату.

|источник

3 ответа3

5

Публичные ЦС будут выдавать сертификаты только для публичных доменов. Было время, когда они отказывались от этого поведения, потому что это вызывало проблемы с недавно представленными доменами верхнего уровня. Кроме того, CA выпускает сертификаты только для доменов, которые принадлежат и используются только одной стороной, что не относится к внутренним именам.

Это означает: либо вы принимаете самозаверяющий сертификат один раз на всех внутренних устройствах, либо вам нужно развернуть свою собственную структуру PKI и импортировать соответствующий корневой CA на все устройства.

|источник
0

Я хотел бы установить сертификат SNI

Там нет такого понятия, как сертификат SNI. Это расширение TLS, и это означает, что имя сервера отправляется в ClientHello .

сертификат, который поддерживает оба имени хоста nas.domain.local. в дополнение к home.notarealdomainname.com.

CA, вероятно, не будут выдавать этот сертификат из-за nas.domain.local .

Но его мне не ясно , где выдача запрещено под CA/Browser (CA/B) Основные требования документов (СА и браузеры делают то , что они согласуют в CA/B форумах, они ничего от IETF не следовать или РЛК).

Благодаря home.notarealdomainname.com вы будете удовлетворять требованиям раздела 11.1.1 «Авторизация регистрантом доменного имени». Раздел 11.3 запрещает *.local , но это связано с подстановочным знаком (а не локальным именем).

Поскольку я не могу найти, где ЦС запрещено выдавать сертификат, вам следует спросить ЦС о выдаче сертификата, который включает локальное имя (в дополнение к общему имени, которым вы управляете).

Я не хочу выдавать свой собственный сертификат, так как для удобства использования я бы хотел, чтобы браузеры доверяли этому сертификату.

Вы должны выполнить следующие шаги (даже если вы не совсем хотите это делать):

  1. создать свой собственный CA
  2. создайте CSR со всеми именами, которые вы хотите иметь на сервере
  3. выдать сертификат на основании КСО
  4. подписать сертификат с вашим CA
  5. установите свой CA на свои устройства и машины

Единственное различие между предварительно доверенным списком CA в браузерах и хранилищах сертификатов и вашим CA заключается в том, что вы должны установить свой CA вручную.

Если вам нужно использовать OpenSSL для создания CSR с несколькими дополнительными именами субъекта (например, nas.domain.local и home.notarealdomainname.com), то посмотрите этот вопрос по переполнению стека: сертификат с использованием расширенного ключа работает только в Firefox. В частности, смотрите файл конфигурации OpenSSL.

Наконец, это известная проблема с Интернетом вещей; и в настоящее время не хватает решения. Недавно он был включен в список рассылки по безопасности веб-приложений. См. Предложение: Пометка HTTP как незащищенного:

Я хотел бы предложить рассмотреть четвертую категорию: личное
Устройства (домашние роутеры, принтеры, IoT, малиновые писи в классах,
холодильники):
- по своей природе не может участвовать в системах DNS и CA
- вероятно, в частном сетевом блоке
- пользователь является владельцем сервиса, следовательно, может доверять себе, а не CA

|источник
0

Я предполагаю, что общая проблема, которую вы пытаетесь решить, состоит в том, как включить надежный HTTPS для устройства как для внутренних, так и для внешних клиентов, и вам на самом деле все равно, если у него два разных имени. Если это правда, у вас может быть другой вариант. Если у вас есть контроль над DNS-сервером для вашей внутренней сети, вы можете разрешить home.notarealdomainname.com использовать внутренний IP-адрес для внутренних клиентов. Тогда вам просто нужен сертификат для публичного имени, и вы можете использовать это имя для доступа к нему как внутри, так и снаружи. Вот как я это делаю в BIND на Ubuntu Server 14.04:

/etc/bind/rc.conf.local:

...

zone "home.notarealdomainname.com" in {
    type master;
    file "/var/lib/bind/db.home.notarealdomainname.com"
}

...

/var/lib/bind/db.home.notarealdomainname.com:

$ORIGIN .
$TTL  86400
home.notarealdomainname.com    IN SOA dnsserver.domain.local. myemail.emaildomain.com. (
                               1       ; serial
                               86400   ; refresh (1 day)
                               3600    ; retry (1 hour)
                               172800  ; expire (2 days)
                               3600    ; minimum (1 hour)
                               )
                      NS       dnsserver.domain.local.
$ORIGIN home.notarealdomainname.com.
@                         A        192.168.1.123

По сути, он сообщает вашему локальному DNS-серверу (здесь предполагается, что это dnsserver.domain.local), что он является полномочием для зоны home.notarealdomainname.com (но не notarealdomainname.com , поэтому он не будет мешать другим хостам в этом домене ) и возвращает для него локальный IP-адрес NAS (здесь предполагается, что он равен 192.168.1.123).

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .