ワイルドカード証明書が必要になる場面

レン

サブドメインを増やすたびに証明書を取るのが面倒…まとめる方法ってある？

プロクラ

ワイルドカード証明書というものがあるよ。1枚で、そのドメインのすべてのサブドメインに使える。ただし、取得の手間が少し違うんだ。

取得方法が違う

プロクラ

通常の証明書は、そのドメインでWebサーバーが応答できれば取れる。ワイルドカードの場合、DNSにレコードを追加する形での確認が必要になる。

• 指定された値を、DNSのレコードとして追加する
• 更新のたびに、これを繰り返す必要がある
• 自動化するには、DNSを操作できる仕組みが要る
• 利用しているDNSサービスが対応しているかを確認する

プロクラ

3つめが分かれ目だよ。自動化できない環境だと、更新のたびに手作業が発生する。有効期間の短い無料の証明書では、それが毎回になる。

どちらを選ぶか

• サブドメインが数個で固定 → 複数の名前を1枚にまとめる方式で足りる
• サブドメインが頻繁に増える → ワイルドカードが向く
• 利用者ごとにサブドメインを発行する → ワイルドカードがほぼ必須
• DNSの自動操作ができない → 個別に取るほうが楽なことも

プロクラ

1つめの方式は見落とされやすいよ。ワイルドカードでなくても、1枚の証明書に複数の名前を含められる。wwwありなしを両方入れるのと同じ仕組みだね。数が固定なら、これで十分。

漏れたときの影響範囲

ウィルスン

…1枚ですべてのサブドメインに使える、ということはだ。その1枚をワタシが手に入れれば、すべてに使えるということでもあるな。

プロクラ

そこは意識しておくべき点だね。便利さと引き換えに、失ったときの範囲が広くなる。秘密鍵の権限を絞る、置き場所を限定する、といった基本はより重要になる。

• 秘密鍵は本人だけが読める権限にする
• 複数のサーバーに配るなら、その全部が守るべき対象になる
• 漏れた場合、そのドメイン全体の証明書を失効させることになる
• 用途ごとに分けたほうがよい場面もある

レン

数が固定なら、まとめて1枚に入れる方式で足りるんだ。それでいこう。

取得と更新を自動化する

プロクラ

DNSでの確認が必要になるぶん、自動化できるかどうかが実用性を左右する。利用しているDNSサービスに対応した仕組みがあるかを、先に確認しよう。

• DNSサービスのAPIを使って、確認用のレコードを自動で追加する
• そのための認証情報は、必要な権限だけに絞る
• 認証情報の置き場所と権限にも注意する
• 対応していないなら、まとめて1枚に含める方式を検討する

プロクラ

2つめは見落としやすいよ。DNSを操作できる認証情報は、ドメイン全体を操作できることが多い。漏れたときの影響が大きいので、権限を絞れるなら必ず絞ろう。