こんにちは、@akase244 です。
Google Chromeさんの常時SSL推奨の動きはいよいよ待ったなしという印象を受けます。 というのも、今年に入ってChromeでフォームが設置してあるSSL未対応ページを開くと「このサイトへの接続は保護されていません」と表示されるようになっていて、非常に不安を煽られるからです。
ということで今回はSSLの話題なんですが、「AWS Certificate Manager」でワイルドカード証明書を発行した際にちょっとつまづいたので、そのときの作業メモです。
SSL証明書のSANフィールドとは
そもそも今回ハマった原因は、私がSubject Alternative Names (以下、SAN）を知らなかったことによる問題なのですが、SANというものをご存知でしょうか？
SSL証明書にはSAN（サブジェクトの別名）というフィールドがあり、ここにCSRに指定したコモンネーム(FQDN)とは別のコモンネームを指定することができます。
これにより、コモンネームとSANフィールドに設定したそれぞれのFQDNでSSL通信が可能となります。マルチドメイン証明書では、このSANフィールドを利用している訳ですね。
SANフィールドについては、SSL証明書の発行を業務で行っている方だとわりと常識なのかもしれませんが、ジオトラストの場合でいうと、例えばコモンネームを www.chirami.io で登録すると、SANとして chirami.io が自動登録されます。
ということは、この形式で発行されたSSLを利用すると、ブラウザで https://www.chirami.io にアクセスしても https://chirami.io でアクセスしてもSSL通信が行われる訳です。
また、コモンネームをサブドメインなしの chirami.io で登録すると、 www.chirami.io は自動登録されません。このあたりが今回のハマりポイントになったわけですが、この話はのちほど。
参考: マルチドメイン（SANs）証明書とワイルドカード証明書
参考: 「Subject Alternative Names（サブジェクトの別名）」とは何ですか
なぜワイルドカード証明証が必要だったのか？
突然ですが、ローカルで作成中のHTMLファイルを外部公開してチェックしたいシーンというのは度々あるかと思います。
例えば、Chromeの開発ツールを使ってのスマホ表示ではなく実機で確認したい場合とか、リモートワークで遠隔地のメンバーにちょっとしたデザイン確認をしてもらいたい場合とか。
そんな時に手助けしてくれるツールがあるといいなと思い、ローカルのHTMLファイルをアップロードすると、24時間限定で外部公開してくれるchiramiというサービスを先日リリースしました。
このchiramiでは以下のようなURLのアクセスパターンが存在します。このようにサブドメインのパターンが複数ある場合はワイルドカード証明書でなければ対応できないため、今回はワイルドカード証明書を取得することにしました。
- パターン1: サービスのURL
- パターン2: wwwなしのサービスのURL (アクセスすると https://www.chirami.io へリダイレクトされる)
- パターン3: ユーザーがHTMLファイルをアップロードした際に発行される一時的なURL
- https://ランダム文字列.chirami.io
無料でSSL証明書を発行したい欲
通常、SSL証明書はお金がかかります。しかし、無料で発行したい気持ちが湧いてきませんか？
なので、今回は「Let’s Encrypt」と「AWS Certificate Manager」を選択肢として調査を行いました。
Let’s Encryptについてはいつか案件で使ってやりたいと思っていたのでいざ調べてみると、FAQページにサブドメイン対応についてそのものズバリな答えが書いてありました。
Will Let’s Encrypt issue wildcard certificates?
We currently have no plans to do so, but it is a possibility in the future. Hopefully wildcards aren’t necessary for the vast majority of our potential subscribers because it should be easy to get and manage certificates for all subdomains.
「直近で対応予定は無いけど、将来的には対応する可能性があるかもね。まぁ、全てのサブドメインの証明書を取得する方が簡単だから、実質ワイルドカード証明書は必要ないよね？」とのこと。
chiramiのサービスの仕様で、ユーザーがアップロードした際に発行されるURLのサブドメインの部分は「ランダム文字列」になるので不定です。
この部分を考慮してLet’s Encryptでランダム文字列のサブドメイン毎に都度SSL証明書を発行するのは現実的ではありません。この時点でLet’s Encryptは選択肢から外れました。
AWS Certificate Managerでワイルドカード証明書を発行する際の注意点
やっと本題です。ここまで長かった。。。
既に説明したとおり、chiramiでは3つのパターンに対応したワイルドカード対応のSSL証明書を発行する必要があります。
AWS Certificate Manageで証明書発行のために「証明書のリクエスト」ボタンをクリックすると、このような画面が表示されます。
私はSANフィールドという存在をしりませんでしたし、「ワイルドカード」証明書を発行するとサブドメインのあり／なしに関わらず、SSL通信してくれるものだと勘違いをしていました。ですので、以下の入力内容で証明書を発行してしまいました。
しかし、「この証明書に別の名前を追加」ボタンの下にある小さな薄い字に目を凝らすとしっかり説明されているじゃありませんか！
つまり、SANフィールドを考慮し、3つのパターンを網羅した正解となる入力はこうなります。
まとめ
いかがだったでしょうか。
これまでSSL証明書をサーバーに設置してApacheやNginxで設定することは普通にやってたんですが、証明書の発行側の経験がなかったので、今回ちょっとした見落としをしてしまったという実例でした。
実は、SANフィールドの件以外にもchiramiのリリースにあたっては色々とトラブル続きだったので、その話については別の機会にでも。
