HTTPSなのに「保護されていない通信」と表示される【URLの正規化】

337, 2021-10-27

HTTPSなのに「保護されていない通信」と表示される
GoogleにインデックスされているURLについて
wwwありとwwwなしのURLについて
Let's encryptの証明書について
解決する方法は2通り
wwwありとwwwなしの両方に証明書を発行する方法
wwwありをwwwなしにリダイレクトする
おわりに

HTTPSなのに「保護されていない通信」と表示される

あるWebサービスをリリースしました。
Let's encryptでSSL化してHTTPSもばっちりでした。
Chromeのアドレスバーを見るとちゃんとSSLの証明書が有効になっていました。

それからしばらくして、そのWebサービスをGoogleで検索しました。
そのWebサービスのトップページはちゃんとGoogleにインデックスされているようで、検索結果にはWebサービスのタイトルが表示されていました。
私はそのタイトルをクリックしてWebサービスを開きました。
しかし、Webサービスを開くと見慣れないメッセージがブラウザに表示されました。

Wi-Fi 接続
ご利用の Wi-Fi（XXX-XXX-XXX）では、ログインページへのアクセスが必要な可能性があります。
Chrome の最高レベルのセキュリティで保護するには、保護強化機能を有効にしてください。

なんだこれは？　と思いながらChromeのアドレスバーを見ると、そこには「保護されていない通信」というテキストが・・・。

結論から言うとこれは、WebサービスのURLの正規化にまつわるトラブルでした。
URLの正規化をちゃんとやっておらず、そのため証明書を発行していない「wwwあり」のURLがGoogleにインデックスされてしまったのです。

この記事ではこのトラブルについて詳しく解説し、解決法を見ていきたいと思います。

GoogleにインデックスされているURLについて

そのWebサービスは仮に「mysite.ababa」というドメインだとします。
Let's encryptはmysite.ababaには証明書を発行しています。
またサーバーではNginxを使っていますが、これの設定もmysite.ababaについて行っていました。

しかし、Googleにインデックスされていたのは「www.mysite.ababa」のほうでした。
私としてはてっきりNginxの設定をmysite.ababaについてやっていたので、インデックスされるのもmysite.ababaかと思ったのですが、実際は違いました。
Googleが選んだのはwww.mysite.ababaでした。

ちなみにサイトマップでは「wwwなし」のほうを公開している状態でした。

wwwありとwwwなしのURLについて

Webサービスを公開する際に、最初の方で決めておかないといけないことが1つあります。
それはURLの正規化についてです。

公開したてのWebサービスのURLには、基本的に↓の4種類があります。

httpでwwwありのURL（http://www.mysite.ababa）
httpでwwwなしのURL（http://mysite.ababa）
httpsでwwwありのURL（https://www.mysite.ababa）
httpsでwwwなしのURL（https://mysite.ababa）

デフォルトではこれら4種類のURLのどれにでもアクセスできる状態になります。
（80番と443番ポートを公開している場合）
そのためSEO的にはどれか1つのURLに絞ったほうが良いのですが、これをURLの正規化といいます。
つまりアクセスできるURLを4種類の中からどれか1つにしぼって、そこにアクセスを集中させるわけです。

今回、公開したWebサービスはこのURLの正規化を施していない状態でした。
そのためGoogleが「httpsでwwwありのURL」をインデックスしてしまったのです。

Let's encryptの証明書について

このWebサービスではLet's encryptで証明書を発行済みです。
しかし、発行しているのは「wwwなし」の方のURLについてでした。
つまり「wwwあり」のほうは証明書を発行していません。

ということでGoogleは「httpsでwwwありのURL」をインデックスしているわけですが、こちらのURLは証明書を発行していないので、ブラウザのアドレスバーには「保護されていない通信」と表示されているわけです。

（^ _ ^）

なるほどね～

解決する方法は2通り

今回のトラブルを解決する方法は2通りあります。
それは↓の2つになります。

wwwありのほうにもSSL証明書を発行する
wwwありをwwwなしにリダイレクトする

「wwwありのほうにもSSL証明書を発行する」という方法は、つまり「wwwあり」と「wwwなし」の両方を有効化して、アクセスできるようにするということです。
こちらの解決を行った場合は、ブラウザで「wwwあり」と「wwwなし」の両方にアクセスできるようになります。
また、Googleにインデックスされているページも証明書が発行されるので、問題のアドレスバーの表示は消えます。

後者の「wwwありをwwwなしにリダイレクトする」と言う方法は、つまりURLの正規化になります。
「wwwあり」を「wwwなし」にリダイレクトすることで「wwwあり」のアクセスを「wwwなし」に集中させるわけです。

今回はこれら2通りの解決方法を解説します。

wwwありとwwwなしの両方に証明書を発行する方法

今回のWebサービスではサーバーはUbuntuを使っています。
まず解放ポートを確認します。

$ # ファイアウォールの状態を確認
$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
443                        ALLOW       Anywhere
80                         ALLOW       Anywhere

↑のように443と80がALLOWになっているか確認します。
ALLOWになっていない場合はポートを解放してください。

$ # 有効にする場合
$ sudo ufw allow 443
$ sudo ufw allow 80
$
$ # 無効にする場合
$ sudo ufw delete allow 443
$ sudo ufw delete allow 80

Let's encryptで証明書を発行する場合、2021年時点ではまず↓のように必要ツールをインストールします。

$ # certbotとcertbotのnginxプラグインを入れる
$ sudo apt install certbot python3-certbot-nginx

certbotというのが証明書を発行するコマンドです。
そしてpython3-certbot-nginxはcertbotのNginx用のプラグインになります。
プラグインを使うと簡単にNginxの設定が行えます。

↑のようにツールをインストールしたら、次に↓のコマンドを実行します。
このコマンドは「wwwあり」と「wwwなし」の両方に証明書を発行します。

$ # www有り無しの両方に証明書を発行する。
$ sudo certbot --nginx -d mysite.ababa -d www.mysite.ababa

↑のコマンドを実行すると、httpのリダイレクトの設定などが表示されますので、今回はhttpをhttpsにリダイレクトする方（2）を選択して続行します。

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

コマンドがうまくいくと証明書が発行されます。
また、certbotのNginxプラグインは/etc/nginx/sites-enabled/mysite.ababa.confなどの設定ファイルに自動で設定を書き加えます。
↑のコマンドを実行したあとは設定ファイルの内容が変更されますので注意してください。

Nginxを再起動するとブラウザのアクセスで証明書が有効になっているのがわかります。

wwwありをwwwなしにリダイレクトする

「wwwあり」のURLを「wwwなし」のURLにリダイレクトする設定です。
WebサービスのNginxの設定ファイル、「/etc/nginx/sites-enabled/mysite.ababa.conf」などを開きます。

そして↓のような設定を書き加えます。

# http(80)のwwwありとwwwなしの設定
server {
    listen 80;
    listen [::]:80;
    server_name www.mysite.ababa mysite.ababa; 

    # http://www.mysite.ababaは
    # https://mysite.ababaにリダイレクト
    if ($host = www.mysite.ababa) {
        return 301 https://mysite.ababa$request_uri;
    }

    # http://mysite.ababaは
    # https://mysite.ababaにリダイレクト
    if ($host = mysite.ababa) {
        return 301 https://$host$request_uri;
    }

    # Let's encrypt用の設定
    location ^~/.well-known/acme-challenge/ {
        default_type    "text/plain";
        root            /var/www/html/;
    }
}

# https(443)のwwwありの方をwwwなしの方にリダイレクトする設定
server {
    listen 443 ssl;
    server_name www.mysite.ababa;

    # SSL証明書の指定
    ssl_certificate /etc/letsencrypt/live/mysite.ababa/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mysite.ababa/privkey.pem;

    return 301 https://mysite.ababa$request_uri;
}

# https(443)のwwwなしの本命設定
server {
    listen 443 ssl;
    server_name mysite.ababa;

    # ... (省略)
}

serverを3つ書いています。

1つはHTTP(80)のリダイレクト設定です。
これは「wwwあり」と「wwwなし」の両方を設定します。
アクセスをHTTPSの「wwwなし」の方にリダイレクトしています。

もう1つはHTTPS(443)の「wwwあり」のリダイレクト設定です。
これはHTTPSの「wwwなし」にリダイレクトします。

最後に本命のHTTPSの「wwwなし」の設定を書きます。
これでNginxの設定は完了です。
Nginxを再起動すると、Googleにインデックスされていた「wwwあり」のページが「wwwなし」のページにリダイレクトされます。

おわりに

今回はHTTPSなのに「保護されていない通信」と表示されることについて原因と解決法を解説しました。
今回のトラブルの原因はURLの正規化にまつわるものでした。
この記事がみなさんのトラブルの一助になれば幸いです。

（^ _ ^）

URLを正規化すれば

（・ v ・）

SEOも有利になるよ

HTTPSなのに「保護されていない通信」と表示される【URLの正規化】

目次

関連記事