Назад | Перейти на главную страницу

Свяжите сертификат SSL для SQL Server, который не использует полное доменное имя

Мы хотели бы безопасно подключиться к SQL 2008 R2 через Интернет для целей отчетности. Скорость не является большой проблемой для этих небольших наборов данных, и пользователи будут использовать простые программы отчетности (например, Access), которые требуют подключения ODBC, а не своего рода API. В этом сценарии у нас есть SQL Server, работающий в локальной сети (например, sql.mydomain.local), доступ к которому осуществляется из внешнего мира через NAT (например, sql.mydomain.com, порт xyz). Это нормально работает без безопасности, однако нам нужно зашифровать соединения. Самый простой способ сделать это - добавить SSL к серверу SQL. Но вот где я сталкиваюсь с проблемами:

  1. Если я получаю сертификат для внешнего имени (sql.mydomain.com), SQL Server отказывается видеть или использовать внешний сертификат SSL, поскольку это не имя сервера или полное доменное имя, поскольку оно настроено локально (для http://technet.microsoft.com/en-us/library/ms191192.aspx). Добавление сертификата вручную через HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.x \ MSSQLServer \ SuperSocketNetLib, похоже, не меняет этого поведения.
  2. Если я использую самозаверяющий сертификат от контроллера домена, я могу видеть и использовать сертификат в SQL. Однако внешние соединения явно жалуются, что сертификату не доверяют. Если я добавляю контроллер домена в качестве доверенного издателя, то 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, и как только сертификат домена был добавлен в качестве доверенного издателя, клиент смог безопасно подключиться.