Hnoss

Hnoss

 案外すぐに120記事超えました。
 でも、きちんと使えるだけの情報にするには、まだまだ量、質共に足りないかんじ。
 ただ、ふと思う時がある。みんなちょっと手を差し伸べればどうにでもなることで困ってたりして、そこを解決できさえすれば、量とか質とかあんまり関係ないのかもねって。
 
カレンダー

文書タグ

フノス(訳者)(125) IT(97) 解説記事(52) オープンソース(49) メディア(31) Linux(29) ウェブ制作(22) DTM(19) HTML5(19) Libre Music(18) おすすめ オープンソース・ソフトウェア(17) 百科事典(14) プラグイン(13) 文化(12) ソフトウェア(11) 録音(11) ミキシング(11) コンテナ(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) 音楽編集(8) セキュリティ(8) シーケンス(8) 芸能(8) マスタリング(7) 音楽(7) 経済(6) 業務効率化(5) JACK(5) 音楽プレーヤー(4) コマンド(4) マイクロサービス(4) Google(4) 映像制作(4) アプリ(4) 欧州(3) Ubuntu(3) 北米(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Windows(3) WordPress(3) Android(3) ソーシャルメディア(3) GNU(3) DAW(3) ウィッカ(2) Twitter(2) GPL(2) オカルト(2) ロスレス音源(2) Python(2) スマホ(2) 牛(2) ニュース(2) GNOME3(2) 歴史(2) 仮想通貨(2) マーケティング(2) PlayStation(2) 古代エジプト(2) 有角神(2) Java(2) ERPシステム(2) ワークフロー(2) 電子ブック(2) エジプト(2) ALSA(2) OS X(2) トヨタ(2) Krita(2) 電子書籍(2) ERP(2) バト(2) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) 日記(1) パシュパティ(1) アピス(1) 宗教(1) テレビ(1) BountySource(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) 教育(1) bi-modal IT(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) Papagayo(1) 写真(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 聖書(1) 任天堂 DS(1) 学校(1) 日本(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) アップストリーム・パッケージング(1) 画像(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) サウンドフォント(1) ヤーウェ(1) CD(1) タブレット(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) ポータブルソフトウェア(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) リーナス・トーバルズ(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) スタジオジブリ(1) クヌム(1) 魔女裁判(1) オンデマンド(1) 政治(1) バフォメット(1) 国際(1) クリエイティブ・コモンズ(1) 黙示録(1) Synfig(1) 独占(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) EU(1) イボ人(1) 国際公文書館会議(1) マイナビ(1) キリスト教(1) レビ記(1) アマナイ(1) 広告(1) KXStudio(1) 絵文字(1) サンフランシスコ(1) イケンガ(1) リクルート(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) Blender(1) 出エジプト記(1) 観光案内(1) ツイッター(1) Youtube(1) パキスタン(1) CC(1) ハトホル(1) パン(1) 地方(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ゲーム(1) 法律(1) 中南米(1) モヘンジョ=ダロ(1) 悪魔(1) ラジオ(1) OpenToonz(1) 電子教材(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional

site_image
Tutorial: Securing your GitLab Pages with TLS and Let's Encrypt  | about gitlab.com / Guest author André Miranda
https://about.gitlab.com/2016/04/11/tutorial-securing-your-gitlab-pages-with-tls-and-letsencrypt/
Hnoss Hnoss     最終更新:2017-10-10 21:24:06    PDF


 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による文章を参考に書かれています。

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

原文:https://about.gitlab.com/2016/04/11/tutorial-securing-your-gitlab-pages-with-tls-and-letsencrypt/
Creative Commons License
この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス外部リンク
新着文書(Hnoss)

GitLab Pages documentation
GitLab Documentation > User documentation > Projects >GitLab Pages 説明書  GitLabには「Gi...
GitLab Pages administration
  はじめに GitLab Pages機能 は、GitLab EE 8.3以降から使えるようになりました。 カスタムCNAMEにTLS証明書が使えるようになった のは、...
GitLab Pages from A to Z: Part 3 / Marcia Ramos
GitLab Documentation > User documentation > Projects > GitLab Pages 説明書 >GitLab Pages のこと全部教えます!③ 記事の 種類 ...

新着文書

What do women’s rights have to do with the SDGs and the internet?
女性の権利はSDGsとインターネットにどのような関係があるか? 2017年8月2日、スリランカ 女性は均質な集団ではなく、科学技術へのアクセスもまた、...
Sexual rights and the internet: Third EROTICS global survey now launched!
性的権利とインターネット:第3回EROTICS国際調査、現在開始! 2017年7月19日 EROTICS国際調査が戻ってきた! もしあなたが、インターネットを自ら...
An ongoing conversation on feminist autonomous infrastructure: Erika Smith and Kéfir
フェミニストの自律的な基盤に関する継続中の会話:エリカ・スミスとKéfir 2017年8月2日、メキシコ 2017年7月に始動した小さな資金調達とし...

新着Wikipedia翻訳

HTTP Public Key Pinning
HTTP公開鍵ピニング HTTP公開鍵ピニング(HPKP: HTTP Public Key Pinning)[1]とは、HTTPヘッダによって実現されるセキュリティの仕組みであり、HT...
Double Ratchet Algorithm
ダブル・ラチェット・アルゴリズム 「ダブル・ラチェット」はこの項目へ転送されています。工具については レンチ を参照下さい。 暗号技術におい...
aplay
 aplayとは ALSA sound card driver 用の コマンドライン オーディオファイルプレーヤーである。復数種類の ファイル形式 、様々なデバイスのサ...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2017-10-10 21:24:01 Hnoss
2 2017-10-10 21:23:18 Hnoss
3 2017-10-10 21:22:46 Hnoss
4 2017-10-10 21:22:01 Hnoss
5 2017-10-10 00:01:19 Hnoss
6 2017-10-09 23:57:27 Hnoss
7 2017-10-09 23:55:53 Hnoss
8 2017-10-09 23:44:28 Hnoss
9 2017-10-09 23:42:39 Hnoss
10 2017-10-09 23:42:01 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →