Я разместил свой сайт на TCP-порту 91.
Есть ли способ привязать их сертификат SSL к тому же порту 91?
Я разместил свой сайт на TCP-порту 91. Есть ли способ привязать их SSL-сертификат к тому же порту 91?
Я интерпретирую этот вопрос как "Я запускаю свой сайт на http://www.mysite.example:91/ и я также хочу запустить его для HTTPS в https://www.mysite.example:91/"(в этом случае это не копия Несколько доменов SSL на одном IP-адресе и одном порте?, как временно отмечено).
Это можно сделать с помощью Объединение портов, который поддерживается, например, Grizzly (веб-сервер Java). (В вашем вопросе не указано, какой сервер вы хотите использовать.)
Унификация портов может работать для любого протокола, по которому клиент должен говорить первым (например, HTTP, SSL / TLS, но не IMAP, ...).
По сути, сервер пытается определить, какой протокол используется, просматривая начало запроса перед его отправкой. Если он получит GET / ... он может предположить, что это HTTP-запрос. Если он получит ClientHello, он может предположить, что это запрос SSL / TLS (который затем может быть перенаправлен на соответствующий протокол поверх него, если необходимо, в этом случае HTTP через TLS).
Поддержка этой функции довольно необычная, но она работает. Однако вам нужно будет явно указать порт в своем URL-адресе, если он не является значением по умолчанию (80 всегда будет значением по умолчанию для http:// а 443 всегда будет значением по умолчанию для https://).
Я не знаю, что эта функция реализована в Apache Httpd, но в принципе это не проблема. В других ответах упоминается, что две службы (или два процесса) не могут прослушивать один и тот же порт. Это правда, но ничто не мешает одному и тому же серверу / процессу обрабатывать несколько сайтов (Apache Httpd делает это очень хорошо, когда один и тот же процесс прослушивает несколько портов, например 80 и 443, и выполняет VirtualHost отправка в обратном направлении).
Возвращаясь к "возможный повторяющийся вопрос", другим решением могло быть использование RFC 2817, как упоминалось в этот ответ. К сожалению, хотя в этом ответе упоминается этот RFC, журналы, которые он показывает, показывают, что curl до трафика SSL / TLS не было простого HTTP-трафика, что указывало бы на то, что он использовал указание имени сервера (SNI), а не RFC 2817. Кроме того, мне не известно о какой-либо реализации RFC 2817, тогда как curl на момент этого ответа поддержка SNI уже была.
Поддержка RFC 2817 намного сложнее, чем поддержка унификации портов, поскольку требует поддержки как на стороне клиента, так и на стороне сервера, включая возможность обновления в середине протокола. (Это еще не конец света, SMTP, LDAP и другие могут это сделать, но они уже широко поддерживаются для этих протоколов.)
Напротив, для унификации портов требуется только изменить механизм начальной отправки на стороне сервера. Просто указав порт явно в URL-адресе, любой браузер будет поддерживать его на стороне клиента.
Не работает. Вы можете привязать только одну службу к порту.
Две службы не могут прослушивать один и тот же порт в одной системе с помощью TCP. Вы можете использовать NAT и направлять трафик из разных мест на разные внутренние адреса на одном и том же порте, но внешний IP-адрес не может использовать обе службы на одном порте.
Когда пользовательский агент или клиент инициирует запрос HTTPS, он использует порт по умолчанию, который 443. Порт по умолчанию для HTTP: 80.
Если ваш сервер прослушивает другой порт (91), вам нужно перенаправить порт 443 на этот порт, поэтому, когда кто-то набирает https://www.example.com/, он будет указывать на сервер, прослушивающий порт 91.
Вы не можете иметь http://www.example.com/ и https://www.example.com/ работает на тот же порт, так как только один процесс может прослушивать порт. Вы можете настроить прослушивание на одном сервере, если у него несколько IP-адресов.
Если ваш сервер будет есть только сайт https тогда переадресация с 443 на 91 и переключение вашего сервера на HTTPS будет работать.