まいの雑記帳

商業登記電子証明書(.p12)まわりの覚書

投稿した日
2026/06/04
更新した日
2026/06/04
読了まで
7.21分で読み終われます (4,325文字)

# はじめに

どうも、わたしです。

最近、商業登記電子証明書の証明書ファイル本体(.p12)を扱う機会がありました。かなり苦しんだので、触っていく中で見つけた諸々を備忘録として書き残しておきます。

なお、実物には当然ながら法人のクレデンシャルが含まれているので、商号、代表者氏名、シリアル番号、Subject Key Identifierといった同定可能な値はすべて伏せています。本エントリはあくまで仕様の話です。

# .p12コンテナを開ける

商業登記電子証明書は、登記・供託オンライン申請システムからPKCS#12コンテナとしてダウンロードされます。OpenSSL 3系で開く場合は-legacyが必要です。

openssl pkcs12 -in hogefuga.p12 -info -noout -legacy

MAC=SHA-1、暗号化=3DES-CBC、Iteration=2000という構成で、2026年の基準では古風な部類です。

なお、このPKCS#12の選択は法務省告示第543号の規定ではなく、登記・供託オンライン申請システム側の配布フォーマットの都合です。告示はX.509証明書のフィールド構造とCMP発行プロトコルだけを規定していて、利用者への手渡し方は何も書かれていません。仕様ではなく運用、ということは頭に入れておくとよさそうです。

# 中の証明書

p12を解体すると、秘密鍵1個と証明書2枚(エンドエンティティ+中間CA)が出てきます。ルートCAは入っていないので、検証側で別途取得する必要があります。

エンドエンティティ証明書の基本情報はわりと普通です。

  • X.509 v3
  • 署名: sha256WithRSAEncryption
  • 公開鍵: RSA 2048bit
  • Issuer: C=JP, O=Japanese Government, OU=Ministry of Justice, CN=Registrar of Tokyo Legal Affairs Bureau

問題はSubject DNで、

C=JP
O=MOJ No.XXXXXXXXXXXX
CN=0402010000001

OがJapanese GovernmentではなくMOJ No.{会社法人番号}
CNは基本的に{役員番号}で、ローマ字氏名が登録されている場合のみ{役員番号}-{氏名のローマ字}の形式になります。私が触った範囲ではいずれもハイフンなしの役員番号のみでした。

いずれにせよ、これを普通のクライアント証明書の感覚で扱うと、O属性を法人名だと思い込んでパースしているライブラリが、ニッコリ笑顔で会社法人番号を法人名として表示してくれます。

法人名そのものは、Subject DNではなく証明書の拡張領域に格納されています。私はこれで数時間を溶かしました。

# 本体は1.2.392.100300.1.1.3

商業登記電子証明書のすべてが詰まっているのが、法務省独自OID1.2.392.100300.1.1.3です。中身はこんなASN.1構造になっています。

RegisteredCorporationInfoSyntax ::= SEQUENCE {
    corporateName              [0] DirectoryString,  // 商号
    registeredNumber           [1] PrintableString,  // 会社法人等番号
    corporateAddress           [2] DirectoryString,  // 本店所在地
    representativeDirectorName  [3] DirectoryString,  // 代表者氏名
    representativeDirectorTitle [4] DirectoryString,  // 代表者役職
    registryOffice             [6] DirectoryString   // 登記所
}

商号も本店も代表者氏名も役職も法人番号も登記所も、全部証明書本体に埋め込まれているわけです。登記簿照会を都度叩かなくとも、証明書を検証するだけで法人実体を照会できます。これは商業登記電子証明書独特の特徴なようで、海外の一般的なクライアント証明書とは目的がそもそも違います。

ちなみに、お気づきの方もいらっしゃるかもしれませんが、タグが[0][1][2][3][4][6]と並んでいて、[5]が欠番になっています。告示付録2のASN.1モジュールにも[5]は定義されていません。

何だったんでしょうね、これ。予約とすら書かれていないあたり、運用初期に検討されて消えたフィールドなのかもしれませんが、想像の域を出ません。

ついでに、もう2つの独自拡張も紹介しておきます。

  • 1.2.392.100300.1.1.1: 日本語のUserNotice(「この証明書は、商業登記法その他の関係法令等に基づき発行されたものです。」)
  • 1.2.392.100300.1.1.2: 東京法務局登記官 というUTF8文字列。発行者の役職そのもの

実は標準のcertificatePolicies(2.5.29.32)拡張内にも英語のUserNoticeが入っていて、英文と和文が並存しています。同じ趣旨を文字種を変えて二重格納するというのは、ある意味で律儀ですが、実装側からすると少し迷惑な気もします。

# 発行者の扱い

これは仕様を眺めていて知ったのですが、商業登記電子証明書の発行者は申請者がどこの法務局に申請してもRegistrar of Tokyo Legal Affairs Bureauとなり、東京法務局登記官で固定なようです。

申請者の管轄登記所(例えば長崎地方法務局とか)は、Issuerフィールドではなく独自拡張のregistryOfficeに入ります。

普通のPKIだと「発行者=申請を受け付けた組織」と素朴に対応していることが多いので、気をつけておくといいでしょう。

# 中間CAが並存

ここもハマる方が多そうですが、商業登記認証局(CRCA1)の中間CA証明書は2世代運用されています。

世代

有効期間

秘密鍵使用期間

旧CRCA(2022)

6年

3年

新CRCA(2026)

10年

5年

両世代ともCommon Nameは同じRegistrar of Tokyo Legal Affairs Bureauなので、CNだけでは識別できません。シリアル番号かSubject Key Identifierで判別すべきです。

ちなみに、告示第543号の本文では登記官証明書は「72ヶ月/36ヶ月」、つまり6年/3年と規定されています。私が実際に触ったいくつかの証明書に含まれるCRCAは規定の倍近くに延長されていたので、告示の改正があったか、関係法令で別途上書きされているはずですが、本記事執筆時点では出典を特定できていません。詳しい方、誰か教えてください。

それと、新世代ではkeyUsagecriticalで付くようになっていたり、CRL Distribution Points拡張が追加されていたりと、告示の最低要件を超えた拡張が行われているようです。告示で定められているのは最低限ラインで、運用側のCP/CPSで上乗せされる感じなのかもしれません。

# 失効確認

失効確認はAIA(1.3.6.1.5.5.7.48.1)に書かれているOCSP URLを叩きます。

http://crca.moj.go.jp/bin/dcwcgi/DC_HUSR/cert/cert

新世代CAではCRLのURIも追加されていて、http://crca1.moj.go.jp/certificateRevocationList.crlから取得できます。

ここで地味に面白いのが、商業登記電子証明書には失効だけでなく休止届という独自概念があることです。CRLではエントリのreasonCode(2.5.29.21)にcertificateHold (6)が入り、OCSPではCertStatusrevokedで返り、そのrevokedInfo.revocationReasoncertificateHold (6)が入ります。代表者が交代しそうだとか、本店移転の登記が走るだとか、そのような一時停止のためのものです。商業登記電子証明書ならではの特徴と言えるでしょう。

# さいごに

商業登記電子証明書を一言でまとめると、X.509のガワを被った登記簿の抜粋です。証明書としての構造はRFC 5280に準拠しつつ、肝心の登記情報は法務省独自OIDの拡張領域に格納されていて、PKIライブラリで素直に検証すると半分しか機能を引き出せません。

ところで、平成26年の告示は本体署名をsha1WithRSAEncryptionからsha256WithRSAEncryptionに切り替えるアップデート(※1)だったわけですが、p12コンテナのMACが今もSHA-1なのは正直なんとも言えない味わいがあります。中身だけ新しくしてガワが旧式というのは、行政あるあるな気もしますが、いつかはAES+PBKDF2あたりに刷新してほしい気持ちが若干あります。

それでは。

※1: subjectKeyIdentifierauthorityKeyIdentifierの補助用途では今もSHA-1が使われています

# 参考