ドメイン認証でよいのであれば、https で通信する時は、AWS Certificate Managerで証明書を取得し、CloudFront で選択すれば良いが、いろんな条件でそれが出来ないことがあるため、そのときの対処方法と問題点です。
AWS Certificate Manager で、CNAME を利用した、DNS検証を使う
特に制限が無く、自身でRoute53やお名前.comなどのアカウントがある場合は、この方法で証明書を取得すればよい。
ただしこれの問題点は、文字の先頭に _ を使えないサービスでドメインを取得している場合は、利用できない。
AWS Certificate Manager で、Eメール検証を使う
WHOIS クエリで返された連絡先情報を使用するそのドメインの登録者、技術担当者、管理者の連絡先、ドメイン名の前に admin@、administrator@、hostmaster@、webmaster@、および postmaster@ のEメールが受信できるのであれば、検証できる。
受信を確認する担当者が別にいるような場合で、認証を行うまで3日以上かかる場合は、タイムアウトになってしまい、再度検証メールを送る必要がある。
そもそもメールが受信できない場合は利用出来ない。
AWS Certificate Manager で取得したリージョンを us-east-1 以外で取得してしまった場合
何らかの理由で、us-east-1 で取得し直すことが不可能な場合は、取得した証明書を Elastic Load Balancing に割り当てるしかない。
Elastic Load Balancing の後ろに EC2 を用いれば、あとはどうにか出来る。
ただしサーバー費が無駄に必要になる。
認証するドメインをNSレコードで登録
Route53で Hosted Zone を作成し、NSレコードとして別DNSサービス側に登録する。
これが出来れば、ドメインを所持している時と同じように設定できる。
サブドメイン単位でも登録出来るため、かなり自由がきく。
Let's Encrypt を用いて、証明書を取得する。
現在利用されているデバイスで、証明書が無効で通信できないようなことは起こっていないので、Let's Encryptは実用的に使えます。
これの利点は、利用するドメインの設定が終わっていて、特定のパスにファイルを置き、httpでアクセスできる状態なら、検証が出来るところ。
90日間で証明書の期限が切れてしまう。
# mac では実行できない。 $ git clone https://github.com/letsencrypt/letsencrypt.git $ cd letsencrypt $ ./certbot-auto certonly -m ＜EMAIL＞ -d ＜DOMAIN＞
途中で、指定のURL、ファイルの内容で、ファイルをアップロードするように指示があるので、その通りにファイルを置く。
続けると、証明書が生成される。必要なのは、cert.pem (証明書), privkey.pem (プライベートキー), chain.pem (中間証明書)。
これで何かがおきた時、乗り切れるはず。
