X.509 証明書の互換性問題：OpenSSL と Go で検証結果が不一致する理由

1. 問題の概要

2 つの X.509 証明書（ルート CA とリーフ）を用いた検証において、OpenSSL では正常に認証通过了いますが、Go プログラムでは「不明の権限による署名」としてエラーが返されます。

• ca.crt.pem: ローター証明書（自己署名）
  • Issuer: Root CA (subject key identifier:

    0x13

    で始まる)
• leaf.crt.pem: リーフ証明書
  • Issuer: Root CA (UTF8String で定義されている)

Go の検証処理では、以下のエラーが発生します。

panic: x509: certificate signed by unknown authority

2. 根本原因：ASN.1 エンコーディングの違い

一見すると同一の証明書であるかのような

ca.crt.pem

ca.verifies.crt.pem

バイトレベルでの違い

両方のファイルを表示すると、目視では識別できませんが、ハッシュ比較やバイナリダンプを行うと以下の違いが見つかります。

diff <(openssl x509 -in ca.crt.pem -outform der | xxd) \
     <(openssl x509 -in ca.verifies.crt.pem -outform der | xxd)

出力例：

4c4
< 00000030: 1231 1030 ...
---
> 00000030: 1231 1030 ...
8c8
< 00000070: 1307 526f ...
---
> 00000070: 0c07 526f ...

差異の詳細（Subject/Issuer フィールド）

OpenSSL の解析結果

asn1parse

PRINTABLESTRING

技術的な背景

• ASN.1 の仕様では、文字列には

  PRINTABLESTRING

  (0x13)、

  UTF8String

  (0x0c) など複数のタグが存在します。
• Go の検証ロジック は、厳密なバイト列（Raw Subject / Raw Issuer）比較に基づいています。
  • 証明書を

    CertPool

    に登録した際に入力される鍵（キー）は

    cert.RawSubject

    です。
  • リーフが参照しているのは、署名された親の証明書の

    AuthorityKeyId

    です。
• 問題点: 検証に失敗する CA (

  ca.crt.pem

  ) の Subject は

  PRINTABLESTRING

  で定義されていますが、リーフが期待している（あるいは OpenSSL が許容する）親は

  UTF8STRING

  です。Go のロジックにおいて、異なる ASN.1 タグを持つ文字列を「同一のエンティティ」として扱いません。

補足: 通常、同じツールで生成された証明書ペアならこの不一致は起こりません。しかし、リーフ証明書の寿命が短いため、ツールのバージョン進化や互換性のない生成プロセスとの組み合わせで不整合が生じることがあります。

3. Go の検証ロジック詳細

Go の

crypto/x509

検証オプションの構築

opts := x509.VerifyOptions{
    Roots:       roots,      // 登録されたルート証明書プール
    CurrentTime: time.Now(), // 検証時刻
}

チェイン構築と候補検索

Verify()

findPotentialParents()

c

// 簡略化されたロジック
for _, root := range opts.Roots.findPotentialParents(c) {
    considerCandidate(rootCertificate, root)
}

エラー発生箇所

最終的に、Subject と Issuer の一致が判定されます。ここでは、証明書の

CertPool

byName

// CertPool の byName map: RawSubject (バイト列のハッシュまたは比較) => インデックス
var candidateChains [][]*Certificate

for _, c := range s.byName[string(cert.RawIssuer)] { // ⚠️ ここが厳密なバイト比較になっている
    candidate, constraint, err := s.cert(c)
    if err != nil {
        continue
    }
    
    // SubjectKeyIdentifier の一致も確認される
    kidMatch := bytes.Equal(candidate.SubjectKeyId, cert.AuthorityKeyId) 
    
    // ... (ロジック分岐略)
}

発生する問題:

• s.byName[string(cert.RawIssuer)]

  というコードは、Raw Subject（バイト列そのもの）をキーとして使用します。

• ca.crt.pem

  では Issuer 部分の文字列が

  PRINTABLESTRING

  だが、

  leaf.crt.pem

  の参照元や OpenSSL の許容範囲では

  UTF8String

  と等価と見なす必要があります。
• バイト列が完全に一致しないため（0x13 vs 0x0c）、ループ内で一致する親が見つからず、検証エラーが発生します。

4. ディバグと確認方法

Go のプログラムをコンパイルし、ブレークポイントでデバッグして挙動を確認できます。

# GDB を使用したデバッグ例
gdb main -ex 'b crypto/x509.(*Certificate).Verify' -ex 'run'

具体的な調査手順

1. 証明書のバイナリ比較:

   openssl x509 -in ... -outform der | xxd

   で確認。
2. ASN.1 パース:

   openssl asn1parse -in ...

   でタグの違い（0x13 vs 0x0c）を確認。
3. Go の内部変数確認: バイト列のハッシュ値や RawSubject を直接確認する。

5. 結論と対策

この現象は、ASN.1 データタイプの厳密比較が Go の証明書検証ロジックにおけるボトルネックとなっています。OpenSSL など他のツールでは柔軟に「同一内容」を許容しますが、Go はバイトレベルの整合性を要求します。

推奨事項

• 生成ツールの統一: CA サーティフィケートおよびリーフ証明書は、互換性のある設定（UTF8String を優先する等）で同じツール・手順で作成することを強く推奨します。
• 「Fail-Closed」の理解: Go は「失敗して終了する（fail-closed）」振る舞いを採用しています。検証エラーが出ても原因が不明瞭なケースがあるため、システム設計上当該リスクを許容するか、代替策（手動確認や異なるライブラリの使用）を検討する必要があります。
• 未来の注意点: 証明書の有効期限（Not After）に注意してください。本記事中の証明書は 2126 年 に切れますが、現在のシステム時刻とは一致しない可能性があります。検証環境の時刻設定も正しいことを確認しましょう。

# 時刻の確認
date