Skip to main content

HTTPS で GitHub Pages サイトを保護する

HTTPS は、他者によるあなたのサイトへのトラフィックの詮索や改ざんを防ぐ暗号化のレイヤーを追加します。 透過的に HTTP リクエストを HTTPS にリダイレクトするために、あなたの GitHub Pages サイトに HTTPS を強制できます。

この機能を使用できるユーザーについて

{data variables.product.prodname_pages %}は、パブリック・リポジトリのGitHub Freeと組織用のGitHub Free、パブリック・リポジトリとプライベート・リポジトリの、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverで利用できます。 詳しくは、「GitHub のプラン」をご覧ください。

リポジトリの管理者権限があるユーザは、GitHub Pages サイトに強制的に HTTPS を指定できます。

HTTPS と GitHub Pages について

カスタムドメインが正しく設定されたサイトを含めたすべての GitHub Pages サイトは、HTTPS や HTTPS 強制をサポートします。 カスタム ドメインについて詳しくは、「カスタムドメインとGitHub Pagesについて」と「カスタムドメインとGitHub Pages のトラブルシューティング」をご覧ください。

GitHub Pages サイトは、パスワードやクレジットカード番号といった機密情報のやりとりに使うべきではありません。

警告: エンタープライズが Enterprise Managed Users を使用しない限り、サイトのリポジトリがプライベートまたは内部であっても、GitHub Pages サイトは既定でインターネット上で一般公開されます。 サイトのアクセス制御を管理することで、サイトをプライベートで公開できます。 それ以外の場合、サイトのリポジトリにセンシティブなデータがあるなら、公開前にそのデータを取り除くのが良いでしょう。 詳細については、「リポジトリについて」および「GitHub Pages サイトの可視性を変更する」を参照してください。

注: RFC3280 では、共通名の長さは最大 64 文字とされています。 したがって、証明書が正常に作成されるようにするには、GitHub Pagesサイトのドメイン名全体の長さは64文字未満でなければなりません。

あなたの GitHub Pages サイトに HTTPS を強制する

  1. GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ページ] をクリックします。

  4. 「GitHub Pages」で、 [HTTPS の適用] を選択します。

証明書プロビジョニングのトラブルシューティング ("Certificate not yet created" (証明書がまだ作成されていません) エラー)

Pagesの設定でカスタムドメインを設定もしくは変更した場合、自動DNSチェックが開始されます。 このチェックは、DNS設定がGitHubによる自動的な証明書の取得を許可するように設定されているかを判断します。 チェックが正常に終わったら、GitHub によって、[Let's Encrypt] から TLS 証明書をリクエストするジョブがキューイングされます。 有効な証明書を受信すると、GitHubは自動的にそれをPagesのTLSターミネーションを処理するサーバーにアップロードします。 このプロセスが正常に終了すると、カスタムドメイン名の横にチェックマークが表示されます。

Let's Encrypt の証明書を発行するには、GitHub Pages サイトを一般公開する必要があることに注意してください。 証明書が発行されたら、サイトを非公開に戻すことができます。

このプロセスには多少の時間がかかることがあります。 [保存] をクリックしてから数分経ってもプロセスが完了しない場合は、カスタム ドメイン名の横にある [削除] をクリックしてみてください。 ドメイン名を再入力し、 [保存] をもう一度クリックします。 これでプロビジョニングのプロセスがキャンセルされ、再起動されます。

混在したコンテンツの問題を解決する

GitHub Pages サイトで HTTPS を有効にしているのに、サイトの HTML が HTTP 経由で画像、CSS、または JavaScript を引き続き参照している場合、サイトは "混在したコンテンツ" を提供しています。 混在したコンテンツを提供することで、サイトのセキュリティが下がり、アセットの読み込みに問題が生じる場合があります。

サイトでのコンテンツの混在を解消するには、サイトの HTML で http://https:// に変更して、すべてのアセットが HTTPS 経由で提供されるようにしてください。

アセットは通常、以下の場所にあります。

  • サイトで Jekyll を使っている場合、HTML ファイルはおそらく _layouts フォルダーにあります。
  • CSS は通常、HTML ファイルの <head> セクションにあります。
  • JavaScript は通常、<head> セクションか、</body> を閉じるタグの直前にあります。
  • 画像は通常、<body> セクションにあります。

ヒント: サイトのソース ファイルにアセットが見つからない場合は、テキスト エディターか GitHub Enterprise Cloud で、サイトのソース ファイルを http で検索してください。

HTML ファイルで参照されているアセットの例

資産の種類HTTPHTTPS
CSS<link rel="stylesheet" href="http://example.com/css/main.css"><link rel="stylesheet" href="https://example.com/css/main.css">
JavaScript<script type="text/javascript" src="http://example.com/js/main.js"></script><script type="text/javascript" src="https://example.com/js/main.js"></script>
Image<a href="http://www.somesite.com"><img src="http://www.example.com/logo.jpg" alt="Logo"></a><a href="https://www.somesite.com"><img src="https://www.example.com/logo.jpg" alt="Logo"></a>

DNS 構成を確認する

場合によっては、カスタム ドメインの DNS 構成が原因で HTTPS 証明書を生成できなくなります。 これは、余計な DNS レコードや GitHub Pages の IP アドレスをポイントしていないレコードが原因で発生する可能性があります。

HTTPS 証明書を正しく生成するには、次の構成をお勧めします。 @ ホスト付きの追加の AAAAAALIASANAME レコード、または、www サブドメインまたは GitHub Pages で使用するその他のカスタム サブドメインをポイントする CNAME レコードは、HTTPS 証明書の生成を妨げる可能性があります。

シナリオDNS レコードの種類DNS レコード名DNS レコード値
Apex ドメイン
(example.com)
A@185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
Apex ドメイン
(example.com)
AAAA@2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153
Apex ドメイン
(example.com)
ALIAS または ANAME@USERNAME.github.io または
ORGANIZATION.github.io
Subdomain
(www.example.com,
blog.example.com)
CNAMESUBDOMAIN.example.com.USERNAME.github.io または
ORGANIZATION.github.io