今からお前んちこいよ

多摩川沿いにて細々とお勉強。

SSL(443ポート)のはずなのに "Not secure" とされてしまう理由

参考)Check if a site's connection is secure - Google Chrome Help
ChromeではURLバーに3種類のセキュリティーレベルが表示される。

https://storage.googleapis.com/support-kms-prod/9IKkC4co6mWlM461wyAF94BiF9nMmvcfaqUl Secure
https://storage.googleapis.com/support-kms-prod/rzP3Kj6ct8WH1Ez2S5wV6HCXQVJZg4z0dppd Info or Not secure
https://storage.googleapis.com/support-kms-prod/IFnvUSEwUHO4ppdhra3qLp1qTqnrZduuMwft Not secure or Dangerous

もちろん https通信なのだから Secure にしたいわけだが、いくつかのポイントで Info レベルに落ちてしまっている可能性がある。今回は2つのポイントに触れていく。

ポイント1:TLS1.2 にしましょう

例えばNginxの設定で、

ssl_certificate     /etc/letsencrypt/live/XXXX/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/XXXX/privkey.pem;
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         HIGH:!aNULL:!MD5;

としてしまっている場合は

ssl_certificate     /etc/letsencrypt/live/XXXX/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/XXXX/privkey.pem;
ssl_protocols       TLSv1.2;
ssl_ciphers         HIGH:!aNULL:!MD5;

と、暗号方式を指定してあげる。

ポイント2:内部で http を呼んでませんか?

特定のタグにおいて、 http でのリクエストをしている箇所がある場合のこと(Mixed Content: Mixed content - Web security | MDN)を指します。

httpでリクエストしても良いタグ

・ <img> (src attribute)   
・ <audio> (src attribute)  
・ <video> (src attribute)  
・ <object>   

http でリクエストしてはダメなタグ

・ <script> (src attribute)  
・ <link> (href attribute) (this includes CSS stylesheets)  
・ <iframe> (src attribute)  
・ XMLHttpRequest  
・ CSS内全てのURL  
・ <object> (data attribute)  

例えば、
・ headerで css や js の外部リンクが http となっている場合
・ CSS内で、background-img() が http となっている場合

見つける方法

\ ブラウザのコンソール /
エラーやWarningなどで教えてくれるので便利。

【SSLサーバ構築】docker-compose + Let’s Encrypt + Nginxでの設定

SSL証明書の発行更新はホストOSで行い、docker-composeで起動したNginxコンテナにその証明書をマウントする方針。 Nginxでは、443(https)ポートを解放し、80(http)ポートへのアクセスは443にリダイレクトするように設定する。

参考)SSL with Docker Swarm, Let's Encrypt and Nginx

ステップ1: Let’s Encrypt 証明書の発行

ホストOS上で 

$ docker run --rm -p 443:443 -p 80:80 --name letsencrypt -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly -n -m "メールアドレス" -d ドメイン・サブドメイン --standalone --agree-tos

見やすくすると。

docker run --rm -p 443:443 -p 80:80 
                   --name letsencrypt 
                   -v "/etc/letsencrypt:/etc/letsencrypt" 
                   -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly
                   -n -m "メールアドレス" 
                   -d sampledomain.com 
                   -d www.sampledomain.com 
                   -d sub1.sampledomain.com 
                   --standalone --agree-tos

実行すると、

[XXXX@XXXX ~]$ docker run --rm -p 443:443 -p 80:80 --name letsencrypt -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly -n -m "メールアドレス" -d ドメイン・サブドメイン --standalone --agree-tos
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for ドメイン・サブドメイン
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/ドメイン・サブドメイン/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/ドメイン・サブドメイン/privkey.pem
   Your cert will expire on 2017-12-18. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

キーが以下のようにホストOSに出来上がり、証明書が発行される。
・/etc/letsencrypt/live/ドメイン・サブドメイン/fullchain.pem
・/etc/letsencrypt/live/ドメイン・サブドメイン/privkey.pem

ステップ2: Dockerの設定

docker-compose.yaml

# nginx-image

〜〜〜 略 〜〜〜
        ports:
            - "80:80"
            - "443:443"    <-- 追記
        volumes:
            - "./log:/var/log"
            - "./html/app:/usr/share/nginx/html"
            - "/etc/letsencrypt:/etc/letsencrypt"    <-- 追記

default.conf

server {
    # redirect from http to https
    listen 80;
    server_name  _;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name ドメイン・サブドメイン;
    index index.php index.html;
    error_log  /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;
    root /usr/share/nginx/html/public/;

    ssl_certificate     /etc/letsencrypt/live/ドメイン・サブドメイン/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ドメイン・サブドメイン/privkey.pem;
    ssl_protocols       TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html/;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
    location ~ /\.ht {
        deny all;
    }
}
$ docker-compose up

ブラウザで確認。

・ https でアクセスできれば成功
・ http でのアクセスが https にリダイレクトしていれば成功

ステップ3:証明書更新スクリプトの設置

証明書は90日で期限が切れる。更新(正確には作り直し)するスクリプトをつくり、cronに設定しておく。 期限が迫ってきた場合は更新処理が走り、余裕がある場合はなにもなく処理が終わる。

certbot.sh

#! /bin/bash

docker run --rm --name letsencrypt \  
    -v "/etc/letsencrypt:/etc/letsencrypt" \
    -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
    -v "/usr/share/nginx/html:/usr/share/nginx/html" \
    certbot/certbot:latest \
    renew --quiet

crontabはこんな感じで、毎日 0:19 と 12:19 に更新チェックをする。

19 0,12 * * * /bin/sh ~/certbot.sh >> ~/certbot.log 2>&1

Qiitaに投稿して思ったこと - 記事を書くモチベの話

先日初めてQiitaに記事を投稿したのだが、それに対するリアクション等からここ(ブログ)に記事を書くモチベや意味を再認識した。結論から言うとQiitaに記事は書かない。*1

qiita.com

最近のQiitaに感じること

あまり好印象じゃない。内容重複した記事の多さ。公式ページを見ればわかるチュートリアル。逆に超特定な内容のチュートリアル(好印象に転ずる場合もある)。あとは内容が濃い上長すぎる記事などに対しては本を出せ、買うから。と思ってしまう時がある。必ずしも悪い訳ではないが、散らかってる という印象を持ってる。

Qiita-teamを使っていた時期があるので記事投稿へのハードルが低いのはわかっているつもりだ。そこがいい点なのだが、なんだろうな。もう少し書き手が考えたほうがいいのかな。既存内容を別の人が書いて投稿しているのを見ると、どうして書いたんだろうという思いになる。調べなかったの?差別化はどこ?という疑問を持つ。本当に人に共有したいのか、自分のメモなのか。後者ならば果たしてQiitaに投稿すべきものなのかという思いが巡る。

冒頭にも書いたとおり、Qiitaに投稿してみて思ったのはやはりレスポンスがあるということ。記事にLIKEがつくのはうれしいものだし、記事からURLを辿り私のGithubリポジトリにスターを付けてってくれる方までいて、うれしさがブログよりも遥かに高いのは事実。

ブログ記事を書く目的

Qiitaなどの情報共有する場において、「自分のメモが他の誰かの役に立てば。。。」 などという考えは甘ったれにしか聞こえない*2。それが私がブログに記事を書く理由だと思う。多分「メモを共有する」という言葉に嫌悪感があり、少ない情報にせよ提供する限りは読み手ファーストで本気出せ。という気持ちがある。

一方、ブログは完全に自分のスペースという意識なのでメモでもいいしガチでもいいと思ってる。

私のブログの立ち位置はというと、どんな内容にせよターゲットが自分であれ読者であれ提供する情報/学んだ情報が何かを明確に記すスペース。未来の自分(=一種の読者) ファースト という感じだろうか。

リアルタイム読み手ファーストのブログではないので検索流入の高い話題を狙って取り扱う訳ではない。それも相まって(?)、記事へのリアクションは確かに少ないがそれはモチベにおいても問題ではない。あくまで未来の自分を助けるという目的があり、そのツールとしてブログを使ってるつもり。

おわりに

記事を書く目的は人それぞれだと思うが、共有の場に書くべきなのか自分のスペースに書くべきなのかは各々考えた方がいいと思うし、そうすることで、もっといいネット情報社会になるんじゃないかなっていう雑な意見。

 

*1:何かしらの意図があれば書くぞ?

*2:あくまで主観でものを言っている