Hosted-by-discourse は期限切れの SSL 証明書を使用していますが、ステータスページはグリーンです

現在、当サイトの動作に支障が出ています。ここでの投稿はすべて自己ホスト型サイトに関するもののようです。

❯ openssl s_client -connect (removed).com:443 -servername (removed).com
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
---
Certificate chain
 0 s:/CN=(removed).com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

API エンドポイントから期限切れの証明書エラーが返されています。Postman でも確認済みです。

@チーム、こちらをよろしくお願いします。

うーん、なんだか変ですね。

これはご自身のサイト側の問題のようです。
サーバーから提供されている証明書自体は問題なく、ほぼすべてのブラウザで受け入れられています。問題は、比較的最近のルート証明書が、多くの古いサーバーの信頼ストアに含まれていないため、多くの自動化された処理で現在エラーが発生している点です。

あなたの具体的なサイトはわからないため、任意の hosted-by-discourse.com サイトを Qualys SSL Server Test でテストしました。

ご覧の通り、2番目の証明書パスのルートは確かに期限切れですが、これは最初の証明書パスにおいて ISRG Root X1 証明書が信頼ストア(つまり、ブラウザやオペレーティングシステムに含まれている)にあることで回避されています。

サーバーは通常、信頼ストアを頻繁に更新しないため、あなたのサーバーにも ISRG Root X1 証明書が含まれていない可能性が高いです(これは mail-receiver の Docker イメージでも同様に発生しました)。

最新のバンドルは、例えば https://curl.se/ca/cacert.pem から入手できます。CentOS の場合、このファイルを /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem に配置します。Ubuntu の場合は update-ca-certificates コマンドを使用すると、/etc/ssl/certs/ca-certificates.crt が更新されます。

あるいは、サーバーコードで一時的に SSL 証明書の検証を無効にする方法もあります。

OpenSSL の出力を掲載したのは、それが当社のウェブサイトとは無関係であることを証明するためであり、Postman はローカルの Windows マシンで実行されています。

編集:私はさまざまな信頼ストアのレベルについては詳しくありませんが、もう少し調べてみます。これは試すたびにすべてのマシンで発生します。

実際のブラウザを使用している場合は失敗していないはずです。

編集:Postman で問題が発生している人が増えているので、これは有効なテストではないようです…:thinking:

これは当社の DevOps 担当者からの返信です。


問題は、ISRG Root X1 が 2 つ存在することです。そのうちの一つは、はるか以前に DST Root CA X3 によって発行されましたが、もう一つの新しい方は、Let’s Encrypt を含むいくつかの組織を統括する ISRG によって自己署名されています。この自己署名されたルート CA は、現在、ほとんどのシステムで信頼されるルート CA として受け入れられています。

これらは同じ署名証明書ですが、「ISRG Root X1」によって発行されたと主張するあらゆるものを、どちらのバージョンに対しても検証可能です。ただし、DST によって署名された方は、それを署名した DST 証明書が現在期限切れとなっているため、認証パスとして有効ではなくなっています。

サーバーが正しく、自己署名された新しい ISRG Root X1 を提供していれば、クライアントは提供された証明書を自身の信頼ストアと比較し、それが同一の証明書であることを確認して問題ないはずでした。しかし実際には、提供された証明書を受け取ると、「よし、手元にある DST Root CA X3 でこれを検証しよう… あれ、期限切れだ」となり、検証に失敗してしまいます。

信頼されているルート CA ストアに含まれていることが期待される証明書を証明書チェーンに含めることは、「正しい動作」からは程遠いです。

letsencrypt.org 自体の証明書チェーンを見てみましょう:SSL Server Test: letsencrypt.org (Powered by Qualys SSL Labs)

ほら、見て。彼らも同じことをしています。証明書チェーンは(サーバー証明書を除き)同一です。

つまり、あなたの DevOps 担当者が間違っているのか、それとも CDCK、Let’s Encrypt、Qualys が間違っているのかのどちらかです。
ルート CA ストアを更新するよう伝えてください。これで問題が解決します。信じてください。

@bpaterson2000 さん、ホスト型サービスへの接続に問題があるとのこと、お聞きして残念です。@RGJ さんがおっしゃっている通り、これは Discourse 側の問題ではなく、クライアント側で修正する必要があります(当社のサーバーはルート証明書を「供給」するものではなく、クライアント側で管理されています)。

Let’s Encrypt による変更の詳細については、こちらをご覧ください:

情報ありがとうございます。ホストされたサーバーからエラーが返っていたため、これは私たちにとって予期せぬ問題でした。

私たちは Heroku を利用しており、Node.js やパッケージを通じておっしゃる機能がバンドルされています。Node のアップデートが、Discourse の REST API への接続を再び正常に行えるようにする鍵となったようです。

ご支援いただき、ありがとうございます。