はじめに
気がつくと、ブラウザも検索エンジンもHTTPSが普通になってしまって、HTTPだと動きが違ったりします。
弊社では、クラウドネイティブなサービス開発がメインなので、クラウド側は、クラウドベンダーさんに証明書の発行や更新を自動でお任せにできているのですが、ブラウザ側は、開発用にサーバープロセスを立ち上げたり、オンプレミスとクラウドを連携するサービスの場合には、オンプレミスにHTTPSサーバーを設置したかったりします。
オレオレ証明書でも良いのですが、HTTPSとHTTPの関係と同じように、オレオレ証明書だと動きが違ったりするので、本物の証明書が欲しいケースがあります。
ということで、いくつも同じような記事があるかと思いますが、Let's Encrypt します。
ただし、今回は、開発やテスト用途で、本番運用は対象外なので、自動更新は検討しません。
やってみる
キャストのみなさん
Let's Encrypt
Let’s Encrypt はフリーで自動化されたオープンな認証局です。 とトップページに書いてあります。
仕組みについては、以下にドキュメントがあります。
本物の証明書を無料で作ることができます。手続きは自動化されていますので、ルールどおりに行う必要があります。
何によって証明するかですが、最近は、迷惑メール対策などでも同様ですが、DNSを世界中に正しく権限移譲された巨大なデータベースシステムとして扱います。昔は、BindもSendmailもソースコードからコンパイルしてだな…そもそもDNSというのはなぁ…とか言いだすとただの老害になるので、時の流れに身を任せることにします。
Route 53
当社の DNS は、Route 53です。
Route 53は、他のAWSのサービスと同様、APIによる操作が可能なので、これをLet's Encryptが期待しているルールで動かせば良いということになります。
LEGO
当社のクラウド上の開発は、Go言語がメインとなりますので、Let's Encryptの期待通りに、Route 53を操作するのもGo言語で書かれたLEGOで行います。
バイナリーをインストールしている記事が多いですが、Goのソースコードが公開されているので、go install だけで動きます。
go install github.com/go-acme/lego/v4/cmd/lego@latest
証明書を入手する
Route 53
記事にしているぐらいなので大丈夫なんですが、でも、ルートドメインを直接プログラムに編集させるのはチョットと思いますよね。（あれ？思わない？思いましょう）
LEGOは、Route 53のホストゾーンIDを対象とするので、Route 53で、イントラネット用のサブドメインを作成して、サブドメインのホストゾーンIDをLEGOに渡すことにします。どうでもいいですが、イントラネットって最近聞かないような気がします。時代ですかね。
開発サーバーは、開発者のコンピュータのことが多いので、localhostのAレコードを127.0.0.1で作成しておきます。その他、必要に応じて、EC2とかGCEとか独立したテストサーバーのIPアドレスもAレコードで登録します。
おいおい、最近のWindowsのhostsファイルってどうやって編集するんだよ。メモ帳を管理者で実行する？マジか。とか言うことがなくなります。
LEGO
aws/configで権限が切り替えられるように設定している場合は、シークレットキーとか指定をしなくても、AWS_PROFILE変数をセットするだけなので、簡単で安全で確実です。
あとは、上で作ったイントラネット用のサブドメインのホストゾーンIDを指定します。イントラネット用のサブドメインを分割したので、ワイルドカード証明書でも影響範囲が限定できます。
AWS_PROFILE=あなたの \
AWS_HOSTED_ZONE_ID=あなたの \
lego --domains "*.intra.あなたの" --email あなたの --dns route53 --accept-tos=true run
作成した証明書は、90日間で無効になりますが、それも影響範囲が限定されるので安心と考えましょう。証明書は、s3に置くことにしておくと、自動化好きの人が「自動化するぞ！」となったときも融通が利きそうです。
おわりに
昔から開発用やテスト用の証明書をうまく解決する方法がなくて苦労してきましたが、良い時代になったものです。
Discussion