svn не примет мой недействительный сертификат

Error validating server certificate for 'https://сервер:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Том
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

Проблема в том, что ваш сертификат не соответствует имени хоста вашего сервера. Вам необходимо, чтобы поле CN в сертификате соответствовало вашему имени хоста. В yuor случае ваше имя хоста - server, а CN вашего сертификата - Tom. Вам необходимо повторно создать сертификат с правильным значением CN.

Следует отметить одно: многие задания cron запускаются с другим HOME (например, / etc / crontab (cron.daily и т. Д.) Устанавливает HOME = /), поэтому у него есть другой файл .subversion. Просто укусил нас здесь, и появилось дерево /.subversion без принятого сертификата. Правильная установка HOME в скрипте cron исправила это.

Вы пытались установить ssl-trust-default-ca к true? Не знаю, решит ли ваша проблема, но я видел эту рекомендацию на Контроль версий с помощью Subversion книга.

Многие установки OpenSSL также имеют заранее определенный набор центров сертификации по умолчанию, которым почти все доверяют. Чтобы клиент Subversion автоматически доверял этим стандартным полномочиям, установите ssl-trust-default-ca переменная для true.

Ответы на этот вопрос помогли мне собрать детали, необходимые для решения похожей проблемы, с которой я столкнулся. Это просто для предварительной сборки деталей для других новичков в Linux, таких как я.

для тестирования скрипта, который вы запускаете через cron, используйте

sudo su

вместо того, что я использовал

sudo -s

в противном случае домашний каталог и другие переменные не будут такими, как при запуске cron (root)

во-вторых, не используйте "--no-auth-cache". Если вы добавите этот переключатель, вы никогда не сможете принять сертификат навсегда.

Используя вышеизложенное, я смог запустить сценарий один раз через sudo su, принять сертификат навсегда, и последующие запуски cron работали.

На ум приходит несколько решений, позволяющих обойти проблему. Во-первых, вы можете создать новый виртуальный хост webdav в Apache, который не использует этот сертификат (простой http). В качестве альтернативы вы можете использовать метод доступа svn + ssh и аутентификацию с закрытым ключом для задания cron (это может быть угрозой безопасности).

Я бы пошел по этому пути, только если вы не можете решить проблемы с сертификатом или не привязаны к https-доступу через webdav.

вы можете просто:

echo t | svn update --username yourusername--password yourpassword --no-auth-cache /local.repository/path 2>/dev/null

Вы можете попробовать проверка сертификата вручную:

$ openssl x509 -noout -fingerprint -in cert.pub
MD5 Fingerprint=0D:89:07:D6:4F:BC:84:2E:2E:14:C2:DA:D4:3B:D5:7C

Поместите это в свой сценарий:

# svn up /BACKUP/checkouts/server/ --username tom –config-dir /xyz/zyx

config-dir может быть любым, где вы хотите хранить информацию о сертификате. Перед запуском из cron запустите его вручную и примите сертификат навсегда, используя «p».

После принятия запустите его через cron, и я считаю, что он будет работать как шарм.

Есть еще один вариант (если предыдущий вариант случайно не работает), который довольно рискован в других средах, но в вашей среде он должен быть нормальным. Используйте сценарий примерно так:

# svn up /BACKUP/checkouts/server/ --username tom --non-interactive –-trust-server-cert

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

Источник: GeekRide