Digi AnywhereUSB 24 Plus : AnywhereUSB Manager и ошибка подключения "ERROR :SSL Server verification (passed in) error: (20) unable to get local issuer certificate"

После первичной настройки USB-концентратора Digi AnywhereUSB 24 Plus и описания групп подключения потребуется установить и настроить пакет, содержащий драйверы для трансляции USB-портов на конечные клиентские или серверные системы - AnywhereUSB Manager. Типовые проблемы, которые могут возникнуть при подключении конечных систем к концентратору описаны в разделе документации AnywhereUSB Plus User Guide – Troubleshooting. Однако иногда встречаются проблемы с не очень очевидным и документированным характером. Разберём одну из таких ситуаций.

Итак, имеем предварительно настроенный концентратор, с которого нужно транслировать лицензионный USB-ключ на виртуальный сервер на базе Windows Server 2012 R2. На сервере установлен программный пакет AnywhereUSB Manager актуальной версии 10.1.24.174 (17.06.2021). В интерфейсе утилиты AnywhereUSB Manager наблюдаем невозможность подключения сервера к концентратору со статусом "Unable to connect".

Чтобы получить более подробную информацию о происходящем, вызываем пункт меню Help > System Messages.

Фактически в этом окне будет отображено содержимое текстового лога awusb.log, расположенного в каталоге C:\windows\system32\config\systemprofile\AppData\Roaming\AnywhereUSB.

В логе в нашем случае видно множество повторяющихся ошибок вида:

... ERROR :SSL Server verification (passed in) error: (20) unable to get local issuer certificate
... INFO  :SSL_connect error 1(-1) when connecting to kom-mc09.holding.com:18574, (null)

Помимо лога на стороне конечного сервера, мы можем посмотреть содержимое лога на самом концентраторе в меню System > Administration - Logs

Здесь мы также видим множество повторяющихся ошибок вида:

... awusbd[2078]: Error in SSL_accept, error:14094418:lib(20):func(148):reason(1048)

Очевидно, что проблема как то связана с сертификатами, которые используют концентратор и AnywhereUSB Manager для защиты сетевого обмена.

Как я и говорил ранее, подобная проблема в документации не освещена, поэтому обращаемся к форуму поддержки Digi и обнаруживаем там вопрос с описанием аналогичной проблемы AnywhereUSB 2 Plus not recognize certificate. Не смотря на свою почти годичную давность вопрос так и не имеет никакого ответа от специалистов Digi.

Характерно для этой проблемы то, что она может проявиться лишь в том случае, если мы в процессе первичной настройки концентратора заменили автоматически сгенерированный само-подписанный SSL-сертификат на сертификат, выданный каким либо доверенным (локальным или публичным) центром сертификации. Так что же не так с нашим установленным на концентратор сертификатом? Ведь он успешно установился и работает для защиты соединения со встроенным веб-сервером и никаких ошибок при этом интерфейс управления нам не выдавал.

Вообще сертификат можно установить в двух разных местах веб-консоли в разделе настроек Services:

1. в подразделе Web administration > SSL Certificate
2. в подразделе AnywhereUSB > TLS identity certificate

В документации на продукт мы не найдём ни единого слова о том, каким образом должен быть сформирован контент, вставляемый в данные поля. Единственное, что нам известно, это то, что если установлен первый сертификат для Web administration, но не установлен второй сертификат для AnywhereUSB, то и для последней службы используется установленный сертификат первой.

Таким образом в нашем случае сложилась ситуация, когда сертификат, успешно установленный для службы Web administration, без проблем работает для защиты встроенного веб-сервера, но с этим же сертификатом в службе AnywhereUSB наблюдаются какие-то проблемы, приводящие к невозможности подключения клиентов через порт TCP 18574.  

На веб-интерфейсе управления концентратором есть встроенная справка в виде всплывающих подсказок, где мы можем видеть, что в поля установки сертификата необходимо скопировать содержимое закрытого ключа и сертификата, связанного с этим ключом.

В нашем случае, с помощью утилиты openssl был сгенерирован закрытый ключ и запрос сертификата, на основании запроса в локальном доменном ЦС был получен соответствующий сертификат и выгружен в формате Base-64. Затем мы объединили контент закрытого ключа и полученного сертификата и записали это значение в поле SSL Certificate в настройках концентратора:

-----BEGIN RSA PRIVATE KEY-----
MIIJKQ...
...
Приватный ключ от сертификата концентратора Digi
...
...tOiSezt
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIGmj...
...
Сертификат концентратора Digi
...
...SozmUc=
-----END CERTIFICATE-----

После изучения проблемы стало понятно, что подобный формат контента и является корнем возникшей проблемы.

Выяснилось, что когда AnywhereUSB Manager инициирует подключение к концентратору, он получает от концентратора его SSL-сертификат и в случае, если сертификат не является само-подписанным, пытается получить ещё и сертификат удостоверяющего ЦС. Это в нашем случае и приводит к возникающим ошибкам SSL_connect.

Для решения проблемы необходимо расширить контент, вставляемый в поле SSL Certificate, сертификатом удостоверяющего ЦС.

-----BEGIN RSA PRIVATE KEY-----
MIIJKQ...
...
Приватный ключ от сертификата концентратора Digi
...
...tOiSezt
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIGmj...
...
Сертификат концентратора Digi
...
...SozmUc=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFizC...
...
Корневой сертификат Центра сертификации
...
...1bg==
-----END CERTIFICATE-----

И по всей видимости, если в цепочке сертификата используются промежуточные ЦС, их сертификаты также потребуется включить в этот контент.

В нашем случае сразу после обновления контента поля SSL Certificate с учётом добавления сертификата ЦС, соединение с концентратором со стороны AnywhereUSB Manager было успешно установлено и описанные ранее ошибки пропали.

На лицо явная недоработка логики работы интерфейса управления. Всей этой нудной истории могло и не быть, если бы при сохранении настроек концентратора более тщательно проверялся контент с полями для вставки сертификатов и выдавалось предупреждение о нехватке сертификата удостоверяющего ЦС.   

Ещё одной занятной "баго-фичей", которую удалось обнаружить в ходе боёв, является то, что после того, как мы заменили само-подписанный сертификат, возможность возврата к само-подписанному сертификату у нас фактически пропала. То есть, во всплывающих подсказках и в документации указано, что можно просто очистить поле и тогда вместо установленного сертификата вновь начнёт использоваться само-подписанный. Однако по факту у нас это не работало (ни после сохранения настроек, ни даже после перезагрузки концентратора … установленный нами сертификат торчал, как вкопанный) и поэтому пришлось идти до конца с разматываем вопроса неработающего сертификата … хотя рука снова тянулась к кнопке Reset :)