64bitに満たないシリアル番号の証明書が発見される！

CAブラウザーフォーラムの要件を満たしていない証明書が見つかったようです

CAブラウザーフォーラムが定める「Baseline Requirements」では、証明書のシリアル番号は64bit以上である必要があると定めています。

が、その要件を満たしていない証明書がかなり出回っているということで海外で話題になっています。

どこの認証局の証明書が対象？

実際にどこの認証局から発行された証明書が対象なのかが気になるところですが、Apple、Google、GoDaddyから発行された証明書が対象とのこと。

※あんまりApple、Googleは認証局という印象はありませんが、自社向けのサービス用とかに証明書発行してるんです。

その数なんと120万を超えるとか。

Appleは878,000枚以上、Googleは100,836枚とのことなのですが、この2社は社内利用の証明書だったようで置き換えが進んでいるので大きな影響はないとのこと。

で、影響が大きいのがGoDaddy。

285,936枚のTLS証明書を発行していたのですが、そのうち12,152枚がまだアクティブな状態。

誤って発行された証明書は5日以内に失効させる必要があると言われているのですが、これがなかなか進んでいないとのこと。

「失効」と一言でも言っても、替わりとなる証明書を再発行しなければなりませんし、サーバへも置き換えが必要なので、かなり大変です。

シマンテック（現デジサート）がGoogle対応で、大量に再発行対応したことが記憶に新しいですが、まぁ、数が数なので仕方ないかと。

その後、GoDaddyは違反した証明書は発行していなかったとアナウンスしています。

証明書を作成するオープンソースのEJBCAソフトウェアパッケージの問題によるもののようです。

デフォルトでは、EJBCAは64bitのシリアル番号の証明書を生成しているはずだったのですが、実際には63bitだったと。

EJBCAはシリアル番号のビットの1つを削ってシリアル番号が正の整数になるようにしてしまう実装がされているため、それが64bitに満たない証明書を発行することにつながっているようです。

よって、64bitのシリアル番号を付与していた証明書はアウトなのですが、72bitで作ったものは64bit以上という要件を満たしていたのでセーフです。

なんでも多少余裕を持っておいたほうが良いという教訓ですね。

証明書を識別するために付与されている番号です。

証明書に限らず製品にはたいていシリアル番号が付与されていて、識別できるようになっていますよね。

証明書のシリアル番号も同じ目的のものです。

昔は証明書のシリアル番号なんて適当だった（単純に連番だったりした）と思うのですが、ハッシュ関数（SHA-1あたり）の脆弱性とかが見つかって証明書偽造リスクが上がったため、シリアル番号もある程度の長さをもたせて、偽造リスクを防ごうという目的で64bit以上というのが定められたようです。

実際問題、64bitが63bitのエントロピー/ランダム性になったところで、セキュリティリスクが上がるわけではないようです。

それにシリアルで偽造リスクを防ごうと考えたのは、ハッシュ関数の信頼性が揺らいでいたからというのもあるわけですが、現在証明書に使われているハッシュ関数（ハッシュアルゴリズム）はSHA256です。

このSHA256の安全性は当分大丈夫なはずなので、シリアルにエントロピーを求める必要性もないようです。

よって、今回のポイントはCA/BFのルールに準拠してない、というところになりそうです。

まぁ、ルール違反をしたらちゃんと対応しなきゃだめですからね。

証明書のシリアルを見れば分かることですが、自分の使っている証明書のシリアルが心配であれば購入元に確認することをおすすめします。

通常シリアルは16進数のランダム値が設定されていると思います。

64bitは16進数だと16文字あればよいわけですが、16文字ぴったりだと今回のEJBCAみたいにちょっと不安。

17文字以上あれば問題ないです。

なお、以下の認証局は該当しないことをアナウンスしていますので、大丈夫です。

以上、「64bitに満たないシリアル番号の証明書が発見される！」でした。

参考にしたサイトはこちら