Чтобы избежать ошибок сертификата, вам нужно пи для отправки сертификата, который соответствует используемому домену. Есть два подхода к этому:
- Используйте один сертификат для обоих доменов, установленных как на пи, так и на главном сервере. Не имеет значения, какой домен клиент использовал в своем запросе, сертификат будет совпадать.
- Выберите сертификат, который ожидает клиент, и отправьте его.
Вариант 1 является более простой и распространенной практикой. Посмотрите сертификат для google.com! Как на пи, так и на главном сервере будет установлен один и тот же сертификат (для обоих доменов). Чтобы получить такой сертификат от Let's Encrypt, вам потребуется главный сервер для запуска веб-сайта для динамического домена pi, а также одна команда certbot для проверки управления обоими доменами одновременно. На сайте главного сервера для имени dyndns не обязательно размещать контент от pi - он просто есть, поэтому Let's Encrypt может проверить, что вы контролируете этот сайт (вы даже можете отключить этот сайт между обновлениями).
Пример команды Certbot для этого (запустите на главном веб-сервере):
letsencrypt certonly --webroot --csr request.csr -w /http/pisite/www -d mypi.spdyn.de -w /http/mainwebsite/www -d maindomain.de
Где request.csrиспользует любой домен в качестве CN и имеет оба домена в поле SAN, /http/pisite/wwwотносится к локальному каталогу, который вы создадите для другого веб-сайта на текущем сервере, связанном с динамическим именем pi, и /http/mainwebsite/wwwявляется существующим каталогом вашего основного веб-сайта.
Вариант 2 более сложен, но дает более «чистый» результат: клиент получает сертификат, соответствующий домену, который он ввел. На raspberry pi запустите nginx с потоковым модулем (или его эквивалентом), который при открытии соединения TLS: исследует поле SNI (без принятия соединения TLS) и, основываясь на включенном в него домене, выбирает, какой восходящий канал направить подключение к. Это позволяет вам выбирать, как вы хотите обрабатывать запросы, сделанные из основного домена на внешний порт, перенаправленные на RasPberry Pi. Вы можете отправить их на основной веб-сервер так же, как если бы они были сделаны на правильном порте, вы можете отправить их на другой порт pi (например, Nextcloud или что-то еще), вы можете завершить их тем же экземпляром nginx и показать любую страницу, которая вам нравится, или просто закрыть соединение. Выбор за вами.
Вот пример конфигурации для этого метода:
stream/sni-switch.conf
# Listen on 443, and on new connection: # if the SNI is mapped herein, handle it on this Nginx # else, forward the whole session to 192.168.1.80:443 (TCP passthrough, no decryption) upstream mainwebserver { server 192.168.1.80:443; } upstream local_https { server 127.0.0.1:1443; } map $ssl_preread_server_name $name { default mainwebserver; pisite.spdyn.de local_https; } server { listen 443; ssl_preread on; proxy_pass $name; } И в nginx.conf
load_module /usr/lib/nginx/modules/ngx_stream_module.so; stream { include /etc/nginx/stream/sni-switch.conf; } ... Чтобы сделать это с Apache, посмотрите это . Пример конфигурации, из которой может выглядеть так:
<VirtualHost *:*> ProxyPreserveHost On ProxyPass "/" "http://192.168.1.80/" ProxyPassReverse "/" "http://192.168.1.80/" ServerName maindomain.de </VirtualHost>