使った独自CAの運用手順ウェブブラウザが新機能をHTTPSでしか有効にしないことが多くなってきたので、開発環境でもHTTPSを使いたい。開発環境用にサーバ証明書を買うのは手間。Constraintsを使った独自CAですよ奥さん。Constraintsに書いたとおり。Constraintsを使うCAの運用手順を説明する。openssl.cnfにCA証明書に設定する属性を指定するセクションを追記[private_ca]subjectKeyIdentifier=hashauthorityKeyIdentifier=keyid:always,issuerbasicConstraints=critical,CA:truenameConstraints=critical,permitted;DNS:.example.com注:nameConstraintsの項がCAが証明書を発行できる対象のドメインを指定。この例では.example.com。demoCA/serial注:ディレクトリ名(demoCA)はopenssl.cnfの設定で変更可能。foo.example.com.crt以上です。難点としては、SafariおよびOSXで動作するChromeではこのルート証明書で署名されたサーバ証明書を正当なものとして認識してくれないところ(手動でサーバ証明書を登録すれば使えるはず)。他のウェブブラウザ+モダンなOSなら問題ないはず。「DNS:example.com」でないと駄目でした。場合はこれ(先頭のドットなし)でサブドメインも含めマッチするように読めます。どちらでも大丈夫でした。AMコメントありがとうございます。おっしゃるとおり、RFCの記述だとdNSNameの場合はドット不要ですね。ドメイン名制限の目的が、「そのドメイン配下に属するホスト名についてのみ証明書発行を許可する」という点にあることを考えると、先行するドットが不要という仕様は合理的かと思いました(メールアドレスの場合と異なるのは混乱を招きそうですが)。含めるべき理由ってありますでしょうか。PMドットなしでサブドメインも含むのが正しい、に同意します。逆にドットありでないと拒否する実装が存在するかもしれないので、両方とも含めておくのが無難かもしれません。的には、ドットなしでサブドメインにもマッチする仕様は合理性を感じませんね、個人的には。完全一致する名前を許可あるいは拒否したい場合も考えられなくはないですし。