Кто бы ни управлял сервером, ему нужен действующий сертификат, соответствующий имени хоста, используемому для посещения сайта.
Если приложение посещается только с локального компьютера, просто вызовите его, используя 127.0.0.1 вместо внешнего IP-адреса, без HTTPS. Поскольку данные никогда не покидают машину, использование HTTPS бессмысленно. (В этой ситуации вы, вероятно, также захотите привязать веб-сервер к 127.0.0.1, чтобы предотвратить посещение сайта другими).
Если к приложению обращаются и с других компьютеров в сети, и вы хотите использовать SSL, тому, кто запускает приложение, потребуется сертификат, соответствующий имени хоста в URL-адресе. Вы не можете получить сертификаты для частных IP-адресов (например, 192.168.1.1 или 10.2.3.4), но если это общедоступный IP-адрес, вы можете получить для него сертификат.
Однако гораздо разумнее указать какое-либо имя хоста (DynDNS, если это разрешено вашим ЦС, или субдомен домена, принадлежащего тому, кто запускает приложение) на IP-адрес. Например, компания Example, владеющая example.com, может использовать webapp.example.com, указать его на свой сервер и получить для этого сертификат. Тот, кто запускает сервер, должен будет развернуть этот сертификат, и ваше приложение должно быть спроектировано таким образом, чтобы принимать его. Вам потребуется один сертификат для каждого сайта клиента. Нет (безопасного) способа обойти это, если вы хотите, чтобы он работал в готовых браузерах.
Возможно, вы сможете упростить этот процесс, предоставив автоматизированные рабочие процессы для запроса сертификатов или даже создав собственную службу, подобную dyndns, для ваших клиентов, где они смогут зарегистрировать yourname.yourservice.com, указать желаемый IP-адрес и получить сертификат для своего хоста от вас. (Это требует от них большого доверия к вам и является своего рода антипаттерном, но, возможно, наименее неприятным решением.) Вам все равно нужно убедиться, что у каждого клиента есть собственный сертификат. Самое главное, НЕ пытайтесь получить подстановочный сертификат для такого домена и распространять сертификат и закрытый ключ вместе с приложением. Любой, у кого есть копия вашего приложения, сможет атаковать «безопасные» соединения. Что еще более важно, как только ЦС узнает об этом, ваш сертификат будет отозван, и это предотвратит доступ к сайту с очень суровым предупреждением и никаким способом обойти предупреждение. И, вероятно, у вас возникнут проблемы с ЦС из-за нарушения вашего соглашения с ними о защите закрытых ключей.
Однако другой вариант — просто сгенерировать самозаверяющий сертификат при первом запуске и вывести отпечаток пальца. Не используйте один и тот же жестко закодированный сертификат для всех установок, как бы это ни было удобно, поскольку закрытый ключ, распространяемый среди всех ваших клиентов, не является закрытым. Этот сертификат будет генерировать предупреждение, которое вы видите. Теперь вам нужно будет добавить этот сертификат или исключение для этого сайта в браузеры, используемые для посещения приложения. Пока вы проверяете отпечаток пальца, это безопасно — это просто дополнительная работа. В зависимости от того, какой браузер используют пользователи, могут быть способы легко развернуть такой сертификат на нескольких машинах.
person
Jan Schejbal
schedule
06.04.2014
