web-dev-qa-db-ja.com

svnは私の無効な証明書を受け入れません

  • Subversionがフックされた自己署名証明書（サーバー）でApacheを実行しているサーバーがあります
  • リポジトリからチェックアウトまたは更新するには、ユーザー名が必要です。
  • 2つのサーバー（サーバーとクライアント）のcronジョブで更新しようとしているレポからのチェックアウトがあります。どちらのcronジョブも同じ理由で機能しません（両方でほぼ同じ設定を使用していますが、クライアントの方が簡単です）。
  • 以下はクライアント上にあり、ログインは1つだけです：root（私は知っています、私をあざ笑ってください）
  • あなたがそれが重要だと思うなら、彼らは両方ともジェンツーです

エラー

Error validating server certificate for 'https://server: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: Tom
 - 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

   (R)eject, accept (t)emporarily or accept (p)ermanently? 
svn: OPTIONS of 'https://server/svn/repo': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://server)

私はこれをすべて知っています。それが私がすべてのガイドに従ってsvnが自動的に証明書を受け入れるようにする理由です：

/ root/.Subversion/servers

[global]
ssl-authority-files = /root/scripts/server.crt

/ root/scripts/server.crt

-----BEGIN CERTIFICATE-----
MIIDejCCAmICCQDibo0twimetjANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJV
UzERMA8GA1UECBMITmV3IFlvcmsxDDAKBgNVBAcTA05ZQzEjMCEGA1UEChMaSGFw
et al
-----END CERTIFICATE-----

/ root/scripts/backup.sh

svn up /BACKUP/checkouts/server/ --username tom

そして、コマンドはルートとして正常に実行され（Sudoではなく、直接ルートとして）、証明書の確認を求めるプロンプトは表示されません（以前はありましたが、永続的に受け入れるためにpを選択しました）。

私のスクリプトが機能しない理由を誰かが知っていますか？過去数か月間、私は迷惑でした。

**編集：**これに戻るには少し時間がかかり、Davidのアドバイスに従いましたが、それでも機能しません。今のエラーは：

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: server
 - Valid: from Sat, 20 Jun 2009 14:10:45 GMT until Mon, 20 Jun 2011 14:10:45 GMT
 - Issuer: Fake Company, New York, US
 - Fingerprint: 1a:c6:9c:eb:62:9e:e1:05:d9:d3:ac:01:f4:35:dc:00:14:48:e5:39
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://server/svn/folder': Server certificate verification failed: issuer is not trusted (https://server)
linuxpermissionssvnhttpscertificate-authority
7
Tom Ritter
 'https：//のサーバー証明書の検証中にエラーが発生しましたサーバ：443 '：
-証明書は信頼できる機関によって発行されていません。 
フィンガープリントを使用して手動で証明書を検証してください！
-証明書のホスト名が一致しません。
証明書情報：
-ホスト名： トム
-有効：日曜日、2009年2月1日03:51:25 GMTから2011年2月1日火曜日03:51:25 GMT 
-発行者：偽造会社、ニューヨーク、ニューヨーク、米国
-指紋：指紋はここにあります

問題は、証明書がサーバーのホスト名と一致しないことです。ホスト名と一致させるには、証明書のCNフィールドが必要です。通常の場合、ホスト名は「サーバー」で、証明書のCNは「トム」です。正しいCN値で証明書を再生成する必要があります。

5
David Pashley

注意すべき点の1つ-多くのcronジョブは、異なるHOMEで実行されます（たとえば、/ etc/crontab（cron.dailyなど）はHOME = /を設定するため）、異なる.Subversionファイルがあります。ちょうどここに私たちを噛んで、受け入れられた証明書のない/.Subversionツリーがありました。 cronスクリプトでHOMEを正しく設定すると修正されました。

2
afbach

ssl-trust-default-caをtrueに設定しようとしましたか？あなたの問題が解決するかどうかはわかりませんが、この推奨事項は Subversionによるバージョン管理 の本で見ました。

多くのOpenSSLインストールには、ほぼ普遍的に信頼されている事前定義された「デフォルト」CAのセットがあります。 Subversionクライアントがこれらの標準権限を自動的に信頼するようにするには、ssl-trust-default-ca変数をtrueに設定します。

1
Leonel Martins

頭に浮かぶ問題を回避するには、いくつかの解決策があります。まず、この証明書を使用しないApacheで新しいwebdav仮想ホストを作成できます（プレーンhttp）。または、cronジョブにsvn + sshアクセス方法と秘密鍵認証を使用することもできます（セキュリティ上のリスクがある可能性があります）。

証明書の問題を修正できない場合、またはhttps webdavアクセスに関連付けられていない場合にのみ、この方法を使用します。

0
Dana the Sane

あなたは試すかもしれません 証明書を手動で検証する ：

$ 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
0
Inturbidus

これをスクリプトに入れます：

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

config-dirは、証明書情報を保存する任意の場所にすることができます。 cronから実行する前に、手動で実行し、「p」を使用して証明書を永続的に受け入れます。

受け入れられたら、それをcronで実行します。これは、魅力のように機能すると思います。

もう1つのオプションがあります（前のオプションが偶然機能しない場合）。これは、他の環境では一種のリスクを伴いますが、ご使用の環境では問題ありません。次のようなスクリプトを使用します。

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

これは、煩わしさなしに証明書を受け入れるだけです。これはセキュリティリスクの一種であるため、運用環境では推奨されませんが、自分で作成した証明書を使用している場合は、それを使用できます。

ソース： GeekRide

0
Napster_X

この質問への回答は、私が抱えていた同様の問題を解決するために必要な要素を集めるのに役立ちました。これは、私のような他のLinux初心者のためにピースを事前に組み立てるためのものです。

cronを使用して実行するスクリプトをテストするには

スードス

私が使っていたものの代わりに

Sudo -s

そうしないと、ホームディレクトリおよびその他の変数は、cron（root）によって実行されたときのようにはなりません。

次に、「-no-auth-cache」を使用しないでください。そのスイッチを追加すると、証明書を永続的に受け入れることはできません。

上記を使用して、Sudo su経由でスクリプトを1回実行し、証明書を永続的に受け入れ、その後のcronの実行が機能しました。

0
AngelBlaZe