У меня есть сервер под управлением Debian 10. Он запускает Apache 2.4 для веб-служб, доступных под https://example.com
, благодаря сертификату LetsEncrypt.
Но он запускает приложение (Subsonic), которое обслуживает веб-интерфейс на порту 4040, на своем собственном веб-сервере, поскольку у меня нет для него vhost и он все еще доступен, когда Apache остановлен. Итак, пока приложение доступно по HTTP на http://example.com:4040
.
Я знаю, как добавить поддержку SSL для виртуального хоста Apache, но как добавить поддержку HTTPS для этого приложения, чтобы оно было доступно на https://example.com:4040
или https://example.com:1234
?
Кроме того, должен ли я использовать другой сертификат SSL, чем тот, который у меня уже есть для этого домена?
Добавьте обратный прокси перед приложением и настройте HTTPS на этом прокси. Удобно, что у вас запущен Apache, который может с радостью отменить прокси за вас.
В настоящее время вы не можете использовать порт 4040, поскольку он уже занят приложением, поэтому, если вы не можете изменить порт приложения или привязать его только к localhost (127.0.0.1 и т. Д.), Вам придется запустить это приложение на другом порту. В этой заметке, если вы хотите запустить это приложение через HTTPS, нет смысла оставлять его доступным по небезопасному протоколу HTTP, поэтому было бы лучше настроить это приложение на привязку к localhost и сделать его доступным только через обратный прокси.
Вам нужен ProxyPass
семейство параметров конфигурации для создания обратного прокси. Вот неполный пример:
Listen <Public IP address of server>:4040
<VirtualHost *:4040>
Protocols h2 h2c http/1.1
ServerName example.com
SSLEngine On
# LetsEncrypt certificates (if not configured in another file)
# SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
# SSLCertificateKeyFile /etc/letsencrypt/live/eample.com/privkey.pem
# Include /etc/letsencrypt/options-ssl-apache.conf
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://127.0.0.1:4040/
ProxyPassReverse / http://127.0.0.1:4040/
</VirtualHost>
Сертификаты должны иметь имя хоста, которое клиент использует для подключения, встроенное в его расширение Subject Alternative Names, поэтому, поскольку вы, похоже, не предлагаете другой хост (example.com
в обоих случаях) вам не понадобится новый сертификат.