クロス署名された証明書でエラー再び クロス署名と古いOpenSSL

早朝に一部のメールが滞留してたのでログを見たら。

Let’s Encryptの証明書搭載のサーバなので、9月も終わりついにIdenTrustのX3が失効したか。にしても証明書の更新し損ねてたのだろか… と証明書のファイルの日付見ても9月1日のものです。古いサーバなので5年前のあれと同じだろうと思いつきますが、せっかくなので確認します。その機械から

他の機械から

とか

R3をトラストアンカーにしている機械あり。サーバ側でできることはLet’s Encryptの場合はfullchain.pemおよびchain.pemのしっぽを一つ減らす、となるかと思います。

を引き起こす証明書を切り取る。クライアント側では当時の記録を読み返すとOpenSSLを1.1.0以降のやばくないものにするというのが解決方法になりそうです。

今回問題が起きるのはLet’s Encryptと同時にサポート期限を迎えたFreeBSD 11の1台だけ、内部のメールルーティング用で時間でき次第廃棄にする予定の機械、chain.pemもきっと3ヶ月以内の証明書更新の際に更新されるはず、ということでインバスケットの処理としてはサーバ側ではなくその人だけの対応で済ませるのが良さそうです。portsでsecurity/opensslを導入して、/etc/make.confにDEFAULT_VERSIONS += ssl=openssl を追加。mail/postfixを再インストールして対応完了。baseのOpenSSLとportsのOpenSSLを使ったportsが混在してますが廃棄間近なので気にしません。

2021-10-03追記

IdenTrustのX3の無くなったchain.pemが自動的に使われるようになるのかと思っていたら、2020年12月のExtending Android Device Compatibility for Let’s Encrypt Certificatesによれば

IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3. The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. ISRG and IdenTrust reached out to our auditors and root programs to review this plan and ensure there weren’t any compliance concerns.

ということでもう2年ちょいはDST Root CA X3がついてそうなのでした。AndroidはトラストアンカーのnotAfterを見ないという実装を採用しているからしばらくAndroidが救われるとのことです。

Today, some ACME clients are able to instead request an alternate chain, if their user has configured it. We currently provide the option of getting the chain: Subscriber Certificate < – R3 < – ISRG Root X1 We will continue to offer this same chain as an alternate. However, note that most ACME clients don’t yet have a way to select this alternate chain (for example, Certbot selects chains by looking to see if they contain a given Issuer Name, but this chain doesn’t contain any Issuer Names which the high compatibility chain above doesn’t). We’ll be working with ACME client developers to create more flexible chain selection mechanisms going forward.

今回こちらで問題になっているのはSMTPサーバだけでAndroid関係ないのでDST Root CA X3が無いchain.pemを自動的に使うように設定したいです。しかしCertbotはそれを選択できないとのことなので今度はそちらを見に行きます。

–preferred-chain を指定する際に、chain全部のIssuerを見るのではなく、尻尾のIssuerだけを見るようなPRを作成してくれた方がいて、早々にマージされています。

なるほどcertbot/certbot/crypto_util.py の find_chain_with_issuer() がシンプルになっているCertbotを利用すればよいのですね。利用中のCertbotはUbuntuで動いていてそこから各所に配布するようになっています。Ubuntuなのでportsのようなありがたい仕組みがないので、EFFのインストラクションに従ってちゃんとsnapを利用して動作させるように設定し直します。念のため /snap/certbot/current/lib/python3.8/site-packages/certbot/crypto_util.py の find_chain_with_issuer() がシンプルに尻尾である[-1]だけ見ていることを確認します。

証明書更新スクリプトが/snap/bin/certbotを利用するように変更して

というオプションを追加するか、letsencrypt/renewal/domain.confの[renewalparams]セクションにpreferred_chain = 行を追加、既存の場合は更新します。

これで次の更新からDST Root CA X3のいないchain.pemが使われるはずです。きっと。更新期限が近いドメインは無いようなのでrenewを動かしたら全部スキップされました。後述の手動の変更を加えたドメインだけはエラーも出てました。

これは更新時期過ぎたら元のsymlinkに戻して手動で再度renewすることにします。ランダムに更新してパラメータの調整や配布のスクリプトが流れるようにしているので、snapで追加された自動更新は実行されないようにします。

Production Chain Changesを見ると、ECDSA証明書を発行してもらう場合もchain.pemやfullchain.pemにDST Root CA X3が入ることはなさそうです。

2021-10-02追記

クライアント側は内部のメール処理だけでしたがサーバ側は一部外部からのメールも受けていたので、サーバ側も対応することにしました。インバスケットの優先順位付け失敗です。暫定措置として、live/ の下(certbot仕様)の該当ドメインの chain.pemとfullchain.pemのsymlinkを削除してsymlink先からコピー

して、それぞれのファイルの尻尾にある下と同じ証明書を消します。あとはこちらで利用させてもらってるのがワイルドカード証明書なので各所に自動的に配布されるようにしてあるので少し待って対応完了。次回のサーバ証明書更新までにcertbotで対応する情報などがわんさか出てくるでしょうからあとはそれを使って楽をします(前記のように週末ちょっと調べました)。

ググるとそれなりに影響あったようです。本件同様にクロス署名に対応できないOpenSSLで発生したものも含めて。
なんかY2K問題のお祭り騒ぎを思い出しました。昭和100年で問題起きるシステムがネットにつながってたらやだなと思いますが、2038年はどうでしょう。IoT機器も64bitになっててそんなに影響ないとかでしょうか。

このCA証明書の情報。先のs_connectでも表示されていますが、Sep 30 14:01:15 2021 GMTなので、Sep 30 23:01:15 JSTです。エラーログの時間とも合います。CApathのhash(SHA-1)からpemを探す場合は

なので、2e5ac55d.*を探すと良いです。