まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:ssl

最近のブログでは独自ドメインを扱うネタが多くなっています(これとか、これとか)。この背景としては旧 Google Apps(現 Google Workspace)の無料版が廃止になって、猶予期間の終了が迫り、これまで取得したドメインの運用を Google Apps に任せていたことに起因して、無料または安価な代替運用先を探していることにありました。ただ(自分的に優先順位の高かった)独自ドメインのメールサーバーについてはある程度対応できたと思っています。

上述のように独自ドメインのメール環境についてはある程度解決しました。次は独自ドメインウェブサイトの問題です。独自ドメインのウェブサイトやウェブサービスを Google Apps を使わずに用意する方法です。まあ、ホスト名だけであれば DNS の CNAME 設定だけでなんとかなるのですが、問題になるのは SSL を使いたいケース(つまり https で始まる URL で独自ドメインのウェブサイトを公開したいケース)です。

これも手間を惜しまないのであれば、Let's Encrypt などで独自ドメインの証明書を無料で取得・更新できます。その証明書を使ってサービスを公開すれば https 対応はできます。ただ、これはこれで(アプリケーション側で証明書を意識するのも)面倒だし、もし証明書の更新を忘れてしまうとサービスが見えなくなってしまったり、証明書を更新した際の再起動なども行う必要があるので、手順としても(コマンドラインで作業するなど)面倒だったりします。独自ドメインのウェブサイトを運用する上でここを(できれば無料、または安価で)どうにかできないだろうか、という課題があります。

そして本ブログエントリはこの部分を
 ・アプリケーションは無料の Heroku で公開して、
 ・無料の Cloudflare で SSL 対応した独自ドメイン名でアクセスできるようにする
という構成を実現するための手順を紹介します。


【アプリケーションを Heroku で公開する】
対象のウェブアプリケーションを Heroku で公開します。アカウントを所有していない場合はサインアップします。

ここでは特別な設定はほぼ不要ですが、1点だけ。Heroku で独自ドメインを使うには、有料版を利用するか、クレジットカードを登録する形で無料枠を使う必要がある点に注意してください。Heroku 自体はクレジットカードを登録せずに無料範囲内で利用することができ、その範囲内でウェブアプリケーションを公開することもできますが、この後独自ドメインを使う場合は無料で使う場合であってもクレジットカードを登録する必要がある、という意味です。

Heroku は GitHub と連携してアプリケーションをデプロイしますが、ここを CLI で手動で行ってもいいし、Git コミットをハンドリングして自動デプロイにしても構いません。いずれかの方法でアプリケーションを Heroku にデプロイしてください。なお後者の方法については過去にこのブログでも紹介したことがあるので、よかったら参考にしてください:
Heroku のパイプラインで GitHub コミット時に自動デプロイする


以下では dotnsf-www.herokuapp.com というホスト名で Heroku 上でアプリケーションが稼働しているものとして説明を続けます。Heroku 上で独自ドメイン向けの設定を行う必要もありますが、 Cloudflare 側での設定をまず先に済ませてから Heroku 上での設定を行います。


【Cloudflare で独自ドメインの設定をする】
次に Cloudflare 側の設定を行います。アカウントを取得していない場合は Cloudflare の無料プランでサインアップし、所有している独自ドメインを登録します。なお以下では独自ドメイン(pi314.jp というドメインを使う例を紹介します)は取得済みで、そのドメインの DNS 管理を Cloudflare にさせる前提で紹介します。

独自ドメインを登録した後、まずは "SSL" のメニューを選択して、「暗号化モード」が「フル」に設定されていることを確認します。もし異なる設定になっている場合は「フル」に変更します。この設定にすることで利用者のブラウザから、Cloudflare を経由して(今回の場合は Heroku 上の)アプリケーション・サーバーまでの全ての経路の通信を暗号化することができるようになります。また独自ドメインの SSL 証明書の更新も自動化されます:
2022040801


そして "DNS" メニューを選択して DNS の設定を行います。今回は上述の dotnsf-www.herokuapp.com というサーバーを www.pi314.jp という名前で公開できるよう設定します。「レコードを追加」と書かれたボタンをクリックします:
2022040802


追加するレコードは以下のようにして「保存」ボタンをクリックします:
 タイプ: CNAME
 名前: www (www.pi314.jp という名前で公開する、という設定です)
 ターゲット: dotnsf-www.herokuapp.com
 プロキシ: ON(プロキシ済み、と表示されます)
2022040803


入力した内容が DNS 画面に表示されるようになります。これで https://www.pi314.jp/ という URL にアクセスがあると、https://dotnsf-www.herokuapp.com/ に(利用者から見えない所で)転送されてページが表示できるようになります。また Cloudflare を使っているので、セキュリティプロキシも有効になっています:
2022040804



【heroku 側のアプリケーションを再設定する】
これでアプリケーションの独自ドメイン利用ができる・・・わけではありません。最後に SSL を使えるように実際には dotnsf-www.herokuapp.com 上で動いているアプリケーションが www.pi314.jp というホスト名でアクセスされる可能性があることを予め認識させておく必要があります。そのためには Heroku の CLI を使って(CLI でログイン後に)以下のコマンドを実行※します:
$ heroku domains:add www.pi314.jp --app dotnsf-www

※このコマンドを実行するには heroku を有料サービスで使うか、または無料利用であってもクレジットカードを登録しておく必要があります。


このコマンドを実行後、しばらく(数分)待ってからウェブブラウザで https://www.pi314.jp/ にアクセスすると、https://dotnsf-www.herokuapp.com/ の画面が https://www.pi314.jp/ というホスト名で表示できることが確認できます。


以上、Heroku も Cloudflare も有償サービスを使わないのであれば、この方法でも無料の範囲内で独自ドメインでウェブアプリケーションを公開することができそうです。



かなり以前に Bluemix(IBM Cloud) の CloudFoundry ランタイム環境でカスタムドメインを運用する手順を紹介したことがありました。今回はその IKS(IBM Kubernetes Services) 版とも言える内容で、特にカスタムドメイン管理を適用する部分については IBM Cloud から提供されるドメイン単位でのオール・イン・ワン・セキュリティーサービスでもある CIS(Cloud Internet Services) を使った場合の手順を確認する機会があったので、その流れを紹介します。

なお、今回紹介する手順を実行するための前提条件として (0) カスタムドメインを所有していること、(1) ベーシックプラン以上の IBM Cloud アカウントを取得していること、(2) IKS(+ Ingress)サービスが利用できること、そして (3) CIS サービスが利用できるという3点が必要です。(0) は今回の作業では当然必要です。また (1) がないと (2) も (3) も利用できないので IBM Cloud アカウントは取得しているとして、このアカウントは無料のライトプランではなく、ベーシックプラン以上でないと (2) も (3) も作成できない点にご注意ください。

また (2) について、IKS は1ヶ月間無料の Free プランもありますが、今回紹介する内容では(Free プランでは使えない) Ingress によるサーバー名管理が必要なため、事実上この (2) は無料では試せない点をご了承ください。シングルゾーンの最弱スペックで1ワーカーノード環境(1時間で約13円)でも構いませんが、IKS を利用するための料金が必要です。なお IKS ではなく上位版の OpenShift 環境でも大丈夫です:
2021062501


(3) の CIS は1アカウントにつき1回だけ、30日間無料プランを申し込むことが可能です。このプランを利用せずにスタンダードプランを利用する場合は、ドメイン1つにつき1ヶ月約30000円です:
2021062502



では以下で具体的な手順を追いながら説明します。

【IKS + Ingress を使ってアプリケーションをデプロイする】
まずは IKS + Ingress 環境で動くウェブアプリケーションを用意します。この時点ではカスタムドメインを意識せずに環境を作ります。

自分で IKS にデプロイしたアプリケーションがあればそれを使っていただいても構いませんが、動作確認用のサンプルとして、以前のブログエントリでも紹介したこのアプリケーションを使う方法も紹介します(アクセスすると、サーバーの /etc/hostname ファイルの内容を表示するだけのアプリケーションです)。ソースコード内に IKS + Ingress 環境を想定したデプロイ用の yaml ファイルが含まれているのでこれを自分の環境向けに編集してデプロイに使うことにします。

まずはソースコードを git clone するかダウンロードしてください:
$ git clone https://github.com/dotnsf/hostname

厳密には今回の作業で最低限必要になるのは yaml/app_deployment_ingresssample.yaml ファイル1つだけなので、ソースコード等に興味なく単に動作確認するだけであれば、このファイルをダウンロードしていただくだけでも構いません:
https://raw.githubusercontent.com/dotnsf/hostname/master/yaml/app_deployment_ingresssample.yaml


次にダウンロードした (yaml/)app_deployment_ingresssample.yaml ファイルを自分の環境向けに編集するのですが、まずは自分の Ingress サブドメインを確認しておく必要があります。IBM Cloud にログインし、利用中の IKS のダッシュボードを開いて Overview メニューから Ingress Subdomain 欄を参照して、その値を確認します:
2021062403


ダウンロードした app_deployment_ingresssample.yaml ファイルをテキストエディタで開き、以下の部分を上で参照した自分の Ingress Subdomain の値に書き換えます。また k8s クラスターを東京( jp-tok )以外のリージョンで作成した場合はサブドメイン情報に続くリージョン情報も自分のリージョンに書き換えてください。最後に保存します:
apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
  - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080


これでデプロイの準備が完了したので、実際に IKS へデプロイします:
$ kubectl apply -f yaml/app_deployment_ingresssample.yaml 

デプロイが成功すると Ingress が有効になり、https://(上述の spec.tls.hosts の値)/ でアプリケーションにアクセスできるようになります:
2021062401


IKS 上にデプロイされたアプリケーションの稼働までができました。この時点では IBM Cloud のドメインによるサーバー名でアクセスされていますが、引き続いて CIS を使い、このアプリケーションをカスタムドメインのサーバー名でアクセスできるようにしていきます。


【CIS にカスタムドメインを登録する】
次の手順は CIS 側の設定です。CIS はドメイン単位で設定を行います。したがってカスタムドメインを使う場合はそのカスタムドメインを登録した上で証明書等を発行する必要があります。

今回は私個人が所有する pi314.jp というドメインを使って説明します。最終的には上述の IKS 上で動く hostname アプリケーションを https://hostname.pi314.jp/ という URL で利用できるように設定していくことにします。以下、"pi314.jp" 部分を皆さんが所有するドメイン名に置き換えて参照してください。

カスタムドメインを CIS に登録する際の最初の手順は利用ドメインの登録ネームサーバーの置き換えです。まず何はともあれ自分のドメインを CIS に管理させるために登録を行います。自分の CIS サービスを開き、Overview メニューから Add domain ボタンをクリックします:
2021062401


画面右にウィザード形式のダイアログが現れるので、指示に従って入力していきます。まずは利用するドメイン(下図では pi314.jp)を入力して Next を選択します:
2021062402


次の DNS レコード登録画面はスキップします。そのまま Next を選択:
2021062403


最後にドメイン管理のためのネームサーバーを変更しろ、という以下のような画面が現れます:
2021062404


DNS で利用するネームサーバーを CIS が管理するネームサーバーに変更する必要があります。この具体的な手順は独自ドメインを取得した業者によって異なりますが、プライマリネームサーバーとセカンダリネームサーバーをそれぞれ以下の内容に変更してください(画面は GoDaddy での DNS 管理画面のものです):
2021062401

 プライマリネームサーバー: ns012.name.cloud.ibm.com
 セカンダリネームサーバー: ns091.name.cloud.ibm.com


変更が完了したら、少し待ってから上図の Next を選択します。変更内容がネット上に反映されるまで少し時間が必要なので、すぐに実行すると「1時間後に再実行しろ」といった内容のエラーになるかもしれません。その場合は少し待ってから再実行してください。

無事に変更内容が確認できた場合は以下のような画面になります。最後に Done を選択:
2021062405


CIS のコンソール画面に移動します。この時点で登録したカスタムドメインが Active になっていることが確認できます。これでドメインの登録とネームサーバーの置き換え作業は完了しました:
2021062406


【CIS に DNS を登録し、エッジとサーバーの接続方法の選択】
ネームサーバーの置き換え後に行う必要があるのは、DNS 設定でカスタムドメインを使ったサーバー名(今回は hostname.pi314.jp)で実際に動いているサーバー(IKS の yaml ファイルで spec.tls.hosts に書かれた値、つまりウェブブラウザで動作確認した時の URL のサーバー名)にアクセスさせるための CNAME の登録と、カスタムドメインのエッジ証明書の作成(確認)、そして CIS のエッジサーバーから IKS のサーバーへどのような方法で接続するかの接続方法の選択です。すべて CIS コンソールから行います。

まずは CNAME を登録します。"Reliability" メニューから "DNS" タブを選択します。画面下部に "DNS records" 欄がありますが、おそらく最初は中身が空のはずです。ここに新しいレコードを作成するため、Add ボタンを選択します:
2021062407


画面右に "Add record" ダイアログが表示されるので、ここで以下のように入力します:
 Type: "CNAME" を選択
 TTL: "Automatic" のまま
 Name: カスタムドメインを使ってアクセスさせるホスト名のドメインを抜いた部分
  (例えば hostname.pi314.jp でアクセスさせたい場合であれば hostname)
 Alias domain name: 現在動いているサーバー名
  (上述のウェブサーバーで動作確認した時に入力した IBM Cloud ドメインのサーバー名)

最後に Add ボタンをクリックします:
2021062408


1つ前の画面に戻り、DNS records が1件追加されていることを確認し、Proxy を ON の状態にしておきます。これで DNS の登録も完了して、hostname.pi314.jp というホスト名で IKS で稼働中のアプリケーションを指し示すようになりました:
2021062409


続けて https 接続のためのエッジ証明書を確認します。CIS コンソールから "Security" メニューを選び、画面下部に Edge certificates 欄を参照します。ここにはカスタムドメインとそのワイルドカード名(今回の例であれば pi314.jp と *.pi314.jp)のエッジ証明書が入力されていればそのままで大丈夫です(2021/06/23 時点の仕様では自動的に作成されているはずです)。もしもここが空になっていたら、右上の Add ボタンを押して、この2つを指定してエッジ証明書を追加してください:
2021062401


最後に CIS のエッジサーバーと、実際のサーバーとの間の通信手段を選択します。同じ "Security" メニューの画面内の TLS mode を確認します(デフォルトは End-to-end CA signed)。ここでセキュリティ要件に合わせて通信方法を選択します。最もセキュリティが高いのは End-to-end CA signed ですが、この場合は別途ドメインのワイルドカード証明書を取得する必要があります。今回は1つ下の End-to-end flexible を選択します(自動発行する自己証明書を使った暗号化通信を行うモードです)。なおこれらの選択肢の違いについて、詳しくはこちらを参照ください:
2021062401


以上で CIS コンソールでの作業も完了です。


【デプロイ設定を変更して IKS にアプリケーションを再デプロイ】

最後にデプロイ設定を変更してアプリケーションを再デプロイします。現在は IBM Cloud ドメイン名でアクセスされる前提でデプロイしていますが、今後はカスタムドメインを使ったアクセスを想定する必要があり、そのための変更を app_deployment_ingressample.yaml ファイルに反映させた上で再デプロイします。

この方法には2つあります。1つは旧サーバー名でのアクセスはできないようにした上でカスタムドメインでの新サーバー名のアクセスを許可する場合、もう1つは旧サーバー名でのアクセスを許可しながら(残しながら)カスタムドメインでの新サーバー名でもアクセスを許可する場合です。両方のケースを順に説明します。

まず旧サーバー名でのアクセスが不要になる場合は前者の(旧サーバー名ではアクセスできないようにする)ケースになります。この場合は app_deployment_ingressample.yaml ファイルの2箇所を以下のように書き換えます:
apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
#   - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    - hostname.pi314.jp
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
# - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
  - host: hostname.pi314.jp
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

"#" で始まる行はコメントなので無くても構いません。要するに spec.tls.hosts と spec.rules.hosts の値を旧サーバー名ではなく新サーバー名に変更する、という作業が必要になります。

もう一方の、旧サーバー名でのアクセスを残しながら新サーバー名でもアクセスできるようにする場合は app_deployment_ingressample.yaml ファイルに新しい Ingress 設定を書き足す形で以下のように書き換えます:
apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
 - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.pi314.jp
  rules:
 - host: hostname.pi314.jp
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

目的に応じた変更をした上で、改めて新しい yaml ファイルを使ってアプリケーションを再デプロイします:
$ kubectl apply -f yaml/app_deployment_ingresssample.yaml

再デプロイ後に新しいホスト名で https アクセスができるようになったことを確認します:
2021062401


以上、CIS + IKS( + Ingress ) の環境でカスタムドメインを使った https アクセスを実現するための設定手順でした。CIS は今回紹介した DNS 関連の機能だけでなく、本来得意とするセキュリティ強化の機能が簡単に使える強みもあるので、IBM Cloud を使って k8s 環境のアプリケーションを安全に使う上での非常に便利なコンパニオンサービスだと感じています。



IBM Cloud から提供されている、Web コンテンツ向けにセキュリティやパフォーマンスといった非機能要件を統合的に設計するサービス、それが CIS(Cloud Internet Services)です。mybluemix.net などの IBM Cloud から提供される標準ドメインではなく、独自ドメインを使うことが前提となりますが、そのドメインで運用するウェブアプリケーションやコンテンツ全般を保護して、安全なインターネット環境を提供することができる便利なサービスです:

https://www.ibm.com/jp-ja/cloud/cloud-internet-services
2019111600


この CIS は(独自ドメインの)DNS を使うことでオリジンサーバーとは別の( Cloudflare 社の)サーバーを経由してオリジンサーバーにアクセスします。この中間サーバーを経由することで必要なセキュリティ要件やコンテンツ保護要件を提供する、というものです。

この CIS を利用して、クライアント(ウェブブラウザ)からの SSL(https) 通信を実現するには大きく3種類の方法があります:

(1)クライアント→中間サーバー→オリジンサーバー 間すべての通信をセキュアに行う方法
(2)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は自己証明書を使った暗号化通信を行う方法
(3)クライアント→中間サーバー 間はセキュアに行い、 中間サーバー→オリジンサーバー 間の通信は HTTP 通信で行う方法
2019110703


①、②、③いずれも共通でクライアントと中間サーバーとの間はセキュアな SSL 通信を行います。中間サーバーとオリジンサーバー間の通信をどう考えるか、という点が異なります。ざっくりいうと①がもっともセキュアで、③がもっともセキュアでない方法となります。

①は理想的といえる方法で、全ての区間がセキュアな通信となります。②も通信自体は SSL で暗号化通信となりますが、その際に利用する証明書はいわゆる「自己証明書」となります。①と比較すると(外部の業者などを使わずに)自分で証明書を作ることができるので、コストや有効期限の自由度などの面でメリットがありますが、「要は誰でも(ドメインのオーナーでなくても)作れる証明書」を使った暗号化通信を行う点が異なります。この証明書を普通に使って直接 SSL 通信を行うと、普通は「セキュアな通信でないが、それでも通信するか?」といった確認メッセージを経て通信可能になったりしますが、中間サーバーとして CIS を入れることにより、クライアントはそういった手順を経ずに通信できるようになります。

そして③の方法ですが、これは中間サーバーとオリジンサーバーとの間の通信は暗号化しない方法です。セキュアかどうか、という観点では暗号化しない経路が存在しているわけで他の2つよりは劣っています。一方で、この方法では証明書の作成を必要としません。クライアントから見た証明書は CIS の中間サーバーが自動で発行されたものが使われ、オリジンサーバーには(そもそも暗号化通信をしないので)証明書が不要です。開発段階や試験段階など、インフラに関わる権限が小さい状況下で、かつ(API の仕様など)https 通信が必須となるような場合においては非常に有要な選択肢となります。またこの方法であれば(そもそも取得しないので)証明書の有効期限切れを心配する必要もありません。 また特にオリジンサーバーとして IBM Cloud の PaaS 環境を利用する場合であれば、オリジンサーバーのルーティングを編集してカスタムドメインでのホスト名でしかオリジンサーバーにアクセスできないように設定することで(HTTPS を使わずにアクセスするような)迂回路を遮断する設定にすることも可能です。

今回はこの③の方法でカスタムドメインの https アクセスを行うための設定を紹介します。

まず IBM Cloud の CIS サービスを利用してプロビジョン済みの状態とし、普通にドメインを登録して設定します。その上で「セキュリティ」カテゴリーの「TLS」内で動作モードを「クライアントからエッジ」に設定します(これが③の通信のための設定となります):
2019110701


なお、このモードの設定内容によって上記図の①~③の通信方法が変わります。以下のような関係です:
2019110704


また DNS の CNAME でオリジンサーバーとの紐付けを行います(下図の「信頼性」-「DNS」)。このカスタムドメインの頭につけるホスト名を指定して、CNAME の参照先となる別名を指定します。IBM Cloud の PaaS (米国南部リージョン)を使う場合は参照先を us-south.cf.cloud.ibm.com を指定します。また「プロキシー」を有効にします:
2019110702


なお、ここで指定する参照先と IBM Cloud PaaS のリージョンとの関係については以下を参照ください:
https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom-domains

最後にオリジンサーバー側を用意します。IBM Cloud PaaS の場合であれば(CNAME で指定した名前).mybluemix.net でアクセスできるようなアプリケーションサーバーを CloudFoundry ランタイムとして作成します(このルーティングは最終的に削除します)。


また IBM Cloud PaaS の場合は「管理」メニューからカスタムドメインを登録する必要があります。この手順の詳細はこちらを参照ください(このリンク先では証明書をインポートする手順まで紹介していますが、今回ここでは SSL の設定を行う必要がないので不要です):
http://dotnsf.blog.jp/archives/1075713365.html


最後に上記で作成した Cloud Foundry ランタイムのルーティングを編集します。経路の編集から「経路の追加」を実行し、mybluemix.net ドメインと同じ名前を指定したカスタムドメイン用の経路を追加します(証明書をインポートしていないので鍵マークには×がついているはずです)。そしてもともとの mybluemix.net 側の経路を削除します。これでカスタムドメインを使った指定でないとアクセスすることはできなくなりました。最後に「保存」します:
2019110705


この状態でカスタムドメインを指定したホスト名で https アクセスを行ってみます。まず最初に CIS がリクエストを受け取ってアクセス内容を(アタックに相当するアクセスでないか)判断します:
2019110706


問題がないと判断されるとオリジンサーバーにルーティングが行われます。結果的に証明書を独自に発行することなくカスタムドメインを使った https 通信ができるようになりました:
2019110707



【参考】
IBM Cloud Certificate Manager で Let's Encrypt 無料 SSL 証明書を取得する



IBM Cloud の PaaS を独自ドメインで、かつ SSL で使ってみました。あまり日本語情報が見つからなかったこともあり、備忘録メモとしてブログエントリにしました。

まず IBM Cloud の PaaS を使うことで、Java や Node.js、PHP などのランタイム(アプリケーション・サーバー)が選択するだけで利用可能になります。利用者はそのランタイムの上で動くアプリケーション(Java なら war ファイルとか、プロジェクトのディレクトリとか)を作って Push(アップロード)するだけでアプリケーションが動きます。 また IBM Cloud の PaaS ではデフォルトで利用可能なドメイン(米国南部データセンターであれば mybluemix.net)があり、このデフォルトドメインを使って稼働させる場合は標準で SSL に対応しているため、特に証明書などを意識することなく SSL 通信可能なアプリケーションを動かすことができます:
2019091307


一方で IBM Cloud の PaaS を(別途取得した)独自ドメインで利用することも可能です(IBM Cloud では「カスタムドメイン」と呼んでいます):
2019091305


カスタムドメインの設定自体は(単純に指定するだけなので)あまり難しくないのですが、カスタムドメインで運用するサーバーを SSL 対応させたことはいままでにありませんでした。今回その機会があり、個人的に躓いた箇所もあったので、一通りの手順を確認してメモ目的で残すことにしました。


【前提条件】
以下の前提条件を元に以降を記載します:
(1)独自ドメインは取得ずみ、DNS設定可能
(2)IBM Cloud はスタンダードアカウント

(1)は今回利用する独自ドメインを既に取得済みであるものとします。今回は僕が個人で取得している teyan.de ドメインを使うことにします。今回の手順の中でこのドメインの DNS 設定を変更する必要があり、その方法は DNS 取得業者によって変わってくるのですが、そのための権限を持っていて、DNS を変更する手順などを理解しているものとします。

また(2)ですが、IBM Cloud は無料のライトアカウントで利用することも可能です。ただ今回のカスタムドメインの利用についてはライトアカウントでは許可されておらず、Pay-As-You-Go などのスタンダートアカウントでの ID を取得している必要があります。


【目的】
IBM Cloud 上で稼働する test20190912.mybluemix.net をカスタムドメイン化して test20190912.teyan.de でアクセスできるようにして、かつ SSL 対応する。つまり https://test20190912.teyan.de/ でアクセスできるようにする
2019091306

↑今回はこれを実現するための手順を以下で紹介しますが、他のホスト名で利用する場合の設定は "test20190912" の部分を適宜読み替えてください。


【ドメインのワイルドカード証明書の準備】
この目的を達成するためには test20190912.teyan.de の証明書が必要になりますが、IBM Cloud の場合はドメインのワイルドカード証明書、つまり *.teyan.de の証明書を用意する必要があります。

試験的な利用であれば(スマホからのアクセスを考慮するとちと面倒ですが)オレオレ証明書でもいいと思いますし、自動更新ができないデメリットを理解した上で Let's Encrypto のワイルドカード証明書を用意してもいいです。もちろん有償でワイルドカード証明書を用意しても構いません。とにかく目的のドメイン(今回は *.teyan.de)のワイルドカード証明書(の公開鍵ファイル、秘密鍵ファイル、中間鍵ファイル)を取得してください。

自分は Let's Encrypto を使いました。Let's Encrypto でのワイルドカード証明書は3ヶ月程度で手動更新する必要がありますが、無料という強力な魅力があります。Let's Encrypto を使ったワイルドカード証明書の取得手順はこちらを参考にさせていただきました:
Let's Encrypt ワイルドカード証明書の取得手順メモ

この手順に従うなどして、目的ドメインのワイルドカード証明書である公開鍵ファイル(cert1.pem)、秘密鍵ファイル(privkey1.pem)、中間鍵ファイル(chain1.pem)を取得したと過程して以下を続けます。


【IBM Cloud にカスタムドメインを追加設定】
次に IBM Cloud 側に自分の独自ドメインを利用するための設定を行います。上述しましたが、この手順は IBM Cloud の(無料の)ライトアカウントでは行うことができません。スタンダードアカウントにアップグレードした上で行う必要がある点にご注意ください。

まず IBM Cloud に(ライトアカウント以外のアカウントで)ログインして、画面上部のメニューから 「管理」 - 「アカウント」 を選択してから、画面左のメニューで 「CloudFoundry の組織」 を選択し、「ドメイン」タブを開きます。そして「ドメインの追加」ボタンを押します:
2019091301


ダイアログが表示されるので、追加する取得済みドメイン(下図では "teyan.de" )を「追加」します。またこの時にアプリケーションをデプロイするデータセンターのロケーション(下図では「米国南部」)を指定します:
2019091302


1つ前の画面に戻り、指定したドメインが一覧に追加されていることを確認します。SSL を使わない場合はこれだけで設定完了ですが、SSL を使う場合は続けて上述の手順で取得した証明書ファイルをアップロードする必要があります。「アップロード」と書かれた箇所をクリックします:
2019091303


SSL 証明書の追加ダイアログが表示されるので、証明書、秘密鍵、中間証明書のファイルをそれぞれ指定し、最後に「追加」します:
2019091304


再度1つ前の画面に戻ります。追加直後は SSL 証明書欄が「保留中」となっているはずで、しばらく(数分)待つ必要があります:
2019091305


処理が反映されると SSL 証明書欄が鍵のかかったアイコンに代わります。これでカスタムドメインの IBM Cloud への追加設定は完了しました:
2019091306


【IBM Cloud にアプリケーションをデプロイ】
クラウド上にアプリケーションを(今回の例では test20190912 という名前で)デプロイします。最終的には test20190912.teyan.de というホスト名でアクセスできるようにしますが、まずは普通に(デフォルトドメインを使って)test20190912.mybluemix.net でアクセスできるものを作成します(今回は標準の HelloWorld アプリ(NodeJS Starter Application)をそのまま使います)。デフォルトドメインはこの時点で SSL 対応しているので、 https://test20190912.mybluemix.net/ でアクセスできます:
2019091307


【カスタムドメイン用のルーティングを追加】
その後、このアプリケーションにカスタムドメインのルーティングを追加します。

アプリケーションの概要ページへ移動し、画面右上の「経路」メニューから「経路の編集」を選択します:
2019091301


ダイアログが表示されます。この時点で test20190912.mybluemix.net だけが表示されていると思いますが、「経路の追加」ボタンをクリックし、下図のように test20190912.teyan.de の経路にも対応するよう追加します。ここまでの手順が正しく実行されていればカスタムドメイン(teyan.de)の経路も証明書がインポートされているので鍵がかかったアイコンになっているはずです。最後に「保存」をクリックします:
2019091302


ここまでの手順を行ってから再度「経路」ボタンをクリックすると、設定した2つの経路が表示されるようになります。これで IBM Cloud 側では test20190912.teyan.de を SSL で表示できるようにするための設定が完了しました:
2019091303


【DNS の CNAME 設定】
後は test20190912.teyan.de へのアクセスがあった場合に、このアプリケーションサーバーにアクセスされるよう DNS 側で CNAME を設定してあげるだけです。が、この最後のステップがかなり戸惑いました。

独自ドメインを購入したサイトへ行き、以下のような設定を追加します:
2019091304


目的のホスト名(この例では test20190912.teyan.de)へのアクセスがあった場合の CNAME 先として、
 (IBM Cloud でのアプリ名、今回は test20190912).us-south.cf.cloud.ibm.com
にルーティングする、という設定をしています。

実は僕自身はここで躓いていました。何も考えずにここは CNAME 先を test20190912.mybluemix.net にするものだと決めつけていたのですが、これだとうまくいきません(https で接続した先で mybluemix.net の証明書が使われてしまうため)。後述のドキュメントを参照すると、ここは mybluemix.net ではなく、us-south.cf.cloud.ibm.com を指定するのが正しいようです。

なおデータセンターが米国南部の場合はこの内容でいいのですが、米国南部以外の場合は us-south 部分を変更する必要があります。詳しくは以下のページを参照してください:
https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-custom-domains


【動作確認】
上記 DNS の設定後、しばらく待って設定が反映されると、https://test20190912.teyan.de/ に(SSL 接続で)アクセスできるようになります。これで目的であった独自ドメインを使った SSL 対応ができました:
2019091306


これで IBM Cloud の PaaS を使って独自ドメインのアプリケーションを SSL 対応で運用することできるようになります。
 

CentOS 7 で運用する独自ドメインのウェブサーバーを Certbot(Let's encrypt) で無料の証明書を取得して SSL 化しました。その手順の備忘録です:
le-logo-standard



【環境】
OS: CentOS 7.6(64bit)
HTTP: Apache HTTPD 2.4.6※

※正確には WordPress 5.2.2(ja) を MariaDB 5.5.60 で運用中。Apache と MariaDB は yum で導入、WordPress は公式サイトから最新版 latest-ja.tar.gz を取得して展開

Document Root: /var/www/html/wordpress
ドメイン名(仮): mydomain.com (DNS 設定済み)

1サーバーで1ドメイン運用、のシンプルなケースを想定しています。http では既に稼働中、という状態だと思ってください。


【準備】

Certbot のインストール
$ sudo yum install -y epel-release
$ sudo yum install -y certbot python-certbot-apache

root で動作確認
$ sudo -i
# certbot --version
certbot 0.36.0

certbot コマンドを実行し、バージョン番号が表示される(=インストールされている)ことを確認します。

【作業】

以下のコマンドを実行するにあたり、証明書を導入するサーバーに HTTP(TCP/80) および HTTPS(TCP/443) でパブリック・アクセスできるようにポート設定できているものとします。またDocument Root に Basic 認証などがかかっている場合は外しておきます(必須)。

証明書作成
# certbot certonly --webroot -w /var/www/html/wordpress -d mydomain.com

-w オプションで DocumentRoot、-d オプションでドメイン名を指定します。E メールアドレスの入力を求められるので自分のメールアドレスを入力して Enter 、そして利用規約に A(Agree) を押して、最後に N(No) を押します:
# certbot certonly --webroot -w /var/www/html/wordpress -d mydomain.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): myname@xxx.co.jp
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

処理が成功すると以下のような "Conguratulations!" というメッセージが表示されます:
2019082900


ここまで完了していると、以下の4ファイルが作成されているはずです(mydomain.com 部分には指定したドメイン名が入ります):
  1. /etc/letsencrypt/live/mydomain.com/cert.pem (サーバー証明書(公開鍵))
  2. /etc/letsencrypt/live/mydomain.com/chain.pem (中間証明書)
  3. /etc/letsencrypt/live/mydomain.com/fullchain.pem (サーバー証明書と中間署名書の結合ファイル 今回は使いません
  4. /etc/letsencrypt/live/mydomain.com/privkey.pem (秘密鍵)

証明書を有効にする

/etc/httpd/conf.d/ssl.conf ファイルの以下3箇所を書き換えて&コメントを外すなどして有効にします:
  • SSLCertificateFile /etc/letsencrypt/live/mydomain.com/cert.pem
  • SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem
  • SSLCertificateChainFile /etc/letsencrypt/live/mydomain.com/chain.pem
  • (fullchain.pem は使わない)

また、Basic 認証をかける場合はこのタイミングで元に戻して(有効にして)おきます。

HTTP サーバーを再起動
# systemctl restart httpd


以上です。僕が以前にウェブサーバーやそのアプリケーションを大量に作る仕事していた頃は無料で証明書作ってもらえるサービスはなくて、いわゆる「オレオレ証明書」に頼っていたのでした。改めていい時代になりました。


このページのトップヘ