Node.js + Express で作るウェブアプリケーションを HTTPS 対応し、更に「HTTPS 以外の通信を認めない」ように設定してみます。なお SSL 対応用のドメイン取得や証明書の取得は完了しているものとし、ドメインは mydomain.com 、秘密鍵ファイルと証明書ファイルがそれぞれ、
　・/etc/letsencrypt/live/mydomain.com/privkey.pem　（秘密鍵）
　・/etc/letsencrypt/live/mydomain.com/cert.pem　（証明書）
に存在しているものと仮定して以下を説明します。


【Node.js + Express で HTTPS 通信】
Node.js + Express で HTTPS 通信を行うには https モジュールを利用します：

var express = require( 'express' );
var app = express();

var fs = require( 'fs' );
var https = require( 'https' );
var options = {
  key: fs.readFileSync( "/etc/letsencrypt/live/mydomain.com/privkey.pem" ),
  cert: fs.readFileSync( "/etc/letsencrypt/live/mydomain.com/cert.pem" )
};
var https_server = https.createServer( options, app );

app.get( '/hello', function( req, res ){
  res.contentType( "text/plain" );
  res.writeHead( 200 );
  res.end( "Hello World." );
});

var https_port = 8443;

https_server.listen( https_port );

console.log( "server starging on " + https_port + ' ...' );

https モジュールを使って 8443 番ポートで待ち受ける https サーバーを作ります。その際に秘密鍵や証明書を指定することで SSL 通信を行うことができるようにしています。

このファイルを Node.js で実行して、ウェブブラウザや curl コマンドで https://mydomain.com:8443/hello にアクセスすることで動作を確認することができます（curl コマンドで localhost など、異なるドメインにアクセスする場合は $ curl https://localhost:8443/hello --insecure といった具合に --insecure オプションを付けて実行することで確認できます）。

また、上記の方法だと https のみアクセスできます（http だと接続エラー）が、http / https 両方でのアクセスに対応するには以下のように改良します：

var express = require( 'express' );
var app = express();
var settings = require( './settings' );

var fs = require( 'fs' );
var http = require( 'http' );
var https = require( 'https' );
var options = {
  key: fs.readFileSync( "/etc/letsencrypt/live/mydomain.com/privkey.pem" ),
  cert: fs.readFileSync( "/etc/letsencrypt/live/mydomain.com/cert.pem" )
};
var https_server = https.createServer( options, app );
var http_server = http.createServer( app );

app.get( '/hello', function( req, res ){
  res.contentType( "text/plain" );
  res.writeHead( 200 );
  res.end( "Hello World." );
});

var http_port = 8080;
var https_port = 8443;

https_server.listen( https_port );
http_server.listen( http_port );

console.log( "server starging on " + http_port + ' / ' + https_port + ' ...' );

これを実行すると、http を 8080 番ポートで、https を 8443 番ポートで同時に待受けてレスポンスを返すことができるようになりました。ウェブブラウザや curl コマンドで http://mydomain.com:8080/hello や https://mydomain.com:8443/hello にアクセスして挙動を確認してください。


【HTTP 通信をしない（HTTPS へ転送）】
最後に、上記プログラムを更に改良して HTTP 通信をしない（強制的に HTTPS 通信に転送する）ための設定を加えます。それには Strict-Transport-Security ヘッダを付けてレスポンスを返すことで実現できます：

var express = require( 'express' );
var app = express();
var settings = require( './settings' );

var fs = require( 'fs' );
var http = require( 'http' );
var https = require( 'https' );
var options = {
  key: fs.readFileSync( "/etc/letsencrypt/live/mydomain.com/privkey.pem" ),
  cert: fs.readFileSync( "/etc/letsencrypt/live/mydomain.com/cert.pem" )
};
var https_server = https.createServer( options, app );
var http_server = http.createServer( app );

//add HSTS
app.use( function( req, res, next ){
  res.setHeader( 'Strict-Transport-Security', 'max-age=15552000' );
  next();
});

app.get( '/hello', function( req, res ){
  res.contentType( "text/plain" );
  res.writeHead( 200 );
  res.end( "Hello World." );
});

var http_port = 8080;
var https_port = 8443;

https_server.listen( https_port );
http_server.listen( http_port );

console.log( "server starging on " + http_port + ' / ' + https_port + ' ...' );

HSTS(HTTP Strict Transport Security) という仕組みを強制することで HTTP でリクエストを受け取っても HTTPS に強制的に変更（リダイレクト）されて通信を続ける、というものです。リダイレクトさせるには HTTP そのものを閉じるわけにはいかない（リダイレクト直前のリクエストを受け取らないといけない）ので、このようなレスポンスヘッダによって実現しています：





【参考】
良い感じにHTTPS対応したexpress(Node.js)サーバを立てる
node.jsによるHTTPSサーバの作り方

タグ ：

nodejs

express

https

Strict-Transport-Security

hsts

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

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



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

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

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



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

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

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

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

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



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



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



なお、ここで指定する参照先と 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 側の経路を削除します。これでカスタムドメインを使った指定でないとアクセスすることはできなくなりました。最後に「保存」します：



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



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




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

タグ ：

ibm

cloud

cis

ssl

https

customdomain

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




【環境】
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 設定済み）

１サーバーで１ドメイン運用、のシンプルなケースを想定しています。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!" というメッセージが表示されます：



ここまで完了していると、以下の４ファイルが作成されているはずです（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 ファイルの以下３箇所を書き換えて＆コメントを外すなどして有効にします：

• 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

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

タグ ：

centos

centos7

letsencrypt

certbot

https

ssl

apache

wordpress