Следующая ситуация - файловая база опубликована через IIS, если заходить через тонкий или веб-клиент недоступны интернет-сервисы 1С, выдает ошибку «Удаленный узел не прошел проверку».

Если зайти напрямую в файловую базу через толстый клиент, то всё работает.

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

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

2. Следующий по популярности совет - не хватает прав пользователю, от имени которого запускается пул приложений IIS. Вместо AppPoolIdentity советуют включить локального пользователя или LocalSystem (полные права в ОС, так себе решение). Результат - без изменений.

3. Проверка настроек брэндмауера - для приложений w3wp добавлены разрешающие правила, включен лог - записи drop отсутсвуют. Сторонних антивирусов не установлено Результат - без изменений.

4. Замена файла cacert.pem в каталоге bin платформы (https://fserver.1c.ru/its/files/public/1cits/exe/cacert/cacert.zip) - этот способ советовали раньше для старых версий платформы при обновлении одного из корневых сертификатов. По идее он не должен повлиять на результат, но после замены файла заработал 1С: Контрагент! Но остальные сервисы по прежнему с ошибкой, например, монитор портала 1С.

5. Самая полезное оказалось описание проблемы на сайте ИТС (https://its.1c.ru/db/metod8dev/content/5949/hdoc) - по инструкции включаем лог CAPI2 и видим такие же ошибки как в примере в статье:

URL             —     http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1-1.crt
Result            —    Возврат из операции произошел из-за превышения времени
subjectName        —    *.1c.ru
RevocationResult    —    Невозможно проверить функцию отзыва, т.к. сервер отзыва сертификатов недоступен

В статье ИТС указано, что чаще всего проблема из-за ограничений доступа к интернет-ресурсам, установленными администратором интрасети - но я не нашел где еще можно проверить эти ограничения.

Также там описан способ игнорирования (на свой страх и риск) ошибки проверки отзыва сертификата (в файле conf.cfg добавить строку IgnoreServerCertificatesChainRevocationSoftFail=true), но это не помогло.
  
Еще одна статья по теме, но там в основном про прокси - https://its.1c.ru/db/metod8dev/content/5941/hdoc.

Итог - исходя из последнего пункта (статьи ИТС), на основании которого мы нашли в логах конкретные ошибки, кажется, что проблема всё-таки в правах пользователя, но на предыдущих шагах мы уже проверяли запуск пула приложений с расширенными правами и это не помогло. Уже не знаю куда копать дальше.

Update

Проверил опубликованную серверную базу - сервисы работают, получается в этом случае от имени пользователя сервера 1С происходит подключение.

1C Контрагент перестал работать (из пункта 4)

(0) > проблема всё-таки в правах пользователя, но на предыдущих шагах мы уже проверяли запуск пула приложений с расширенными правами и это не помогло

Вы не те «расширенные права» проверяли, LocalSystem это про другое немножко. Создайте обычную учётную запись, типа USR1CV8, как это делается в серверном варианте, и явным образом назначьте её для пула приложений IIS, — тогда вы сможете получить доступ к локальному хранилищу сертификатов этого пользователя и досконально диагностировать эту ситуацию с сертификатами. Также брандмауэр неплохо бы вообще полностью отключить, хотя для проверки, возможно вы там ошиблись как-нибудь.

(0) А через не файловую базу пробовали публиковать? Так же рекомендую обновить платформу до последней и переопубликовать веб-сервисы от имени Админа ОС.

(0) Так же дайте полные права к файлам базы 1С всем пользователям ОС.

(4) > дайте полные права к файлам базы 1С всем пользователям ОС

Вам как архитектору виднее, конечно, но вообще это какой-то вредный совет, по моему скромному мнению, да ещё и бессмысленный, — причём вообще тут может быть файл базы данных?

(2) Вы правы. Я в начале не придал значения в статье ИТС той части, где описано под каким пользователем ошибка в логе CAPI2. Проверил - и даже в случае с Local System там был другой пользователь - который авторизован на веб сервере.

На веб-сервере установлена авторизация ОС. Созданы локальные пользователи именно для веб-приложения, то есть они не подключаются к RDP.
И получается, что есть 3 места, где можно указать авторизацию:
1) Непосредственно авторизация пользователя при доступе к веб-серверу;
2) Авторизация в настройка пула приложений (по умолчанию "Удостоверение пула приложений");
3) В основных настройка приложения в разделе "Физический путь" настройка "Подключаться как" (по умолчанию "сквозная проверка").

Протестировав все возможные комбинации авторизаций и проверяя лог ошибок я выяснил, что в ошибке в логе происходит под пользователем, указанным в настройке 3 или в случае настройки по умолчанию (сквозная) используется логин 1 (авторизация в пункте 2 не влияет на данную ошибку).

После этого я попробовал авторизоваться (здесь и далее это авторизация по пункту 1 выше) под локальным администратором и ошибки не было.

Далее я попробовал изначального локального пользователя добавить в группу "Power users" и вроде это помогло - открылся монитор портала 1С. Но другие сервисы почему-то не открылись и через какое-то время и монитор перестал. Я пробовал добавлять в разные группы и в конечном счете даже добавил в группу "Администраторы" и тоже почему-то не заработало. При этом локальный Администратор работает без ошибок и тот же USR1CV8 (при проверке северной базы) тоже. Может конечно там какое-то кэширование и изменение групп не отразилось полноценно, но после каждого изменения я перезапускал пул приложения.

Складывается такое ощущение, что работает без ошибки с «реальными» пользователями для которых есть своя папка и под которыми что-то работало в системе, а пользователь добавленный только для авторизации на веб-сервере не хочет нормально работать (пробовал включать в настройках пула «Загружать профиль пользователя» - не помогло).


Исчерпав дальнейшие способы решения и я решил переключиться на саму 1С. Я проверил в этих же условиях самописную обработку, где устанавливается HTTPS-соединение без ошибок и решил разобраться - может в типовой как-то по особому проверяется сервер, к которому идет подключение. Изучил код и нашел единственное значимое отличие, в расширение изменил его:

Было:
Возврат Новый ЗащищенноеСоединениеOpenSSL(Неопределено, Новый СертификатыУдостоверяющихЦентровОС);
*здесь я привожу итоговые параметры, которые передаются в конструктор в данном конкретном случае

Стало
Возврат Новый ЗащищенноеСоединениеOpenSSL();

После данного изменения ошибка ушла и сервисы стали работать быстро и без ошибок.
Но не знаю как это отразится на отправке ЭДО, где используется ЭЦП. И я отношусь к этому как к временному решению.

Сам факт, что это помогло как будто подтверждает, что проблема с доступом к каким-то локальным сертификатам. Но почему тогда ошибка в логе с подключение к серверу CRL.

Возвращаясь к группам пользователям - очень странные результаты, но может действительно, что-то не обновилось, но пока нет возможности перезагрузить сервер. Может быть где-то есть какие-то политики или настройки доступа к сертификатам для пользователя помимо групп?

PS Брэндмауэр отключал полностью еще во время первых тестов - результата не было.

Может поставить апач и не копать винду?

(7) апач тоже придется копать, так как мало опыта, например, для решения задач:
- авторизация, удобное добавление логина и пароля для пользователя веб-сервера;
- отдельный экземпляр процесса для определенной публикации (в IIS можно создать отдельный пул на каждую публикацию).

(6) > Протестировав все возможные комбинации авторизаций и проверяя лог ошибок я выяснил, что в ошибке в логе происходит под пользователем, указанным в настройке 3 или в случае настройки по умолчанию (сквозная) используется логин 1 (авторизация в пункте 2 не влияет на данную ошибку).

Вы точно уверены в этом, ничего не перепутали? К сожалению, у меня нет сейчас возможности проверить самому, но вообще говоря, доступ к локальным ресурсам ОС (включая доступ к хранилищу сертификатов пользователя) осуществляется именно на уровне самой платформы 1С (точнее, веб-компонента для работы с файловой базой данных), запущенной в рамках пула приложений родительского процесса w3wp.exe, — поэтому сомнительно, чтобы первый и второй варианты играли в данном случае какую-то роль. А вот во втором варианте вы как раз и указываете того самого единственного пользователя, от имени которого будет запускаться w3wp.exe и будут осуществляться все локальные операции с компонентами ОС, включая и работу с сертификатами. Дальше смотрите в логах CAPI2 возникающие ошибки сертификатов и устраняете их конкретно для этого данного локального пользователся. Если мне не изменяет память, я именно так всегда делал и в конце концов всё начинало работать.



> Складывается такое ощущение, что работает без ошибки с «реальными» пользователями для которых есть своя папка и под которыми что-то работало в системе, а пользователь добавленный только для авторизации на веб-сервере не хочет нормально работать (пробовал включать в настройках пула «Загружать профиль пользователя» - не помогло).

Ну да, именно так всё и есть, насколько я понимаю. Во-первых, при авторизации по пунктам 1 и 3 учётные данные используются исключительно для авторизации на веб-сервере — и всё, и больше ни для чего. Сама же платформа, как уже сказано выше, запускается от имени пользователя, ассоциированного с удостоверением пула приложений (т.е. пункт 2 в вашей классификации). Во-вторых, просто добавленный пользователь, который ещё ни разу не авторизовался в системе, представляет собой просто набор прав, и для него ещё не создаётся никакая локальная инфраструктура, в частности то же хранилище сертификтов, например. Поэтому и требуемые операции с сертификатами нормально в полной мере осуществляться не могут.

Вообще, очень непонятно, почему у вас сработала авторизация по пункту 1 под локальным администратором. Ещё более непонятно, почему у вас то сначала работает, а потом вдруг перестаёт работать. Похоже, что вы в спешке где-то что-то напутали всё-таки, мне кажется.