web-dev-qa-db-ja.com

Curl経由でアクセスすると、有効な証明書でSSL証明書エラーが発生する

*.mysite.comを強化するワイルドカードSSL証明書があります。サイトは問題なくすべてのブラウザからアクセスできます。 URLがservice.mysite.comのサービス（別のサーバー上）もあります。奇妙なことに、curlを使用してservice.mysite.comにアクセスすると、次のようになります。

curl: (60) SSL certificate problem: certificate has expired

さらに掘り下げたところ、Ubuntu 18.04サーバーからは確かにservice.mysite.comにアクセスできるが、Ubuntu 14.04からはアクセスできないことがわかりました。これは、おそらく私のCAバンドルが正しくないことを示しています。

だから私はこれをしました：

curl -vv --cacert mysite.ca-bundle.crt https://service.mysite.com

mysite.ca-bundle.crtは、SSLプロバイダーから受け取ったものです。しかし、それでもまったく同じエラーが発生します。何が欠けていますか？

ubuntusslopensslssl-certificate
7
kargirwar

Webサイトの実際のアドレス、SSLプロバイダーの名前、証明書に関するその他の情報を提供しておらず、基本的に考えられるさまざまな原因を推測させてください。

私の推測では、証明書チェーンは最上位のCAとして「AddTrust External Root」で終わり、そのルート証明書 数時間前に有効期限が切れました。

証明書の所有者であるSectigo チェーンがあります チェーンの–古いCA証明書が新しい証明書に相互署名しているため、 "AddTrust External Root"は基本的に上位層でした上記通常、会社の実際のルートCAです。新しいオペレーティングシステムはSectigo/Comodoの証明書を自己署名ルートCAとして認識し、古いオペレーティングシステムはAddTrustルートの下の中間CAとして認識します。

そのため、onlyがAddTrustルートCA証明書によるクロス署名を介してSectigoを認識する古いオペレーティングシステムでは、後者が期限切れになるとすぐに、チェーン全体が無効になります。これを修正するには、それらのシステムがルートとして認識する別のCAに切り替える必要があります（/etc/ssl/certs）。

それらのシステムdoがSectigoをそれ自体ルートCAとして認識している可能性があります。理論的には、証明書が複数のチェーンを通じて検証することは完全に合法です。 CAは同時にルートになることができますand別のCAによって相互署名されます。

しかし 実際には 、多くのTLSクライアントライブラリは代替チェーンの構築が非常に得意ではなく、証明書を検証する方法が常に1つしかないと想定しています。 （Windowsは少し優れており、大きなWebブラウザーには、TLSライブラリーが提供するものに加えて、この追加の複雑さを処理するコードも含まれています。）

たとえば、OpenSSLの古いバージョンはveryであり、どの証明書が信頼できるルートとして機能するかについて厳密でした。サーバーがチェーン「OldCA–NewCA–Intermediate–MyServer」を送信した場合、信頼できる証明書として「OldCA」がある場合、OpenSSL 1.0はonlyを受け入れますが、そうではありません代わりに「NewCA」を使用している場合は、それを受け入れるのに十分賢くなります。

したがって、Ubuntu 14.04がすでにSectigoを認証局として認識している場合は、Webサーバーから送信されている証明書チェーンを修正する必要があります。「発行元：AddTrust」と表示されている証明書を削除すれば十分でしょう。

古い証明書チェーンが次のようになっているとします。

[AddTrust External Root]                               [included in OS]
+-- USERTrust RSA Certification Authority (Sectigo)    sent by your server
    +-- Gandi Standard SSL CA 2                        sent by your server
        +-- git.kernel.org                             sent by your server

サーバーが相互署名されたUSERTrust証明書の送信を停止するように、それを編集する必要があります。

[USERTrust RSA Certification Authority (Sectigo)]      [included in OS]
+-- Gandi Standard SSL CA 2                            sent by your server
    +-- git.kernel.org                                 sent by your server

クライアント側でこれを修正することもできます AddTrustルートCAを削除することによって 。

18
user1686

今日も同じ問題があり、14.04が失敗し、18が問題なく機能しました。今日は、人気のあるルートサポートが古いUbuntuボックスで機能しなくなった日です。幸い、私たちは14を廃止しましたが、それが機能しない場合は、そこにいくつかの指示があります。また、DevOpsチームは、OpenSSLをアップグレードして、ここで説明する変更に対応できるようにするために、かなりの手間がかかる可能性があることにも注意しました。 https://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-202

2
Justin

linuxのミントでcacert.pemまたはトラストチェーンAddTrust External Rootから/usr/lib/ssl/certs/AddTrust_External_Root.pemを削除する必要があります。

不思議に思っている人は、Mozillaからcacert.pemを取得できます。 https://curl.haxx.se/docs/caextract.html 次に、AddTrust External Rootを削除する必要があります。

AddTrust External Rootを削除すると、ソフトウェアが正しいパス証明書を使用するように強制します（複数ある場合）。

たとえば、twinoid.comには3つのパスがあります。そのうちの2つは有効で、最後はAddTrust External Rootを含みます。 https://www.ssllabs.com/ssltest/analyze.html?d=twinoid.com&hideResults=on （そこで3つのパスを確認できます）

もちろん、正しい修正はこれを正しく処理しないソフトウェアからのものでなければなりませんが、この一時的な修正によって私は救われます。ブラウザのような一部のソフトウェアは、この問題を少し前に修正しています。

1
Matoran