Черепаха SVN: Начальный тайм-аут подключения

У меня есть проблема при соединении Черепахи SVN с моим сервером SVN. Первое подключение, кажется, сталкивается с тайм-аутом (SVN слоняется вокруг 20 секунд), и вторые (автоматические) работы попытки немедленно. Т.е. каждое обновление, фиксация, журнал занимает looong время и сводит всех с ума...

То же действие SVN от клиента командной строки Linux работает немедленно. Доступ через веб-браузер работает также без любой задержки.

Установка SVN следующие: сервер SVN выполняет CentOS 7, Apache 2.4.6 и mod_dav_svn 1.7.14. Доступ через SSL настроен. Аутентификация сделана через LDAP на Windows Server 2012 R2. Клиент (Windows 7 x64) выполняет Черепаху 1.7.15 (x64).

Это - соответствующая конфигурация Apache (запутываемый...):

# Reduce LDAP cache to 30 seconds
LDAPCacheTTL 30 
LDAPOpCacheTTL 30

<Location /svn>
  DAV svn
  SVNParentPath /var/svnrepo
  SVNListParentPath on
  AuthName "My Repository"
  AuthType basic
  AuthBasicProvider ldap
  AuthLDAPURL "ldap://dc.mydomain.local/OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local?sAMAccountName?sub?(objectClass=*)" NONE

  AuthLDAPBindDN "CN=ServiceUser,OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local"
  AuthLDAPBindPassword "VERYSECRETPASSWORD"

  # Require ldap group via Microsoft rule "LDAP_MATCHING_RULE_IN_CHAIN"
  Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local
</Location>

Журнал Apache (ssl_error_log) запускается как это когда инициирование действие SVN:

[Wed Aug 26 07:48:14.560025 2015] [ssl:info] [pid 2310] [client 192.168.1.155:49316] AH01964: Connection to child 0 established (server svnserver.mydomain.local:443)
[Wed Aug 26 07:48:14.560563 2015] [ssl:debug] [pid 2310] ssl_engine_kernel.c(1878): [client 192.168.1.155:49316] AH02043: SSL virtual host for servername svnserver.mydomain.local found

Теперь SVN, кажется, зависает (метка времени во вторых 14) - Apache уничтожил бы соединение немного позже, когда модуль reqtimeout включен (я отключил его в этом сценарии). Приблизительно 20 секунд спустя (метка времени во вторых 36), действие продолжается:

[Wed Aug 26 07:48:36.102214 2015] [ssl:debug] [pid 2310] ssl_engine_kernel.c(224): [client 192.168.1.155:49316] AH02034: Subsequent (No.2) HTTPS request received for child 0 (server svnserver.mydomain.local:443)
[Wed Aug 26 07:48:36.102267 2015] [authz_core:debug] [pid 2310] mod_authz_core.c(809): [client 192.168.1.155:49316] AH01626: authorization result of Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=SVN-Group,OU=Group of DomainLocalGroups,OU=MyOU,DC=MyDomain,DC=local: denied (no authenticated user yet)
[Wed Aug 26 07:48:36.102275 2015] [authz_core:debug] [pid 2310] mod_authz_core.c(809): [client 192.168.1.155:49316] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Wed Aug 26 07:48:36.102334 2015] [authnz_ldap:debug] [pid 2310] mod_authnz_ldap.c(501): [client 192.168.1.155:49316] AH01691: auth_ldap authenticate: using URL ldap://dc.mydomain.local/OU=Group of Users,OU=MyOU,DC=MyDomain,DC=local?sAMAccountName?sub?(objectClass=*)
[Wed Aug 26 07:48:36.147960 2015] [ldap:debug] [pid 2310] util_ldap.c(372): AH01278: LDAP: Setting referrals to On.
[Wed Aug 26 07:48:36.154921 2015] [authnz_ldap:debug] [pid 2310] mod_authnz_ldap.c(593): [client 192.168.1.155:49316] AH01697: auth_ldap authenticate: accepting john.doe

ssl_access_log и ssl_request_log запускаются во вторых 36, ничто не зарегистрировано от вторых 14

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

Какие-либо идеи? Что происходит между вторыми 14 и вторыми 36 и как я могу предотвратить его?;-)

Спасибо, Florian

Обновление: Я нашел решение (хотя я не действительно уверен, что причина...): Каждый раз я запускаю Черепаху SVN (или Windows svn клиент командной строки), я заметил действие по брандмауэру: контроллер домена пытался достигнуть нескольких серверов, например, c.root-servers.net, который, кажется, серверы VERISIGN, чтобы проверить сертификат SSL или найти новые корневые сертификаты и т.д. (?). Это было заблокировано брандмауэром, таким образом, DC занял время для прохождения через его списка альтернативных серверов.

Мы используем самоподписанные сертификаты, поэтому моя первая попытка состояла в том, чтобы ввести наш сертификат CA в управление сертификатом Windows через групповую политику. Это работало (по крайней мере, SVN не жаловался на неизвестный CA после удаления всей подлинной информации). Тем не менее, 20 задержек секунды все еще там (и DC все еще пытается достигнуть Verisign).

В конечном счете я попробовал локальный параметр конфигурации SVN "ssl-авторитетные-файлы" для статичной передачи сертификата CA и voilà: задержки не стало!

Т.е. это приводит к задержке 20 секунд:

svn list myrepo

и это нет

svn list --config-option servers:global:ssl-authority-files=C:\temp\mycertificate.crt myrepo

Все еще немного грустно, что для этого обходного решения нужна конфигурация на каждом клиенте, но по крайней мере это - решение...

Я не уверен, что Windows делает при проверке сертификата, возможно, он проверяет на аннулирование или что-то и ожидает тайм-аута (потому что он не может достигнуть Verisign и друзей).Без понятия.