AWS IoTの証明書発行、CSRのCNは実は必須じゃない

  • AWS
  • IoT
  • PKI

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

AWS IoTのThingに証明書を発行するときのCSR、CNだけ入れとけば動くのは知ってたけど、それが「AWS IoTの要件」なのか「たまたま慣例でそうしてるだけ」なのか曖昧だったので公式ドキュメントで確認した。

結論

CreateCertificateFromCsr がCSRに対して検証してるのは公開鍵の要件だけ。

  • RSAなら2048bit以上
  • ECCならNIST P-256 / P-384 / P-521のいずれか

Subject内のCN/O/OU/C/ST/Lは一切チェックされない。ドキュメントにもそういう記述はない。

なので最低限のCSRはこれで十分。

ターミナル
openssl req -new -newkey rsa:2048 -nodes -keyout private.key -out request.csr \
  -subj "/CN=my-iot-thing-name"

CNを入れてるのは「後でThingを識別しやすくするための慣例」であって、AWS IoT側が要求してるわけじゃない。極端な話、Subjectを空にしてもCreateCertificateFromCsrは通る（はず、実機未確認）。

SANについても同様で、AWS IoTはドメイン検証をする仕組みじゃないのでSANは見ていない。

なんで気になったか

「CNは必須」と書かれた解説をよく見かけるけど、実際に動いてるものと突き合わせると違和感があったので確認した形。

「動く」と「仕様として要求されている」は別物なので、そこを混同しないようにしたい。

一般論との違い

ここが一番ややこしかったところ。「CSRのCNって必須？」は証明書の種類によって答えが変わる。

RFC 5280的にはSubjectを空にすることも許容されている。ただし条件付きで、SubjectAltName拡張をcriticalとして含めている場合に限る、という規定がある。つまりX.509の標準としては「CN必須」なんて決まってない。

じゃあ何が決めてるかというと、発行するCA（や、そのCAが従う要件）側のポリシー。

flowchart TD
    A[CSR発行] --> B{発行先CAは?}
    B -->|AWS IoT CreateCertificateFromCsr| C[公開鍵の要件だけチェック]
    B -->|公開TLS証明書 Let's Encrypt等| D[CA/Browser Forum要件]
    C --> E[Subject/CN/SANは無検証]
    D --> F[SAN必須 CNは慣例で入れるが実質無視される]

    classDef entry fill:#e8eef7,stroke:#4a6fa5,stroke-width:1px,color:#1a1a1a
    classDef loose fill:#e6f4ea,stroke:#3a8b52,stroke-width:1px,color:#1a1a1a
    classDef strict fill:#fdece9,stroke:#c9503f,stroke-width:1px,color:#1a1a1a

    class A,B entry
    class C,E loose
    class D,F strict

公開Webサーバー向けのTLS証明書だとCA/Browser Forumの要件があって、SANが必須になる。CNも慣例で入れるけど、ブラウザ側はもうSANしか見てないのでCN自体の実効性はほぼない。

一方でAWS IoTみたいなmTLSのクライアント証明書系はそもそもドメイン検証という概念自体がないので、CAが独自に緩いポリシーを取ってても不思議じゃない。今回のケースはまさにそれ。

まとめると

  • AWS IoTのCreateCertificateFromCsrはCSRの公開鍵要件しか見ない
  • CNを入れるのは運用上の慣例であって、AWS IoTの仕様上の必須事項ではない
  • 「CSRにCNが必須かどうか」は証明書の用途とCA/要件次第で変わる話で、AWS IoT固有の緩さを他の証明書全般に当てはめるのは違う