メニュー
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

チュートリアル: Amazon Linux で SSL/TLS を使用できるように Apache ウェブサーバーを設定する

Secure Sockets Layer/Transport Layer Security (SSL/TLS) は、ウェブサーバーとウェブクライアントの間に、転送中のデータが傍受されないように保護する、暗号化されたチャネルを確立します。このチュートリアルでは、Apache ウェブサーバーを実行している単一の Amazon Linux インスタンスに、SSL/TLS のサポートを手動で追加する方法を説明します。ここでは説明しませんが、AWS Certificate Manager は、商業グレードのサービスを提供する予定がある場合には良い選択肢です。

注記

歴史的経緯から、ウェブの暗号化は、単純に SSL と呼ばれることが少なくありません。ウェブブラウザでは今でも SSL がサポートされていますが、後継プロトコルである TLS プロトコルの方が攻撃を受けにくいと考えられています。Amazon Linux では、すべてのバージョンの SSL をデフォルトで無効にしており、TLS バージョン 1.0 についても、以下に説明するように無効にすることをお勧めします。最新の暗号化標準については、RFC 7568 を参照してください。

重要

これらの手順は Amazon Linux で使用するためのものです。他のディストリビューションのインスタンスでの LAMP ウェブサーバーのセットアップは、このチュートリアルの範囲外です。 Ubuntu の LAMP ウェブサーバーについては、Ubuntu コミュニティのドキュメントの ApacheMySQLPHP トピックを参照してください。Red Hat Enterprise Linux については、Customer Portal でウェブサーバーに関するトピックを参照してください。

前提条件

このチュートリアルを開始する前に、次のステップを完了してください。

  • EBS-backed Amazon Linux インスタンスを起動します。詳細については、「ステップ 1: インスタンスを起動する」を参照してください。

  • インスタンスが以下の TCP ポートで接続を受け付けるようにセキュリティグループを設定します。

    • SSH (ポート 22)

    • HTTP (ポート 80)

    • HTTPS (ポート 443)

    詳細については、「Amazon EC2 でのセットアップ」を参照してください。

  • Apache ウェブサーバーをインストールします。手順については、チュートリアル: Amazon Linux への LAMP ウェブサーバーのインストール」を参照してください。必要なのは http24 パッケージおよび対応する従属コンポーネントのみです。PHP および MySQL に関連する手順は無視してかまいません。

  • ウェブサイトの識別と認証を行うため、SSL/TLS の公開鍵基盤 (PKI) ではドメインネームシステム (DNS) を使用します。EC2 インスタンスを使用してパブリックウェブサイトをホストする計画がある場合は、ウェブサーバーのドメイン名を登録するか、既存のドメイン名を Amazon EC2 ホストに移す必要があります。これについては、ドメイン登録および DNS ホスティングに関するサードパーティのサービスが多数存在します。Amazon Route 53 を使用することもできます。

ステップ 1: サーバーでの SSL/TLS の有効化

この手順では、自己署名のデジタル認証を使用して、Amazon Linux で SSL/TLS をセットアップします。

注記

自己署名証明書はテスト用であり、本稼働環境では使用できません。インターネットに自己署名証明書を公開すると、サイトへの訪問者にセキュリティ警告が表示されます。

To enable SSL/TLS on a server

  1. Connect to your instance and confirm that Apache is running.

    Copy
    [ec2-user ~]$ sudo service httpd status

    If necessary, start Apache.

    Copy
    [ec2-user ~]$ sudo service httpd start
  2. To ensure that all of your software packages are up to date, perform a quick software update on your instance. This process may take a few minutes, but it is important to make sure you have the latest security updates and bug fixes.

    注記

    The -y option installs the updates without asking for confirmation. If you would like to examine the updates before installing, you can omit this option.

    Copy
    [ec2-user ~]$ sudo yum update -y
  3. Now that your instance is current, add SSL/TLS support by installing the Apache module mod_ssl:

    Copy
    [ec2-user ~]$ sudo yum install -y mod24_ssl

    Later in this tutorial you will work with three important files that have been installed:

    • /etc/httpd/conf.d/ssl.conf

      The configuration file for mod_ssl. It contains "directives" telling Apache where to find encryption keys and certificates, the SSL/TLS protocol versions to allow, and the encryption ciphers to accept.

    • /etc/pki/tls/private/localhost.key

      An automatically generated, 2048-bit RSA private key for your Amazon EC2 host. During installation, OpenSSL used this key to generate a self-signed host certificate, and you can also use this key to generate a certificate signing request (CSR) to submit to a certificate authority (CA).

    • /etc/pki/tls/certs/localhost.crt

      An automatically generated, self-signed X.509 certificate for your server host. This certificate is useful for testing that Apache is properly set up to use SSL/TLS.

    The .key and .crt files are both in PEM format, which consists of Base64-encoded ASCII characters framed by "BEGIN" and "END" lines, as in this abbreviated example of a certificate:

                            -----BEGIN CERTIFICATE-----
                            MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
                            MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
                            DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
                            bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
                            ...
                            z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
                            WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
                            3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
                            -----END CERTIFICATE-----                    

    The file names and extensions are a convenience and have no effect on function; you can call a certificate cert.crt, cert.pem, or any other file name, so long as the related directive in the ssl.conf file uses the same name.

    注記

    When you replace the default SSL/TLS files with your own customized files, be sure that they are in PEM format.

  4. Restart Apache.

    Copy
    [ec2-user ~]$ sudo service httpd restart

    注記

    Make sure the TCP port 443 is accessible on your EC2 instance, as described above.

  5. Your Apache web server should now support HTTPS (secure HTTP) over port 443. Test it by typing the IP address or fully qualified domain name of your EC2 instance into a browser URL bar with the prefix https://. Because you are connecting to a site with a self-signed, untrusted host certificate, your browser may display a series of security warnings.

    Override the warnings and proceed to the site. If the default Apache test page opens, it means that you have successfully configured SSL/TLS on your server. All data passing between the browser and server is now safely encrypted.

    To prevent site visitors from encountering warning screens, you need to obtain a certificate that not only encrypts, but also publicly authenticates you as the owner of the site.

ステップ 2: CA 署名証明書の取得

このセクションでは、プライベートキーから証明書署名リクエスト (CSR) を生成して認証機関 (CA) に送信し、署名付きホスト証明書を取得して、これを使用できるように Apache を設定するプロセスについて説明します。

自己署名 SSL/TLS X.509 ホスト証明書は、暗号化技術上は CA 署名証明書と同じです。これらの相違は数学的なものではなく、社会的なものです。CA では、最低でもドメイン所有権を検証してから申請者に証明書を発行することを保証しています。そのため、各ウェブブラウザには、ブラウザベンダーが信頼する CA のリストが含まれています。X.509 証明書は主に、プライベートサーバーキーに対応するパブリックキーと、このパブリックキーに暗号で関連付けられている CA による署名で構成されています。HTTPS 経由でブラウザがウェブサーバーに接続すると、サーバーは、信頼された CA のリストをブラウザが確認できるように、証明書を提示します。署名者がリストに含まれている場合や、他の信頼された署名者の信頼チェーンを通じてアクセス可能である場合、ブラウザはサーバーと、高速暗号化データチャネルのネゴシエーションを行い、ページをロードします。

証明書には、リクエストの確認作業が必要であり、一般的に費用がかかるため、各社を比較することをお勧めします。よく知られている CA のリストについては、dmoztools.net のサイトを参照してください。いくつかの CA では、基本レベル証明書が無料で提供されます。なかでも最も注目すべきは Let's Encrypt プロジェクトです。このプロジェクトでは、証明書の作成および更新プロセスの自動化もサポートしています。Let's Encrypt を CA として使用する方法の詳細については、「付録: Amazon Linux での Let's Encrypt と Certbot の使用」を参照してください。

ホスト証明書の基盤にはキーがあります。2017 年時点で、政府および業界グループは、2030 年まで、ドキュメントを保護するための RSA キーに 2048 ビットの最小キー (モジュロ) サイズを使用することを推奨しています。Amazon Linux で OpenSSL によって生成されるデフォルトのモジュラスサイズは 2048 ビットです。つまり、自動生成された既存のキーは、CA 署名証明書に適しています。モジュラスサイズを大きくする、別の暗号化アルゴリズムを使用するなど、キーのカスタマイズが必要な場合は、次に示す代替手順に従ってください。

To obtain a CA-signed certificate

  1. Connect to your instance and navigate to /etc/pki/tls/private/. This is the directory where the server's private key for SSL/TLS is stored. If you prefer to use your existing host key to generate the CSR, skip to Step 3.

  2. (Optional) Generate a new private key. Here are some sample key configurations. Any of the resulting keys work with your web server, but they vary in how (and how much) security they implement.

    1. As a starting point, here is the command to create an RSA key resembling the default host key on your instance:

      Copy
      [ec2-user ~]$ sudo openssl genrsa -out custom.key 2048

      The resulting file, custom.key, is a 2048-bit RSA private key.

    2. To create a stronger RSA key with a bigger modulus, use the following command:

      Copy
      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096

      The resulting file, custom.key, is a 4096--bit RSA private key.

    3. To create a 4096-bit encrypted RSA key with password protection, use the following command:

      Copy
      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096

      This results in a 4096-bit RSA private key that has been encrypted with the AES-128 cipher.

      重要

      Encryption provides greater security, but because an encrypted key requires a password, services depending on it cannot be auto-started. Each time you use this key, you need to supply the password "abcde12345" over an SSH connection.

    4. RSA cryptography can be relatively slow, because its security relies on the difficulty of factoring the product of two large two prime numbers. However, it is possible to create keys for SSL/TLS that use non-RSA ciphers. Keys based on the mathematics of elliptic curves are smaller and computationally faster when delivering an equivalent level of security. Here is an example:

      Copy
      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      The output in this case is a 256-bit elliptic curve private key using prime256v1, a "named curve" that OpenSSL supports. Its cryptographic strength is slightly greater than a 2048-bit RSA key, according to NIST.

      注記

      Not all CAs provide the same level of support for elliptic-curve-based keys as for RSA keys.

    Make sure that the new private key has highly restrictive ownership and permissions (owner=root, group=root, read/write for owner only). The commands would be as follows:

    Copy
    [ec2-user ~]$ sudo chown root.root custom.key [ec2-user ~]$ sudo chmod 600 custom.key [ec2-user ~]$ ls -al custom.key

    The commands above should yield the following result:

    -rw------- root root custom.key

    After you have created and configured a satisfactory key, you can create a CSR.

  3. Create a CSR using your preferred key; the example below uses custom.key:

    Copy
    [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

    OpenSSL opens a dialog and prompts you for information shown in the table below. All of the fields except Common Name are optional for a basic, domain-validated host certificate.

    Name Description Example
    Country Name The two-letter ISO abbreviation for your country. US (=United States)
    State or Province Name The name of the state or province where your organization is located. This name cannot be abbreviated. Washington
    Locality Name The location of your organization, such as a city. Seattle
    Organization Name The full legal name of your organization. Do not abbreviate your organization name. Example Corporation
    Organizational Unit Name Additional organizational information, if any. Example Dept
    Common Name

    This value must exactly match the web address that you expect users to type into a browser. Usually, this means a domain name with a prefixed host name or alias in the form www.example.com. In testing with a self-signed certificate and no DNS resolution, the common name may consist of the host name alone. CAs also offer more expensive certificates that accept wild-card names such as *.example.com.

    www.example.com
    Email Address The server administrator's email address. someone@example.com

    Finally, OpenSSL prompts you for an optional challenge password. This password applies only to the CSR and to transactions between you and your CA, so follow the CA's recommendations about this and the other optional field, optional company name. The CSR challenge password has no effect on server operation.

    The resulting file csr.pem contains your public key, your digital signature of your public key, and the metadata that you entered.

  4. Submit the CSR to a CA. This usually consists of opening your CSR file in a text editor and copying the contents into a web form. At this time, you may be asked to supply one or more subject alternate names (SANs) to be placed on the certificate. If www.example.com is the common name, then example.com would be a good SAN, and vice versa. A visitor to your site typing in either of these names would see an error-free connection. If your CA web form allows it, include the common name in the list of SANs. Some CAs include it automatically.

    After your request has been approved, you will receive a new host certificate signed by the CA. You may also be instructed to download an intermediate certificate file that contains additional certificates needed to complete the CA's chain of trust.

    注記

    Your CA may send you files in multiple formats intended for various purposes. For this tutorial, you should only use a certificate file in PEM format, which is usually (but not always) marked with a .pem or .crt extension. If you are uncertain which file to use, open the files with a text editor and find the one containing one or more blocks beginning with the following:

    - - - - -BEGIN CERTIFICATE - - - - - 

    The file should also end with the following:

    - - - -END CERTIFICATE - - - - -

    You can also test a file at the command line as follows:

    Copy
    [ec2-user certs]$ openssl x509 -in certificate.crt -text

    Examine the output for the tell-tale lines described above. Do not use files ending with .p7b, .p7c, or similar extensions.

  5. Remove or rename the old self-signed host certificate localhost.crt from the /etc/pki/tls/certs directory and place the new CA-signed certificate there (along with any intermediate certificates).

    注記

    There are several ways to upload your new certificate to your EC2 instance, but the most straightforward and informative way is to open a text editor (vi, nano, notepad, etc.) on both your local computer and your instance, and then copy and paste the file contents between them. You need root [sudo] privileges when performing these operations on the EC2 instance. This way, you can see immediately if there are any permission or path problems. Be careful, however, not to add any additional lines while copying the contents, or to change them in any way.

    From inside the /etc/pki/tls/certs directory, check that the file ownership, group, and permission settings match the highly restrictive Amazon Linux defaults (owner=root, group=root, read/write for owner only). The commands would be as follows:

    Copy
    [ec2-user certs]$ sudo chown root.root custom.crt [ec2-user certs]$ sudo chmod 600 custom.crt [ec2-user certs]$ ls -al custom.crt

    The commands above should yield the following result:

    -rw------- root root custom.crt

    The permissions for the intermediate certificate file are less stringent (owner=root, group=root, owner can write, group can read, world can read). The commands would be:

    Copy
    [ec2-user certs]$ sudo chown root.root intermediate.crt [ec2-user certs]$ sudo chmod 644 intermediate.crt [ec2-user certs]$ ls -al intermediate.crt

    The commands above should yield the following result:

    -rw-r--r-- root root intermediate.crt
  6. If you used a custom key to create your CSR and the resulting host certificate, remove or rename the old key from the /etc/pki/tls/private/ directory, and then install the new key there.

    注記

    There are several ways to upload your custom key to your EC2 instance, but the most straightforward and informative way is to open a text editor (vi, nano, notepad, etc.) on both your local computer and your instance, and then copy and paste the file contents between them. You need root [sudo] privileges when performing these operations on the EC2 instance. This way, you can see immediately if there are any permission or path problems. Be careful, however, not to add any additional lines while copying the contents, or to change them in any way.

    From inside the /etc/pki/tls/private directory, check that the file ownership, group, and permission settings match the highly restrictive Amazon Linux defaults (owner=root, group=root, read/write for owner only). The commands would be as follows:

    Copy
    [ec2-user private]$ sudo chown root.root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ ls -al custom.key

    The commands above should yield the following result:

    -rw------- root root custom.key
  7. Because the file name of the new CA-signed host certificate (custom.crt in this example) probably differs from the old certificate, edit /etc/httpd/conf.d/ssl.conf and provide the correct path and file name using Apache's SSLCertificateFile directive:

    Copy
    SSLCertificateFile /etc/pki/tls/certs/custom.crt

    If you received an intermediate certificate file (intermediate.crt in this example), provide its path and file name using Apache's SSLCACertificateFile directive:

    Copy
    SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt

    注記

    Some CAs combine the host certificate and the intermediate certificates in a single file, making this directive unnecessary. Consult the instructions provided by your CA.

    If you installed a custom private key (custom.key in this example), provide its path and file name using Apache's SSLCertificateKeyFile directive:

    Copy
    SSLCertificateKeyFile /etc/pki/tls/private/custom.key
  8. Save /etc/httpd/conf.d/ssl.conf and restart Apache.

    Copy
    [ec2-user ~]$ sudo service httpd restart

ステップ 3: セキュリティ設定のテストと強化

SSL/TLS が運用可能になりパブリックに公開されたら、実際の安全性をテストする必要があります。セキュリティセットアップの詳細な分析を無料で行うことのできる Qualys SSL Labs などのオンラインサービスを使用すると簡単です。その結果に基づき、受け入れるプロトコル、優先する暗号化方式、除外する暗号化方式を制御することによって、デフォルトのセキュリティ設定を強化するかどうかを決定できます。詳細については、Qualys のスコアの計算方法を参照してください。

重要

サーバーのセキュリティを確保するには、実際のテストが非常に重要です。小さな設定エラーによって、深刻なセキュリティ侵害やデータの損失が生じる可能性があります。調査や新たな脅威に応じて、推奨されるセキュリティ管理方法は常に変化するため、適切なサーバー管理を行うには、定期的なセキュリティ監査が不可欠です。

Qualys SSL Labs のサイトで、サーバーの完全修飾ドメイン名を www.example.com という形式で入力します。約 2 分後に、サイトに関するグレード (A から F) と、結果の詳細な内訳が届きます。以下の表は、Amazon Linux でのデフォルトの Apache 設定およびデフォルトの Certbot 証明書と同じ設定を使用しているドメインのレポートをまとめたものです。

総合評価 B
証明書 100%
プロトコルサポート 95%
キー交換 90%
暗号強度 90%

このレポートは、設定がほとんど正常であり、証明書、プロトコルサポート、キー交換、暗号強度に関して許容範囲の評価であることを示しています。設定では、前方秘匿性もサポートしています。前方秘匿性とは、プライベートキーから派生した一時 (エフェメラル) セッションキーを使用して暗号化を行う、プロトコルの機能です。これは、攻撃者がウェブサーバーの長期的なプライベートキーを所有していても、HTTPS データを復号できないことを意味します。ただし、このレポートは、全体のグレードを低下させる原因となる重大な脆弱性についても警告しており、追加の潜在的な問題を指摘しています。

  1. RC4 暗号化方式のサポート: 暗号化方式は、暗号化アルゴリズムの計算の中核です。SSL/TLS データストリームの暗号化に使用される高速の暗号化方式である RC4 は、いくつかの重大な脆弱性を持つことで知られています。修正方法は、RC4 サポートを完全に無効にすることです。また、明示的暗号順序と禁止された暗号の明示的リストも指定します。

    設定ファイル /etc/httpd/conf.d/ssl.conf で、SSLCipherSuiteSSLProxyCipherSuite のコメントアウトされた設定例を含むセクションを探します。

    Copy
    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 #SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

    これらの設定はそのままにして、その下に以下のディレクティブを追加します。

    注記

    ここでは読みやすくするために数行に分けて示していますが、これらの 2 つのディレクティブは 1 行に指定する必要があります。暗号化方式名はスペースで区切りません。

    Copy
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES: !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLProxyCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES: !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

    これらの暗号化方式は、OpenSSL でサポートされている暗号化方式の長いリストのうち、一部です。これらは、以下の条件に応じて選択され、順序付けられています。

    1. 前方秘匿性のサポート

    2. Strength

    3. スピード

    4. 特定の暗号化方式、その後に暗号化方式のファミリー

    5. 許可されている暗号化方式、その後に拒否されている暗号化方式

    ランクの高い暗号化方式の名前には、ECDHE が含まれています (Elliptic Curve Diffie-Hellman Ephemeral など)。ephemeral は前方秘匿性を示します。また、RC4 は現在、リストの最後に近い位置にあり、禁止された暗号化方式に含まれています。

    デフォルトや、内容が見えない簡単なディレクティブに依存するのではなく、暗号化方式の明示的なリストを使用することをお勧めします。

    重要

    ここに示されている暗号化方式リストは、多数考えられるリストの 1 つに過ぎません。たとえば、前方秘匿性よりスピードを重視したリストが必要になることもあります。

    古いクライアントをサポートする必要性が予測される場合は、DES-CBC3-SHA 暗号化スイートを許可することができます。

    最後に、OpenSSL の更新ごとに、新しい暗号化方式が導入され古い暗号化方式が廃止されます。EC2 の Amazon Linux インスタンスを最新の状態に維持し、セキュリティに関する OpenSSL からの告知に注意して、技術分野の報道でセキュリティ面の新しい脆弱性に関するレポートを警戒してください。詳細については、Elastic Load Balancing ユーザーガイド の「Elastic Load Balancing での事前定義された SSL のセキュリティポリシー」を参照してください。

    最後に、次の行について、"#" を削除してコメント解除します。

    #SSLHonorCipherOrder on

    このコマンドは、(この場合) 前方秘匿性をサポートするものも含めて、ランクの高い暗号化方式を優先するようサーバーに強制します。このディレクティブが有効になると、サーバーは、セキュリティの弱い暗号化方式に戻る前に、セキュリティが強力な接続を確立しようとします。

  2. 廃止されるプロトコルサポート: 設定では、TLS 1.0 および 1.1 をサポートしていますが、これらのバージョンは廃止が予定されています。2018 年 6 月以降は TLS 1.2 が推奨されます。今後のプロトコルサポートに対応できるように、設定ファイル /etc/httpd/conf.d/ssl.conf を開き、行頭に # を付けて以下の行をコメントアウトしてください。

    #SSLProtocol all -SSLv3
    #SSLProxyProtocol all -SSLv3

    次に、次のディレクティブを追加します。

    Copy
    SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    これらのディレクティブにより、SSL バージョン 2、3、および TLS バージョン 1.0、1.1 が明示的に無効化されます。サーバーは、クライアントが TLS の廃止されていないバージョンを使用している場合を除き、クライアントと暗号化接続を確立することを拒否するようになります。ディレクティブに含める指定が多くなるほど、サーバーの動作に対する設定内容が明確にわかりやすくなります。

    注記

    このようにして、TLS バージョン 1.0 および 1.1 を無効にすると、ごく一部の古くなったウェブブラウザによるサイトへのアクセスがブロックされるようになります。

編集した設定ファイルにこれらの変更を保存した後、Apache を再起動します。

Qualys SSL Labs でドメインをもう一度テストすると、RC4 脆弱性が解決し、次のようなサマリレポートが出力されます。

総合評価 A
証明書 100%
プロトコルサポート 100%
キー交換 90%
暗号強度 90%

トラブルシューティング

  • パスワードを指定しないと Apache ウェブサーバーが起動しません。

    これは、パスワードで保護された暗号化プライベート サーバー キーをインストールした場合は正常な動作です。

    その暗号化のキーとパスワードを削除できます。デフォルトディレクトリに custom.key という暗号化プライベート RSA キーがあり、そのパスフレーズが abcde12345 であるとすると、EC2 インスタンスで次のコマンドを実行し、このキーの非暗号化バージョンを生成してください。

    Copy
    [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root.root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo service httpd restart

    パスワードが求められずに Apache が起動するようになります。

付録: Amazon Linux での Let's Encrypt と Certbot の使用

Let's Encrypt 認証局は、インターネット全体を暗号化するための Electronic Frontier Foundation (EFF) の取り組みの中核部分です。この目標を踏まえ、Let's Encrypt ホスト証明書は、手動による介入を最小限に抑えながら、作成、評価、インストール、保守されるように設計されています。証明書管理の自動化側面はウェブサーバー上で動作しているエージェントによって実行されます。インストールおよび設定されたエージェントは、Let's Encrypt と安全に通信して、Apache およびキー管理システム上で管理タスクを実行します。このチュートリアルでは、Certbot エージェントを使用します。このエージェントを使用することで、カスタマイズされた暗号化キーを証明書の基盤として提供するか、エージェント自身がそのデフォルト値を使用してキーを作成できます。また、「Configure Automated Certificate Renewal」で説明するように、手動による介入なしで定期的に証明書を更新するよう Certbot を設定することもできます。詳細については、Certbot のユーザーガイドまたはマニュアルページを参照してください。

重要

Certbot の開発者は、Amazon Linux での Certbot のサポートは実験的なものであると警告しています。何かうまくいかなければ簡単に回復できるように、Certbot をインストールする前に EBS ルートボリュームのスナップショットを作成しておくことをお勧めします。EBS スナップショットの作成方法の詳細については、「Amazon EBS スナップショットの作成」を参照してください。

Install and Run Certbot

While Certbot is not officially supported on Amazon Linux, and is not available from the Amazon Linux package repositories, it functions correctly once installed. These instructions are based on EFF's documentation for installing Certbot on RHEL 6.

This procedure describes the default use of Certbot, resulting in a certificate based on a 2048-bit RSA key. If you want to experiment with customized keys, you might start with Using ECDSA certificates with Let's Encrypt.

  1. Enable the Extra Packages for Enterprise Linux (EPEL) repository from the Fedora project on your instance. Packages from EPEL are required as dependencies when you run the Certbot installation script.

    Copy
    [ec2-user ~]$ sudo yum-config-manager --enable epel
  2. Download the latest release of Certbot from EFF onto your EC2 instance using the following command.

    Copy
    [ec2-user ~]$ wget https://dl.eff.org/certbot-auto
  3. Make the downloaded file executable.

    Copy
    [ec2-user ~]$ chmod a+x certbot-auto
  4. Run the file with root permissions and the --debug flag.

    Copy
    [ec2-user ~]$ sudo ./certbot-auto --debug
  5. At the prompt "Is this ok [y/d/N]," type "y" and press Enter.

  6. At the prompt "Enter email address (used for urgent renewal and security notices)," type a contact address and press Enter.

  7. Agree to the Let's Encrypt Terms of Service at the prompt. Type "A" and press Enter to proceed:

    -------------------------------------------------------------------------------
    Please read the Terms of Service at
    https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
    in order to register with the ACME server at
    https://acme-v01.api.letsencrypt.org/directory
    -------------------------------------------------------------------------------
    (A)gree/(C)ancel: A
  8. Click through the authorization for EFF put you on their mailing list by typing "Y" or "N" and press Enter.

  9. At the prompt shown below, type your Common Name (the name of your domain as described above) and your Subject Alternative Name (SAN), separating the two names with a space or a comma. Then press Enter. In this example, the names have been provided:

    No names were found in your configuration files. Please enter in your domain
    name(s) (comma and/or space separated)  (Enter 'c' to cancel):example.com www.example.com
  10. On an Amazon Linux system with a default Apache configuration, you see output similar to the example below, asking about the first name you provided. Type "1" and press Enter.

    Obtaining a new certificate
    Performing the following challenges:
    tls-sni-01 challenge for example.com
    tls-sni-01 challenge for www.example.com
    
    We were unable to find a vhost with a ServerName or Address of example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       |                       | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
  11. Next, Certbot asks about the second name. Type "1" and press Enter.

    We were unable to find a vhost with a ServerName or Address of www.example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       |                       | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1

    At this point, Certbot creates your key and a CSR:

    Waiting for verification...
    Cleaning up challenges
    Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
    Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem
  12. Authorize Certbot to create and all needed host certificates. When prompted for each name, type "1" and press Enter as shown in the example:

    We were unable to find a vhost with a ServerName or Address of example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       |                       | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
    Deploying Certificate for example.com to VirtualHost /etc/httpd/conf.d/ssl.conf
    
    We were unable to find a vhost with a ServerName or Address of www.example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       | example.com        | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
    Deploying Certificate for www.example.com to VirtualHost /etc/httpd/conf.d/ssl.conf
  13. Choose whether to allow insecure connections to your web server. If you choose option 2 (as shown in the example), all connections to your server will either be encrypted or rejected.

    Please choose whether HTTPS access is required or optional. 
    -------------------------------------------------------------------------------
    1: Easy - Allow both HTTP and HTTPS access to these sites
    2: Secure - Make all requests redirect to secure HTTPS access
    -------------------------------------------------------------------------------
    Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

    Certbot completes the configuration of Apache and reports success and other information:

    Congratulations! You have successfully enabled https://example.com and
    https://www.example.com
    
    You should test your configuration at:
    https://www.ssllabs.com/ssltest/analyze.html?d=example.com
    https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com
    -------------------------------------------------------------------------------
    
    IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at
       /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will
       expire on 2017-07-19. To obtain a new or tweaked version of this
       certificate in the future, simply run certbot-auto again with the
       "certonly" option. To non-interactively renew *all* of your
       certificates, run "certbot-auto renew"
    ....
  14. After you complete the installation, test and optimize the security of your server as described in ステップ 3: セキュリティ設定のテストと強化.

Configure Automated Certificate Renewal

Certbot is designed to become an invisible, error-resistant part of your server system. By default, it generates host certificates with a short, 90-day expiration time. Prior to expiration, re-run the certbot command manually if you have not previously allowed your system to call the command automatically. This procedure shows how to automate Certbot by setting up a cron job.

  1. After you have successfully run Certbot for the first time, open /etc/crontab in a text editor and add a line similar to the following:

    39      1,13    *       *       *       root    /home/ec2-user/certbot-auto renew --no-self-upgrade

    Here is an explanation of each component:

    39 2,14 * * *

    Schedules a command to be run at 02:39 and 14:39 every day. The selected values are arbitrary, but the Certbot developers suggest running the command twice daily.

    root

    The command runs with root privileges.

    /home/ec2-user/certbot-auto renew --no-self-upgrade

    The command to be run. The path /home/ec2-user/ assumes that you installed Certbot in your default user home directory; adjust this as necessary. The renew subcommand causes Certbot to check any previously obtained certificates and to renew those that are approaching expiration. The --no-self-upgrade flag prevents Certbot from upgrading itself without your intervention.

    Save the file when done.

  2. Restart the cron daemon:

    Copy
    [ec2-user ~]$ sudo service crond restart