本サイトは移転しました!

GCEの開発環境にSSL証明書を入れようと思ったが

<環境の復習>

サーバサイドの開発をAWS Cloud9で行います。
なるべく無料範囲で、ということで、EC2を使用せず、GCP上のGCEに接続します。
ですので、サーバ側開発環境はGCEに立っています。
クライアント側開発は、クロスプラットフォーム開発を行うためにMonacaを使用しています。
ですので、開発中は、MonacaからGCEに接続して、JSONを取得しよう、と考えています。
本番環境は、さくらレンタルサーバにサーバアプリを構築し、Monacaでビルドしたモバイルアプリから接続します。

ここまで、GCE上でWordPressを動作させており、Monacaでデザインの概要を作成しました。
次は、MonacaからJSON取得をしようとしています。

Let’s Encrypt

さて、MonacaからGCEに接続してJSONを取得しようとしたところ、
The page at ‘https://ide.monaca.mobi/’ was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ‘http://xxx/’. This request has been blocked; the content must be served over HTTPS.
というエラーになりました。
これは、ここまでの調査の中で予期されたエラーなので、では、SSL証明書を導入しましょう、ということになります。

こちら
https://nozomi-hiragi.com/gcd_wp_ssl_support/

を参考に、Let’s Encryptを入れようと思いました。
SSL証明書も無料の時代、すごいなと思います。

ところが。やはり、ところが。

ConfigurationError: Requested name xxx.xxx.xxx.xxx is an IP address. The Let’s Encrypt certificate authority will not issue certificates for a bare IP address.
というエラー。

xxx.xxx.xxx.xxx はGCEで外部公開用に発行してくれているIPアドレス。GCE環境は単なる開発環境と考えているので、ドメイン名など取得していません。IPアドレスでは証明書発行できないんですね。

ということで、このチャレンジはあきらめます。

さくらレンタルサーバの共有SSL

ではどうするかというと、さくらレンタルサーバにテスト環境も立てます。
AWS Cloud9+GCEでサーバ側開発を行い、コミットしたらさくらのテスト環境に連動し、クライアント側の開発・テストは、テスト環境のサーバに接続して行います。テスト完了後、アプリビルド、サーバアプリを本番環境にリリース、というのが理想の流れです。

さくらのレンタルは無料の共有SSLというサービスを提供してくれていますので、できるのではないかと思います。

https://www.sakura.ne.jp/function/common-ssl/

今日は終わり。

独自ドメインの場合は、自前でSSL証明書を取得する必要があります。