| ||||
| ||||
сервер с CSP KC1 3.0.3293 (лицензия CSP+TLS); Windows 2003, полностью пропатчен; у клиентов тоже уже 3.0; двухсторонняя аутентификация на веб-сайте на asp под IIS, ГОСТ 94; ссылки на списки отозванных и на точки распространения в Центре сертификации/всех сертификатах традиционно очищены; наблюдаем, что периодически "забывается" сертификат, которым авторизовался клиент (т.е. функция asp, которая возвращает subject сертификата - вдруг при очередном переходе пользователя со страницы на страницу возвращает пусто; в параметрах ServerVariables о сертификате клиента - тоже становится пусто); проявляется у многих пользователей; я сначала думал, что в 3.0 веден таймаут SSL-сессии некий - но бывает, выпадание происходит иногда почти сразу после открытия предыдущей страницы. при этом при Windows 2000, CSP+TLS 2.0 и раньше при 1.1 все было стабильно. наблюдаю на двух серверах с Windows 2003 (т.е. от машины вроде не зависит); вроде бы эффект не проявляется, если у клиента 1.1 настройки IIS - задан сертификат узла, Ignore client certificate для всего сайта и Accept client certificate для подкаталога со страничками, требующими авторизации. Со страничек, требующих авторизации, есть ссылки на gif в других подкаталогах сайта, не требующих авторизации (с настройкой Ignore client certificate). Что-то менять в подобной структуре не хочется, и в предыд. версиях Windows и CSP+TLS все ведь стабильно работало. Нет ли каких идей, как решить проблему? (не знаю точно, связана ли она с CSP 3.0 или реализацией SSL в Windows 2003/IIS6...) | ||||
Ответы: | ||||
| ||||
Если есть тестовый environment, то попробуйте поставить Crypto-Pro Winlogon на сервер, без лицензий и настройки. | ||||
| ||||
Не помогло. Поставил на резервный Win2003-сервер - WinLogon 1067. Перезагрузился. Лицензионный ключ не вводил (для WinLogon не покупали). Переключил в кластере всех пользователей временно только на этот сервер [до этого, забыл сказать, был кластер двух машин для распредения нагрузки между IISами; а тут включили только одну третюю машину]. За 20 мин. - 150 ошибок на 1500 обращений пользователей к страницам :((( Ошибки в логе, кстати, чаще кучкуются - несколько секунд все хорошо, потом раз и нескольким пользователям ошибка, что якобы сертификат не выбран, потом дальше все работают (тем, у кого ошибка, потребуется перезапускать браузер, чтобы автовторизоваться на сайте). Еще, кажется, ошибки чаще на объемных html(т.е. asp)-страницах (~150 кб) и при импорте. Есть еще идеи? P.S. Сервис паки в CSP 3293 не ставил (судя по их описанию, вроде бы не нужны. или нужны?) | ||||
| ||||
На сервере, Вы написали, сертификат с алгоритмом ГОСТ ..94. Вопросы: 1) какой алгоритм в корневом сертификате (и в сертификатах промежуточных ЦС, если есть)? 2) какие алгоритмы у сертификатов клиентов? 3) сертификаты клиентов выданы на том же ЦС, что и сертификат сервера? 4) клиенты используют IE7 или IE6 или разные? | ||||
| ||||
1) ГОСТ Р 34.11/34.10-94. 2) ГОСТ Р 34.11/34.10-94 ( для сохранения совместимости/возможности просмотра и проверки подписи старых документов на сайте - везде только ГОСТ94 ). 3) да. ЦС - один (стандартный Microsoft). 4) браузеры разные - IE6 (точно), IE7 (вероятно, у кого-то есть) тут обнаружилось, что еще у порядочного количества клиентов - КриптоПро 1.1/2.0, на 3.0 их еще не перевели (но вроде как на тестовой машине, когда еще сам тестировался, я наблюдал ошибку и при КриптоПро 3.0, хотя сейчас что-то поймать не могу - возникала редко). Еще какой момент забыл упомянуть. Одновременно с переносом сайта на новые сервера (с Windows 2000 на Windows 2003) и переходом c КриптоПро 2.0 на КриптоПро 3.0 - я обновил сертификат ЦС (т.к. старый истекает уже меньше, чем через год). Т.е. у многих клиентов - сертификаты выпущены ЦС, стоявшем под Windows 2000 с КриптоПро 2.0 [в asp пускаю клиентов с сертификатами, подписанными и старым, и новым сертификатом ЦС, проверяя подпись сертификатов программно; впрочем, при ошибке проверять нечего...]. Сертификат в IIS - выпущен в КриптоПро 2.0 (пробовал в 3.0 выпустить, но тогда клиенты со старыми сертификатами - не смогут зайти или должны скачивать новый серт. ЦС, а хотелось переход на новый серт. ЦС сделать плавным - заставлять загружать его только при обновлении личного сертификата клиентом) | ||||
| ||||
УТОЧНЕНИЯ И НАБЛЮДЕНИЯ Клиентов СИЛЬНО беспокоит невозможность отправки больших файлов методом POST по SSL при импорте. (Параметр AspMaxRequestEntryAllowed на Win2003-сервере с самого начала был увеличен до 2048000, таким образом, отправка файлов по HTTP работает - но не по HTTPS) Причем если у клиента Windows 2000 - то все работает и по HTTPS. Но при Windows XP/2003 - POST формы, к которой приаттачен base64-кодированный файл 500-700 Кб, - приводит к зависанию (бесконечному ожиданию) браузера или пустой страничке. И это происходит стабильно, хотя когда на сервере была Windows 2000, то импорт работал нормально (независимо от операционки клиента). Интересно, что если с сервером работает только один человек, то импорт 500-700 кб происходит нормально и при Windows XP/2003 у клиента. Если двое одновременно делают POST с двух машин - то у одного из них уже часто возникает невозможность отправки. При этом POST данных до asp вообще не доходит (вставлял запись в файл лога в самом начале asp). Но минут через 7 в asp приходит обращение клиента к предыдущей (до POST) страничке, с параметрами той траницы и пустым сертификатом (хотя клиент закрыл браузер и больше никуда не лез). Интересно еще, что при наших тестах отправка 500 Кб на сервер из Win2000 - происходит быстро, а та же отправка с WinXP/2003, когда с сервером работает только один человек - происходит удачно в этом случае, но занимает несколько секунд (в обоих случаях имя сервера в браузере вводилось в виде IP-адреса в локальной сети). Вот тестовый пример скрипта aaaaa.asp - если делать POST из двух-трех Windows XP/2003 у клиента на сервер с Windows 2003, то периодически происходит бесконечное ожидание в браузере. [А если сервер под серьезной нагрузкой - вообще отправить не получится. В реальной ситуации данные файла в форму приаттачиваются с помощью ActiveX, конвертируются и кодируются в base64, но для чистоты эксперимента проверял и с вот таким скриптом] <html> <body> <form method="POST" name="docfrm" action="aaaaa.asp"> <input type="hidden" name="n1" value=""> <input type="submit" name="n2" value="Send"> <%=Request.ClientCertificate("Subject")%> </form> <SCRIPT LANGUAGE="JavaScript"> <!-- var s="ceww892jBf"; s=s+s+s+s+s+s+s+s+s+s; s=s+s+s+s+s+s+s+s+s+s; s=s+s+s+s+s+s+s+s+s+s; s=s+s+s+s+s+s+s+s+s+s; s=s+s+s+s+s; document.docfrm.n1.value=s; alert(s.length); // End --> </SCRIPT> </body> </html> | ||||
| ||||
P.S. Было еще наблюдение, что если зайти на aaaaa.asp, успешно послать данные, потом подождать 3 мин., потом еще раз послать - то вероятность бесконечного ожидания в браузере увеличивается. Но ошибки имели место (при нагрузке на сервер - постоянно, клиенты пишут гневные письма...) и без такого ожидания. | ||||
| ||||
P.P.S. Ошибки (бескон. ожидание в браузере) также наблюдал, когда заходил с сервера на сам сервер, т.е. по https://127.0.0.1 - хотя при этом они реже. | ||||
| ||||
up | ||||
| ||||
Запустил приведённый тест (aaaaa.asp) на стенде без ПО от КриптоПро (т.е. все сертификаты - RSA). Только увеличил размер данных до 5 000 000. (т.е. добавил ещё одну строку s=s+s+s+s+s+s+s+s+s+s;) Конфигурация: Сервер - Win2003 SP1 + все хотфиксы, Клиент - XP SP2 + все хотфиксы, IE7. Запукаю на клиенте четыре IE, во всех обращаюсь к aaaaa.asp, после предъявления сертификата клиента во всех IE жму Send с небольшим интервалом. Итог - три IE успешно отправили, один свалился. На сервере ошибки 413 (Объект запроса слишком большой, Request Entity Too Large) Если на клиенте закрыть все IE (а на сервере оставить всё как есть), заново открыть на клиенте только два - глюков гораздо больше. После перезапуска IIS на сервере лучше - два IE работают успешно. Хотя три IE на клиенте тоже выживают с трудом :) - видел, как только один из них отработал успешно, а два упали. | ||||
| ||||
Спасибо, проблема действительно не связана с КриптоПро. Помогло задание параметра IIS6: SSLAlwaysNegoClientCert=1 в Metabase Explorer из IIS 6.0 Resource Kit Tools (завели для W3SVC, после заведения открыть и во второй закладке поставить галочку Inheritable, задать группу Server) Проблема связана с размером буфера UploadReadAheadSize=49152 байт в IIS6: http://groups.google.com/group/microsoft.public.inetserver.iis/browse_thread/thread/fc4c937bbeef5c56/850b4f873fc4c27c?tvc=2&q=UploadReadAheadSize# http://technet2.microsoft.com/WindowsServer/en/library/0ef55842-24d2-4060-bb98-d69e2877a6671033.mspx?mfr=true http://support.microsoft.com/?kbid=889334 P.S. Записи о пустом сертификате клиента при входе в asp в логе еще наблюдаются [реже, 60 в час, было более 250, в Win2000 было 10], но в браузерах клиентов вроде бы никак не проявляются (возможно, возникают, когда клиент уходит с сайта). | ||||
| ||||
Проблема с upload'ом больших файлов по SSL при сервере Windows 2003 решилась (как писал выше). Но проблема со сбросом аутентификации у клиента - наблюдается по крайней мере у одного пользователя (об этой проблеме писал первоначально в данной теме и наблюдал иногда на тестовом Win2003 сервере: перехожу со странички на страничку внутри сайта и вдруг asp "забывает" параметры сертификата, и в ServerVariables и т.п. они пустые). Проявляется только когда и у клиента, и на сервере - КриптоПро 3.0 (у другого пользователя в той же организации КриптоПро 1.1 - там все хорошо, аналогично у нас с тестовым сервером; если пользователь с КриптоПро 3.0 заходит на сервер под Win2000 с КриптоПро 2.0 - то тоже все хорошо). Кстати, с отправкой больших файлов у конкретно этого клиента проблем никогда не было. Характеристика клиента: - КриптоПро 3.0.3293 - как и на сервере (сначала клиент ключи хранил на Flash, потом перегенерил новые, в реестр, не помогло). - Windows XP SP2 с последними обновлениями. - IE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 - На компьютере есть налоговая программа "Диппост" (из-за которой у клиента и была обновлена версия КриптоПро до 3-й; у большинства клиентов пока все-таки 1 и 2 версии). - Клиент использует прокси (пробовали в IE ставить галочку "Использовать HTTP 1.1 через прокси-соединения", это не влияло). [рядом машина с КриптоПро 1.1 с такими же характеристиками - там все хорошо; а данному клиенту пока приходится ходить на сервер под Win2000] Вы рекомендовали "Если есть тестовый environment, то попробуйте поставить Crypto-Pro Winlogon на сервер, без лицензий и настройки". На тестовом ставил, с тех пор ошибку вроде бы не наблюдал (хотя она вообще у меня редко бывала). Можно ли поставить Winlogon на боевые (если что, потом снести). Очевидно, потребуется купить лицензию на Winlogon? (хотя его функционал нам вообще-то не нужен). | ||||
| ||||
В Крипто-Про Winlogon исправлены некоторые ошибки в реализации TLS. Лицензий никаких не требуется, если не использовать фукнционал Winlogon и SmartCard CSP. На боевые сервера ставить можно, но при удалении придется удалить и CSP, затем последний поставить заново. | ||||
| ||||
Hello! Good Site! Thanks you! qhepjbfbtljwup | ||||