「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

hanako

English⇒Japanese

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

ホーム新着翻訳記事一覧 > 新着翻訳記事

新着翻訳記事

GitLab PagesでのTLS設定方法と、Let's Encryptについて | from: about gitlab.com / ゲスト著述家・André Miranda

  GitLab Pagesで作られたサイトを、 Let's EncryptでHTTPS化する方法をお教えします。

 

  どうしてTLS/SSLが必要か

  HTTPSについて話し合ったときなどに、よく「静的サイトにはHTTPSなんていらない」という話をする人がいます。
 理由として、POSTリクエストがないことや、クレジットカードを使った取引がないことから、「安全を確保すべき要素が見当たらない」ことを挙げることが多いようです。

 しかし、それはHTTPSの役割をあまりにも理解していないからこそ言えることでしょう。

  TLS(もとSSL)とは、HTTPサイトに安全対策を施すために設計されたセキュリティプロトコルです。

 これを使うことでサイトがどのような点で強くなるかというと、

  1. サイト運営者の信用証明になる。サイト利用者に運営者の情報などをわざわざ明かさなくても、怪しいものではないという印象を与えられる。また、サイトに接続時にTLSハンドシェイクが使われるので、利用者がなりすましサイトに転送されることを予防する。
  2. データの保全性:サイトのリクエスト/レスポンスに関わるデータを改ざんされづらくなる。
  3. 暗号化:TLSを使う醍醐味。クライアントとサーバーが通信する際のプライバシーを保護できる。(この点について、サイト運営者は直接の恩恵を受けない)


 TLSレイヤーは、FTP(FTPSから作成)やWebSocket( ws:// wss://から作成)などのプロトコルと同様に追加できます。

 

  HTTPSはみんなのもの

  近ごろでは、どのウェブサイトでもTLSを使うことが強く勧められております。

 我々は、ウェブの世界が安全なものになることを最大の目標として活動しているのですが、

 それには次の3要素が欠かせません。
 

  まずは、HTTPSのサイトに優先的に接続できるようにすることです。
 1つにはブラウザの機能として、もう1つは検索エンジンによる対応によって実現が進みつつあります。
 たとえば、Googleは2014年から、HTTPS化されたサイトを優先して検索上位に表示しています。
 

  TLS証明書

  最後の要素は、TLS証明書です。
 TLSをHTTPに追加するためには、認証局から証明書をもらわなくてはなりません。
 2015年まで、証明書をもらう前には、TLSが適用される範囲を利用者みずからが算出する必要があった上に、まず認証局から「購入」しなくては手に入らないものでした。

  2015年12月に、Let's Encryptが無料で、しかも適用範囲も自動測定してくれる認証局を開きました。
 これ以降、証明書はターミナルから手軽に受け取れるようになったのです。

 

  実装方法

  それでは、HTTPS証明書を具体的にどうやってブログに添加するかを紹介します。

 ここでは、 Jekyll 3で制作した静的ブログを例にとって、説明していきますが、
 他の静的サイト・ジェネレータを使っていたりする場合でも、だいたい似たような手順を踏みますので、
 「ああ、ここは自分のジェネレータでいうとこのあれかな?」などといろいろ置き換えて考えてみてください。
 GitLab にはたくさんのexampleプロジェクト が置かれているので、参考になると思います。

 

  今回はこんなふうにブログを作りました。

======================
$ jekyll new cool-blog
 New jekyll site installed in ~/cool-blog.
$ cd cool-blog/
======================

 このようにして、何らかの方法でGitLabプロジェクトを立ち上げていることを、今回の解説の前提条件といたします。

 このようにして、まずは「ユーザーページ」を作りました。
 「ユーザーページ」とは、ユーザーアカウント(ただしグループアカウントは除外)で作成されたプロジェクトのことで「ユーザー名(半角英数).gitlab.io」というアドレスがついています。
 GitLabプロジェクトの基本的な立ち上げ方法は、GitLab Pagesのマニュアルに詳しく書いてありますので、そちらを参考にしてください。
 

  さて話を戻しますが、デフォルトのドメイン「ユーザー名.gitlab.io」を、
 「新ドメイン(半角英数).org」という独自ドメインに変更することになりました。

  実のところ、サイトのドメインが変更されたとしても、GitLab側としてはサイト・プロジェクトを作成したときのドメインで識別しています。
 なので、コードをアップロードする宛先は、デフォルトのドメインにしたほうがようでしょう。

 アップロードの方法です

======================
$ git remote add origin git@gitlab.com:YOURUSERNAME/YOURUSERNAME.gitlab.io.git
$ git push -u origin master
======================

 ひとまずプロジェクトのアップロード自体は、これでできたはずです。

 しかし、GitLab Pagesのセットアップがまだでした。

 これからセットアップの説明をしていきますが、その前に、まずは「デフォルトの設定」で、サイトがどのようにビルドされていくかを大まかに見ていきましょう。

 レポジトリのrootディレクトリから.gitlab-ci.yml ファイルを開きましょう。

 Jekyll3で作ったページなら、おおよそこうなっています。

======================
 pages:
  stage: deploy
  image: ruby:2.3
  script:
   - gem install jekyll
   - jekyll build -d public/
  artifacts:
   paths:
    - public
  only:
   - master
======================

 このファイルは「deploy」の時にGitLabランナーが使うもので、Jekyllをインストールしてから、ウェブサイトをpublic/フォルダにビルドする(jekyll build -d public/)という一連の工程が設定されます。
 

  このようにして、サイトをビルドする時の工程をあれやこれや指示することができます。

 Jekyllの場合、これが作動してから数分でビルドが完了するはずです。
 デフォルト設定では間違いなく、デフォルトのドメイン「https://ユーザー名.gitlab.io」がついているサイトに変更が加えられます。

 付け加えておきますが、GitLabでは「gitlab.io」のサブドメインにもTLS証明書を付けています。(ただし、少し制限があるようです。詳しくは説明書をご覧ください。)

 つまり、デフォルトのドメインで安全にサイトを運営することが可能なようにお膳立てされているのです。

 そして、下手に独自ドメインに手を出しておいて、安全対策を打たない方が、やっていることとしては問題ありです。

 あなたは自分の独自ドメインを管理する気がありますか。
 この段階で「めんどうだ」「べつにいいや」と思えるのなら、そのままにしておいてくださいね。

 さて、重たい前置きはここまでにして、独自ドメインにTLS証明書をつける設定にまいります。
 そんなに難しくはありません。

 

  独自ドメインにTLS証明書を付ける方法

  ドメイン名については、どこからから購入してくるはずです。

 次に、この2つの設定をしてください。

  1. ドメインをGitLab Pagesに認証させる(説明書
  2. ウェブサイトに証明書を追加する


 ドメインを追加すると、あなたのウェブサイトには、取得した独自ドメインと、デフォルトのドメインの両方を使うことができます。
 

  しかし、独自ドメインにHTTPS認証をつけると(今回の場合はhttps://新ドメイン.org)、どういうわけだか全く意図していないページに飛ばされることがあります。

 このとき、原因は単なる設定ミスであることがほとんどです。
 (しかし中にはごくたまに、誰かがあなたの情報を盗もうとして作った罠である場合もあるので、少し注意が必要です。)

 設定を誤ると次のような現象が起こります。

  末尾に「 gitlab.io 」がついているページについては、GitLabがTLS証明書をつけています。
 そして、独自ドメインをCNAMEで置き換えたあとだろうと、GItLabレポジトリからサイトにアクセスする時には、システム側の設定により、なるべくgitlab.ioのHTTPS接続を使おうとします。

 問題はそのサイトをブラウザで表示するときです。
 ブラウザそのものは指定された「新ドメイン.org」にアクセスしようとします。ここでブラウザがそのドメインのTLS証明書を受け取ることができれば、問題は起こりません。
 しかし、そこから得られたTLS証明書が「*.gitlab.io」のものだった場合、ブラウザはHTTPSの方に優先して接続しようともしますから、接続先の情報に混乱が生じてしまうのです。

 この現象は、証明書の設定を誤ったときはもちろんのこと、HTTPS化していない独自ドメインでもよく起こります。
  これを予防するためにも、独自ドメインには証明書をつけてください。

 それでは Let's Encryptでの方法を説明します。

  Let's Encryptはまだできて間もない認証局なのですが、適用範囲を自動測定してくれる無料証明書を発行しております。
 誰でも、無料で、HTTPSを使えるという、実に三拍子そろったセットです。

 設定などの操作は、ターミナルでほぼ完結できることも特徴の一つです。

 まずはletsencrypt-autoユーティリティをダウンロードして、証明書を使う準備をしましょう。

 ターミナルから、

======================
$ git clone https://github.com/letsencrypt/letsencrypt
$ cd letsencrypt
======================
 letsencrypt-autoは何かと便利なコースです。

 たとえば、Apacheでウェブサーバーを展開している場合は、「letsencrypt-auto --apache」とウェブサーバー内で指令を出せば、LetsEncryptを使う準備ができてしまいます。

 しかしここで注意しておきたいことがあります。
 「letsencrypt」はUnix系のウェブサーバーでのみ動作することを想定して設計されています。
 なので、Windows系のサーバーでは「letsencrypt-auto」を直接動作させることはできません。しかし別の方法がありますので、こちらの解説を参考に設定してください。
 

  GitLabサーバーでLet's Encryptが使えるようになりました。
 次は手動での設定をします。

======================
$ ./letsencrypt-auto certonly -a manual -d 新ドメイン(半角英数).org
#
# ここで他のドメインを追加したい場合があると思います。 たとえば、「www.他ドメイン(半角英数).org」 というドメインを追加する場合は、
#
./letsencrypt-auto certonly -a manual -d 新ドメイン.org www.他ドメイン.org
#のように、「-d」のあとに追加したいドメインを、半角スペースの後に並べて記述してください。
#

======================

 認証が完了すると、次のメッセージが表示されます。

======================
Make sure your web server displays the following content at
http://YOURDOMAIN.org/.well-known/acme-challenge/5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM
before continuing:

5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM.ewlbSYgvIxVOqiP1lD2zeDKWBGEZMRfO_4kJyLRP_4U

#
# ~省略~
#

Press ENTER to continue
======================
 
 あとは、きちんと認証ができているかを確かめるために、ターミナルからいったん離れて(まだ閉じなくて良い)、ブラウザからサイトを開いてみましょう。

  リクエストした独自ドメインにきちんと接続できたのなら、成功です。
 ね、簡単だったでしょ!
 今回作成したファイルは、ブログの中ではこのようなフォルダとして保管されます。

======================
---
layout: null
permalink: /.well-known/acme-challenge/5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM.html
---

5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM.ewlbSYgvIxVOqiP1lD2zeDKWBGEZMRfO_4kJyLRP_4U
======================

 ここには、Jekyll(静的サイト・ジェネレータ)に対して「cool-blog/_site/.well-known/acme-challenge/5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM.html
の先っちょを無くしたアドレスが書かれていますね。これがサイトの中の「どのページか」を指すアドレスです。
 なので、フロントマターの「permalink」という部分に入るアドレスは適宜変化します。

 しかし、 Jekyll 2とJekyll 3とでは「permalink」の仕様に違いがあるようです。
  なおかつ、3の方が改良が進んでいるということなので、なるべくJekyll3を導入することをおすすめします。

 あと、Jekyll3以外の静的サイト・ジェネレータを使っている場合でも、同じようなファイルが作成されるはずです。

 たとえば、上記のようなリンクが、先っちょもそのままに表示されたり、
「permalink」に相当する部分がイコールマーク(=)になっていたりと、
表記に多少の違いはありますがおおよそ同じです。

 これが「letsencrypt-setup.html」というファイルとして、ブログのルートフォルダに保管されることになります。

 それがきちんと作用しているかどうかを確かめるには、「jekyll serve」というコマンドでローカルサーバーを立ち上げて、先ほどのURLにアクセスしてみます。
 

======================
$ curl http://localhost:4000/.well-known/acme-challenge/5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM
# こんな返答があったら成功です:
5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM.ewlbSYgvIxVOqiP1lD2zeDKWBGEZMRfO_4kJyLRP_4U
======================

 ただし、ここで確かめられたのはローカルホスト上での結果であって、まだGitLabにファイルがアップロードされていないことを忘れてはなりません。

 というわけで、次のコマンドをお忘れなく。

======================
$ git add letsencrypt-setup.html
$ git commit -m "add letsencypt-setup.html file"
$ git push
====================== 

 さて、アップロードしたファイルは作動しているのでしょうか。確かめてみましょう。

======================
# ここで確認するのは、ローカルホストのURLではありませんから、実際にアップされているドメインを入力しましょう。
 $ curl http://YOURDOMAIN.org/.well-known/acme-challenge/5TBu788fW0tQ5EOwZMdu1Gv3e9C33gxjV58hVtWTbDM
======================
 ここで「404 pages not found」と表示されたら、どこかしらに設定ミスがあったのかもしれません。

 しかし、その対処法についてはコメント欄(原文)で触れることにします。
 

  さーて、まだまだやることがありますよ。

 さっき開けっ放しにしておいたターミナルに戻って、ENTERボタンを押してください。
 ここまで説明してきた手順は、まだURLを登録するところまででしたから。

 ドメインにTLS証明書をつける工程が終了すると、しばらくして次のようなメッセージが表示されるはずです。

======================
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
 /etc/letsencrypt/live/YOURDOMAIN.org/fullchain.pem. Your cert will
 expire on 2016-07-04. To obtain a new version of the certificate in
 the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

 Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate

 Donating to EFF: https://eff.org/donate-le
====================== 
 これが出れば、本当にうまくいった証です。
 晴れてあなたのドメインもTLS証明書つきです。よかったですね。

 

  しかし、ここで1つ申し上げなくてはならないことが。
 TLS証明書はその性質上、必ずや有効期限があります。
 Let's Encryptの場合、90日間です。

 なので、上の例でいうところの「expire on 2016-07-04」などと表示される日付をカレンダーに記録しておいて、忘れずに更新手続きを済ませてください。
 万が一、更新が行われなかった場合、証明書の有効期限が切れるため、HTTPSでの通信も行われなくなります。
 先ほど説明したような「ブラウザでサイトに入れない状況」が発生する可能性があります。ご注意ください。
 

  更新の方法をお教えします。
 といっても、更新は登録よりも簡単です。
 GitLabの証明書と暗号鍵をアップロードするだけなので。

 プロジェクトから「Settings -> Pages 」に移動して、
 古いCNAMEを消去し、同じドメインでCNAMEを新しく登録しなおします。しかしこの時はまだ、TLS証明書をアップロードできていません。

 sudoを使って、「/etc/letsencrypt/live/YOURDOMAIN.org/fullchain.pem 」というファイルを開きます。
 そこに書いてある内容をコピーして、「Certificate (PEM)」という欄にはりつけます。

 そしてこちらもまたsudoを使って、「/etc/letsencrypt/live/YOURDOMAIN.org/privkey.pem」というファイルを開いて、その内容をコピーして、今度は「Key (PEM)」という欄にはりつけてください。

 (写真1)Pages設定ページ。「Domain」「Certificate(PEM)」「Key(PEM)」の欄がある。

 

  これだけです。
  さてと、もう一度正しくHTTPSが継続されているか確認しましょう。

======================
$ curl -vX HEAD https://YOURDOMAIN.org/
#
# starting connection(通信開始)
#

* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* Server certificate: YOURDOMAIN.org
* Server certificate: Lets Encrypt Authority X3 * Server certificate: DST Root CA X3
====================== 
 このように表示されたらよいでしょう。


 リダイレクトを整備しよう

  さて、証明書の使い方についてはこれで全てです。
 ただし、証明書を付けたことに関連して必要になる操作があります。それがリダイレクトです。

 ドメインに証明書が付けられたウェブサイトはHTTPとHTTPSの両バージョンがある状態です。
 しかし、できることならHTTPS版のサイトにアクセスを集めた方が良いでしょう。
 また検索エンジンにも、HTTPSでのアクセスを優先させる通知した方が望ましいと言えます。

 

  検索エンジンへ通知

  検索エンジンへの通知は実に簡単です。
 それはHTTPS版のページが「canonical(正当)」であるとエンジンに伝え、全てのユーザーをそこに引き込むように申請します。

 HTMLのヘッダーに次のリンク・タグを付けてください。

======================
<link rel="canonical" href="https://YOURDOMAIN.org/specific/page" />
======================
 ブログにこのタグをつけ、HTTPS版のアドレスをリンクに指定すると、
 検索エンジンがHTTPS版をきちんと表示してくれるようになります。

 

  わすれちゃいけない内部リンク 

  HTTPS化したページでは、安全性が疑わしいリソースへの接続をブロックする機能が働きます。

 この影響で、CSSやJavaScriptファイルの接続がいったん切れてしまいます。指定のしなおしを忘れないでください。

  ここではプロトコル無視用パスを使うのが、手近な方法だと思われます

======================
<link rel="stylesheet" href="//YOURDOMAIN.org/styles.css" />
<script src="//YOURDOMAIN.org/script.js"></script>
====================== 


 JavaScriptを使ったリダイレクト

 これは、GitLabサーバーを使っている限りはほとんど発生しない現象なのですが、
  ユーザーが誤ってHTTPのついたアドレスを使って、HTTP版のサイトにアクセスしてしまう現象が、たまに発生します。
 たとえば、ユーザーの「お気に入り」に登録されていたアドレスがHTTPだった時などが代表的でしょう。

  こうして接続してしまったユーザーの場合、
 あらかじめ運営側がユーザーに誘導をかけておかないと、HTTP版から抜け出すこともできません。

 応急措置として、301レスポンスを送信して、HTTPS版に転送するようにする対策が必要です。

  次のJavaScriptコードなどを追加します。

======================
var host = "新ドメイン.org";
if ((host == window.location.host) && (window.location.protocol != 'https:')) {
window.location = window.location.toString().replace(/^http:/, "https:");
}
======================
 
 ただし、これを入れておけばそつがないわけではなく、次の問題があります。

  1. JavaScriptが使えない、あるいは拒否されている場合は作動しない。
  2. アタッカーにコードを改ざんされやすいため、中間者攻撃が起こりやすい
  3. ブラウザ自体がリダイレクト先のアドレスを自動的に覚えてくれるわけではないので、ユーザーが同じURLを使い続ける可能性が高い



 まとめ

  (写真2)HTTPS化されたウェブサイト
 ウェブサイトをHTTPS化することが、とても簡単だということがおわかりいただけましたか。
 無料なわけですし、皆さんには是非とも、迷わずHTTPS化に取り組んでいただきたい。
 

  GitLabでLet's Encryptについて、さらなる議論や情報提供をしてくれる方は、GitLab EEの「#474」「#467」「#472」にコンタクトを取ってください。
 いつでもお待ちしております。
 

  それから、 Pierre Far氏 と Ilya Grigorik氏 によるHTTPS解説もわかりやすいので、おすすめです。

  またリンク先の、SSL Labs提供の無料オンライン・サービスでは、ご自分のウェブサイトがHTTPS化されているかどうかを確認できます。
 「ウェブサーバーが、どのような設定でSSL化されているかまで分析できる」という触れ込みです。
 

  この記事はPaul Wakefordによる文章を参考に書かれています。

  ここまで読んでいただき、ありがとうございました。

 

 
PDF
更新日:2017-10-10 21:24:06 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://about.gitlab.com/2016/04/11/tutorial-securing-your-gitlab-pages-with-tls-and-letsencrypt/ Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】GitLab RunnerをFreeBSDにインストールする

GitLab Runner > GitLab Runnerをインストールする >FreeBSDにインストールする 注: FreeBSDでは、現在 ”開発最先端”とされているリリース を利用することも可能です。  GitLab …2017-12-13 17:21:41

GitLab CI にプッシュしたものを GitHubに出力する | from: Leow Kah Man - Tech Blog

 今僕は、GitLabでウェブサイトを公開するためにGitLab CIランナーを使っています。でも、今度はそれをGitHub pagesでも公開できるようにしてみたい。  もしも、ネットのコンテンツを…2017-12-11 23:59:39

僕がHugo静的サイト・ジェネレータをGitLabで使うときにしたCI設定 | from Leow Kah Man - Tech Blog

 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとCIビルドが自動的にできるところが便利です。  僕はGitLabのレポジトリにNodeJS Dockerイメージを構…2017-12-11 23:58:18

【GitLab 公式 を訳してみた】GitLab Runnerをインストールする

GitLab Runner > GitLab Runnerをインストールする  GitLab Runnerは、GNU/Linux、 macOS、 FreeBSD、 Windowsでインストールと使用することが可能です。  インストールには3つ…2017-12-06 17:57:33