そのため、コードリポジトリを保持するUbuntuサーバー上で実行されているAtlassian BitBucketの自己ホスト型バージョンがあります。私たちはDigiCertからのSSL証明書を使います。毎年問題を起こしたことのない証明書を更新します。 しかし今回は、証明書が更新された後にGITからコードをプッシュおよびプルするときに、ほとんどの開発者が次のエラーを受け取ります。
fatal：アクセスできません：SSL証明書の問題：ローカル発行者証明書を取得できません
自己署名証明書または内部PKI証明書を使用している場合、オンラインのすべての検索でこのエラーが発生します。 DigiCertのような公的機関によって発行された証明書がなぜこのエラーを受けているのか、私たちは全く困惑しています。この上の任意の助けは大歓迎です。
回答:
公的認証局は、ルートから直接証明書を発行するのではなく、代わりに中間セキュリティー証明書を通して発行します（セキュリティー上および管理上の理由から）。
仲介者がいなければ、あなたの証明書とDigiCertの間にリンクを張ることは不可能です。つまり、あなたのサーバー証明書を検証するためには、単にDigiCertルートを信用するだけでは十分ではありません。
Webブラウザはさまざまな方法でそうすることができます：彼らはあなたのサーバ証明書に保存されたAIA URLから証明書をフェッチすることができます、そして彼らは以前見た中間発行人をキャッシュできます。 現れる ブラウザからアクセスしたときに「正常に」動作すること
しかし、最低限必要なTLSクライアントはそれほど柔軟ではなく（つまり、追加のHTTPリクエストを作成することも、書き込み可能なキャッシュを作成することもできません）、中間証明書を提供する必要があります。 TLSサーバー自体による 。
Webサーバーが単一のPEM（.crt）ファイルを使用する場合、そのファイルには正しい中間証明書が必要です。 添付 それに。
DigiCertが電子メールで証明書を含む.zipをあなたに送った場合、含まれるファイルの1つが中間証明書です。 cat またはテキストエディタ。 （サーバー証明書が常に最初になり、直接発行者が次に続きます。ルートは最後になりますが、ここでは重複しているので含めないでください。）
WebサーバーがPKCS＃12ファイルを望んでいて、そのファイルを次のように作成した場合 openssl exportそれから、それを再エクスポートし、OpenSSLのを使って中間体を指定 -CAfile オプション。 （あるいは、それに結合した.crtを -cert 代わりに）
WebサーバーがJavaキーストアを使用している場合 keytool -importcert うまくいくかも？ （最近のバージョンのJavaサポートでは、キーストアとしてPKCS＃12ファイルを直接使用することを実際に望んでいるので、これは冗長になる可能性があります。正直なところ、わかりません。）
設定を確認してください。 SSLツール または Qualys SSL Labs 。 Webブラウザでサイトを開くだけです ではない 私がすでに述べたことによる良いテストです。