Мы хотели бы безопасно подключиться к SQL 2008 R2 через Интернет для целей отчетности. Скорость не является большой проблемой для этих небольших наборов данных, и пользователи будут использовать простые программы отчетности (например, Access), которые требуют подключения ODBC, а не своего рода API. В этом сценарии у нас есть SQL Server, работающий в локальной сети (например, sql.mydomain.local), доступ к которому осуществляется из внешнего мира через NAT (например, sql.mydomain.com, порт xyz). Это нормально работает без безопасности, однако нам нужно зашифровать соединения. Самый простой способ сделать это - добавить SSL к серверу SQL. Но вот где я сталкиваюсь с проблемами:
Все пути вперед кажутся немного шаткими: 1. Настройте локальный домен только для этого сервера с публичным именем (например, mydomain.com) и добавьте туда машину, чтобы полное доменное имя соответствовало внешнему сертификату, сгенерированному надежным издателем, надеюсь Тогда SQL увидит и будет использовать сертификат. 2. Попросите пользователей изменить файл своих хостов для создания cname sql.mydomain.local на sql.mydomain.com.
Я что-то упустил в своем понимании? Есть ли способ обойти ограничения SQL в отношении использования сертификата, который не является полным доменным именем? Если я куплю сертификат для sql.mydomain.com с альтернативным именем субъекта sql.mydomain.local, будет ли SQL видеть и использовать его?
Ответ на эту проблему - использовать сертификаты альтернативного имени субъекта, чтобы SQL был доволен. Я тестировал с использованием сертификата, выданного доменом, выполнив несколько отличных шагов здесь: http://williamdurkin.com/2013/03/sql-server-connection-encryption-and-net-framework-4-5/
Этот сгенерированный сертификат мог быть просмотрен и использован SQL Server, и как только сертификат домена был добавлен в качестве доверенного издателя, клиент смог безопасно подключиться.