OpenSSLがcertsフォルダーでCAを取得しない

curlHTTPSサーバーに接続できない問題が発生しています。

$ curl https://the-problem-site.com    (not the real URL!)   
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

1112はSSL_R_TLSV1_UNRECOGNIZED_NAMEにありssl.hます。

openssl s_client -connect the-problem-site.com:443代わりに試してみると

CONNECTED(00000003)   
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
verify error:num=20:unable to get local issuer certificate   
verify return:0   

Certificate chain   
0 s:/serialNumber=xx/C=xx/ST=xx/L=xxxx/O=xx/OU=xx/CN=the-problem-site.com   
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA   

つまり、問題は信頼できないこと/C=US/O=GeoTrust Inc./CN=GeoTrust Global CAです。ただし、その証明書はインストールされています：/etc/ssl/certs/GeoTrust_Global_CA.pemあり、代わりに実行した場合

openssl s_client -connect the-problem-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

その後、すべてが機能します。証明書はまた、ハッシュという名前のファイルとして存在しb0f3e76e.0、それがでますca-certificates.crt。ただし、私の知る限りでは、curlもopensslも証明書を読み取ろうとしません。もし私がstraceそれらなら、エラーが発生したとしても、/usr/lib/ssl/certsそれを読んだり/etc/ssl/certs、まったく読んだりする試みはありません。ただし、openssl.cnfは読み取ります。走りましたupdate-ca-certificates。

これは、openssl 0.9.8kを備えたUbuntu 10.04です。2つの別々のインストールで問題を再現できます（一方が他方のクローンである可能性もあります）。openssl 0.9.8eを使用してCentOS VMで同じテストを試行すると、正常に機能し、証明書ファイルをで読み取っていることを確認できますstrace。Ubuntu stracesの同じ時点で同等のファイルアクセスはありません。openssl.cnfCentOS VMからUbuntuマシンにファイルをコピーしても、違いはありません。これを引き起こしている可能性のある環境または.rcファイルに明らかなものはありません。

私が間違っていることはありますか？これは機能する必要がありますか？つまり、opensslとcurlはインストールされたCAをコマンドラインから自動的に取得しますか？これはどのように構成されますか？ありがとう！

別のデータポイント：13サーバーのクリーンインストールではcurl、証明書ファイルを取得して正常に動作します。openssl s_clientまだしません。なぜでしょうか？

システムにはいくつかの暗号化ライブラリがあります。

• OpenSSL（ゴールドスタンダード、BSDスタイル（非常に無料）のライセンスを含み、いくらか問題のある条項（GPL互換性を妨げるが、「悪い」ものはない）を含み、GNUでの採用を制限する）
• GnuTLS（FSFからの置き換え。LGPLv2ライセンス（ただしメンテナンスされていない）とLGPLv3ライセンス（したがってGPLv2のみのプログラムとは互換性がない）の2つのフレーバーで提供されます）。セキュリティも強化されます）
• NSS（Netscape / Mozillaのライブラリ、外部ではめったに使用されません。新しい標準の採用には時間がかかります）
• PolarSSL、MatrixSSL、NaCl / Saltなどのマイナーなもの

もちろん、それらすべてに類似点と相違点があります。それらを使用するソフトウェア（暗号化の目的、またはSSL / TLSの使用）は、これらのライブラリの複数の使用をサポートする場合があります（たとえば、WebブラウザーであるLynxは通常OpenSSLにリンクされていますが、GnuTLSもサポートしています（あまり良くありません） GNUの人々をなだめるために）。

cURLは、3つの主要な暗号ライブラリのいずれかを使用することをサポートするプロジェクトの1つでもあります。これは主に、cURLが主に、http、ftpなどの接続を使用して他のプログラムがダウンロード（またはアップロード）したいときに使用するライブラリであるためです。curlコマンドラインツールは、これらの変異体のいずれかから来ることができます。

今、私はあなたが新しくインストールされていないシステムで見ている問題が以下であることをかなり確信しています：

OpenSSLとGnuTLSはどちらも、/etc/ssl/certs/<hash>.<number>-style CAディレクトリの使用をサポートしています。ただし、OpenSSLバージョン0.xおよびGnuTLSは、OpenSSLバージョン1.xが使用するアルゴリズムとは異なるアルゴリズムを使用して、前述のハッシュを計算します。（どちらもシステム上で共存できます。異なる証明書が同じハッシュを持っている場合は、それらに異なる番号を使用するだけです。しかし、何らかの理由で、Debian / Ubuntuのca-certificatesパッケージはこれを行わないようです。）さらに、GnuTLSの一部のバージョンはディレクトリの使用をサポートしますが、ファイルの使用のみをサポートします/etc/ssl/certs/ca-certificates.crt（これも通常はca-certificatesパッケージのメンテナスクリプトによって管理されますが、逸脱する可能性があります）。あなたは古いバージョンを使用しているようですので、これはあなたが打つものかもしれません。

openssl s_clientデフォルトでは（つまり、-CApathまたは-CAfileオプションなしで）は証明書をどこも検索しません。

あなたのcurlアップグレードインストールから最も可能性が高いとは異なる暗号ライブラリ使用してcurl新規インストールからを。

openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443加えてopenssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443、古いGnuTLSバージョンの動作を模倣するようにしてください。

OpenSSL 1.xがシステムのどこかにあるかどうかを再確認し（UbuntuはLTSバージョンにまでメジャーアップデートを忍び込ませることで知られています）、ある場合はファイルのハッシュを確認します。

openssl x509 -noout -hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash_old -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem

通常、2番目と3番目のコマンドは失敗するか（OpenSSL 0.x）、1番目と3番目のコマンドは同じハッシュを表示しますが、2番目のコマンドは異なるハッシュを表示します（OpenSSL 1.x）。GnuTLSは2番目のコマンドからの出力を使用します（OpenSSL 1.xがインストールされている場合）。OpenSSL 0.xがインストールされている場合、それは同じハッシュです。このようなシンボリックリンクは手動で作成できます。

デバッグのフィードバックを提供したら、この投稿を更新できます。