Ubuntu18.04でApacheの自己署名SSL証明書を作成する方法
序章
TLS 、またはトランスポート層セキュリティ、およびその前身である SSL は、セキュアソケットレイヤーの略で、通常のラップに使用されるWebプロトコルです。保護され、暗号化されたラッパーのトラフィック。
このテクノロジーを使用すると、サーバーは、外部の関係者によってメッセージが傍受される可能性なしに、サーバーとクライアント間でトラフィックを安全に送信できます。 証明書システムは、ユーザーが接続しているサイトのIDを確認するのにも役立ちます。
このガイドでは、Ubuntu18.04のApacheWebサーバーで使用する自己署名SSL証明書を設定する方法を学習します。
注:自己署名証明書は、サーバーとクライアント間の通信を暗号化します。 ただし、Webブラウザに含まれている信頼できる認証局(CA)のいずれによっても署名されていないため、ユーザーは証明書を使用してサーバーのIDを自動的に検証することはできません。
サーバーにドメイン名が関連付けられていない場合や、暗号化されたWebインターフェイスがユーザー向けでない場合は、自己署名証明書が適切な場合があります。 do にドメイン名がある場合、多くの場合、CA署名付き証明書を使用することをお勧めします。 Ubuntu 18.04でLet’sEncryptを使用してApacheを保護する方法に関するガイドを使用して、無料の信頼できる証明書を設定する方法の詳細をご覧ください。
前提条件
このチュートリアルを完了するには、次のものが必要です。
- root以外のユーザーが構成された1つのUbuntu18.04サーバー
sudo
特権とファイアウォールが有効になっています。 このようなユーザーアカウントを設定するには、 Ubuntu18.04を使用したサーバーの初期設定に従います。 - ApacheWebサーバーがインストールされています。 LAMP(Linux、Apache、MySQL、PHP)スタック全体をサーバーにインストールする場合は、 Ubuntu18.04でのLAMPのセットアップに関するガイドに従ってください。 Apache Webサーバーのみが必要な場合は、PHPとMySQLに関連する手順をスキップしてください。
前提条件を完了したら、次の手順に進みます。
ステップ1—SSL証明書を作成する
TLS / SSLは、公開証明書と秘密鍵の組み合わせを使用して機能します。 SSLキーはサーバー上で秘密にされます。 クライアントに送信されるコンテンツを暗号化するために使用されます。 SSL証明書は、コンテンツを要求するすべての人と公に共有されます。 これは、関連付けられたSSLキーによって署名されたコンテンツを復号化するために使用できます。
単一のOpenSSLコマンドを使用して、自己署名キーと証明書のペアを作成できます。
- sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt
これにより、一連の質問が表示されます。 それらについて説明する前に、発行しているコマンドで何が起こっているかを確認します。
openssl
:これは、OpenSSL証明書、キー、およびその他のファイルを作成および管理するための基本的なコマンドラインツールです。req
:このサブコマンドは、X.509証明書署名要求(CSR)管理を使用するように指定します。 「X.509」は、SSLおよびTLSが鍵と証明書の管理のために準拠している公開鍵インフラストラクチャ標準です。 新しいX.509証明書を作成するには、このサブコマンドを使用します。-x509
:これは、通常行われるように証明書署名要求を生成する代わりに、自己署名証明書を作成するようにユーティリティに指示することにより、前のサブコマンドをさらに変更します。-nodes
:これは、パスフレーズで証明書を保護するオプションをスキップするようにOpenSSLに指示します。 Apacheは、サーバーの起動時に、ユーザーの介入なしにファイルを読み取れる必要があります。 パスフレーズは、ユーザーが再起動するたびにパスフレーズを入力する必要があるため、これが発生するのを防ぎます。-days 365
:このオプションは、証明書が有効であると見なされる時間の長さを設定します。 この場合、1年間に設定されています。-newkey rsa:2048
:これは、新しい証明書と新しいキーを同時に生成することを指定します。 証明書に署名するために必要なキーは前の手順で作成されていないため、証明書と一緒に作成する必要があります。 Thersa:2048
部分は、2048ビット長のRSAキーを作成するように指示します。-keyout
:この行は、作成中の生成された秘密鍵ファイルを配置する場所をOpenSSLに指示します。-out
:これは、作成中の証明書を配置する場所をOpenSSLに指示します。
前に述べたように、これらのオプションはキーファイルと証明書の両方を作成します。 情報を証明書に正しく埋め込むために、サーバーについていくつか質問があります。
プロンプトに適切に記入します。
プロンプトの全リストは次のように出力されます。
OutputCountry Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com
作成した両方のファイルは、下の適切なサブディレクトリに配置されます /etc/ssl
.
ステップ2—SSLを使用するようにApacheを構成する
これで、キーファイルと証明書ファイルが正常に作成されました。 /etc/ssl
ディレクトリ。 次に、これらを利用するためにApache構成を変更する必要があります。
これを行うには、構成にいくつかの調整を加えます。
- 強力なデフォルトSSL設定を指定する構成スニペットを作成します。
- 含まれているSSLApache仮想ホストファイルを変更して、生成されたSSL証明書を指すようにします。
- (推奨)暗号化されていない仮想ホストファイルを変更して、要求を暗号化された仮想ホストに自動的にリダイレクトします。
完了すると、安全なSSL構成が作成されます。
強力な暗号化設定を使用したApache構成スニペットの作成
まず、Apache構成スニペットを作成してSSL設定を定義します。 これにより、Apacheに強力なSSL暗号スイートが設定され、サーバーを安全に保つのに役立ついくつかの高度な機能が有効になります。 設定するパラメータは、SSLを有効にする任意の仮想ホストで使用できます。
で新しいスニペットを作成します /etc/apache2/conf-available
ディレクトリ。 この例では、を使用してファイルを作成します nano
ファイルに名前を付けます ssl-params.conf
その目的を明確にするために。 お好みのテキストエディタを自由に使用してください。
- sudo nano /etc/apache2/conf-available/ssl-params.conf
Apache SSLを安全に設定するために、Cipherlist.euの推奨事項を採用します。 Cipherlist.eu は、一般的なソフトウェアで使用されている暗号化設定を理解するための便利でわかりやすいリソースです。
注: Cipherlist.eu から提案されたこれらの設定は、強力なセキュリティを提供します。 場合によっては、これにはクライアントの互換性が向上するという犠牲が伴います。 古いクライアントをサポートする必要がある場合は、というラベルの付いたページのリンクをクリックしてアクセスできる代替リストがあります。「はい、レガシー/古いソフトウェアで動作する暗号スイートをください。」必要に応じて、そのリストを次のサンプルコードブロックのコンテンツに置き換えることができます。
使用する構成の選択は、サポートする必要があるものに大きく依存します。 どちらも優れたセキュリティを提供します。
目的のために、提供された設定全体をコピーしてください。 ただし、を無効にすることで、小さな変更を1つ行うことができます。 Strict-Transport-Security
ヘッダー(HSTS)。
HSTSをプリロードするとセキュリティが向上しますが、誤って有効にした場合や誤って有効にした場合は、広範囲に及ぶ結果が生じる可能性があります。 このガイドでは、設定を有効にしませんが、影響を理解していることが確実な場合は、設定を変更できます。
決定する前に、 HTTP Strict Transport Security(HSTS )、特に「プリロード」機能についてお読みください。
次に、構成をに貼り付けます ssl-params.conf
ファイル:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM
# Requires Apache 2.4.36 & OpenSSL 1.1.1
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:prime256v1
# Older versions
# SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On
# Disable preloading HSTS for now. You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
# Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off
終了したら、ファイルを保存して閉じます。 使用している場合 nano
、を押すことでこれを行うことができます CTRL + X
、 それから Y
と ENTER
.
デフォルトのApacheSSL仮想ホストファイルの変更
次に、変更します /etc/apache2/sites-available/default-ssl.conf
、デフォルトのApacheSSL仮想ホストファイル。 別のサーバーブロックファイルを使用している場合は、次のコマンドでその名前に置き換えてください。
始める前に、元のSSL仮想ホストファイルをバックアップします。
- sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak
次に、SSL仮想ホストファイルを開いて調整します。
- sudo nano /etc/apache2/sites-available/default-ssl.conf
内部では、ほとんどのコメントが削除されており、仮想ホストファイルにはデフォルトで次のコンテンツが含まれています。
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</IfModule>
ファイルに若干の調整を加えます。 まず、仮想ホストファイルで調整したい通常のものを設定します(たとえば、 ServerAdmin
電子メールアドレス、 ServerName
、など、調整します SSL
証明書とキーファイルを指すディレクティブ)。
これらの変更を行った後、サーバーブロックは次のようになります。
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin [email protected]
ServerName server_domain_or_IP
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
</VirtualHost>
</IfModule>
終了したら、ファイルを保存して閉じます。
(推奨)HTTPSにリダイレクトするようにHTTPホストファイルを変更する
現在のところ、サーバーは暗号化されていないHTTPトラフィックと暗号化されたHTTPSトラフィックの両方を提供します。 セキュリティを強化するために、ほとんどの場合、HTTPをHTTPSに自動的にリダイレクトすることをお勧めします。 この機能が必要ない、または必要ない場合は、このセクションをスキップしても問題ありません。
暗号化されていない仮想ホストファイルを調整して、すべてのトラフィックをSSL暗号化にリダイレクトするには、 /etc/apache2/sites-available/000-default.conf
ファイル:
- sudo nano /etc/apache2/sites-available/000-default.conf
以内 VirtualHost
構成ブロック、追加 Redirect
ディレクティブ、すべてのトラフィックをサイトのSSLバージョンにポイントします。
<VirtualHost *:80>
. . .
Redirect "/" "https://your_domain_or_IP/"
. . .
</VirtualHost>
終了したら、ファイルを保存して閉じます。
ステップ3—ファイアウォールを調整する
あなたが持っている場合 ufw
ファイアウォールが有効になっている場合、前提条件ガイドで推奨されているように、SSLトラフィックを許可するように設定を調整する必要がある場合があります。 幸いなことに、Apacheはいくつかのプロファイルをに登録します ufw
インストール時に。
次のコマンドを実行して、使用可能なプロファイルのリストを表示します。
- sudo ufw app list
出力は次のようになります。
OutputAvailable applications:
Apache
Apache Full
Apache Secure
OpenSSH
ステータスを確認することで、現在の設定を確認できます。
- sudo ufw status
以前に通常のHTTPトラフィックのみを許可した場合、出力結果は次のようになります。
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Apache ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Apache (v6) ALLOW Anywhere (v6)
追加のHTTPSトラフィックを許可するには、「Apache Full」プロファイルを許可してから、冗長な「Apache」プロファイルの許容値を削除します。
- sudo ufw allow 'Apache Full'
- sudo ufw delete allow 'Apache'
ステータスを確認して変更を確認します。
- sudo ufw status
OutputStatus: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Apache Full ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Apache Full (v6) ALLOW Anywhere (v6)
これで、ファイアウォールへのApacheトラフィックが正常に許可されました。
ステップ4—Apacheでの変更を有効にする
変更を加えてファイアウォールを調整したので、ApacheでSSLおよびヘッダーモジュールを有効にし、SSL対応の仮想ホストを有効にして、Apacheを再起動できます。
有効 mod_ssl
、Apache SSLモジュール、および mod_headers
、SSLスニペットの一部の設定で必要です。 a2enmod
指図:
- sudo a2enmod ssl
- sudo a2enmod headers
次に、SSL仮想ホストを有効にします a2ensite
指図:
- sudo a2ensite default-ssl
また、を有効にする必要があります ssl-params.conf
ファイル、設定した値を読み込むには:
- sudo a2enconf ssl-params
この時点で、サイトと必要なモジュールが有効になります。 テストを使用して、ファイルに構文エラーがないことを確認します。
- sudo apache2ctl configtest
すべてが成功すると、次の結果が得られます。
OutputAH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK
最初の行は、 ServerName
ディレクティブはグローバルに設定されていません。 そのメッセージを取り除きたい場合は、 ServerName
サーバーのドメイン名またはIPアドレスに /etc/apache2/apache2.conf
. メッセージは害を及ぼさないため、これはオプションです。
出力に Syntax OK
その中で、構成ファイルには構文エラーはありません。 これで、Apacheを安全に再起動して、変更を実装できます。
- sudo systemctl restart apache2
変更を加えたら、次にSSLサーバーをテストします。
ステップ5—暗号化のテスト
次に、SSLサーバーをテストします。 Webブラウザーを開いて、次のように入力します。 https://
サーバーのドメイン名またはIPをアドレスバーに入力します。
https://server_domain_or_IP
作成した証明書は、ブラウザの信頼できる認証局の1つによって署名されていないため、次のような警告が表示される可能性があります。
これは予想された正常なことです。 ホストの信頼性のサードパーティによる検証ではなく、証明書の暗号化の側面にのみ関心があります。 ADVANCED をクリックしてから、提供されたリンクをクリックして、とにかくホストに進みます。
あなたはあなたのサイトに連れて行かれるべきです。 ブラウザのアドレスバーに、「x」が付いたロックが表示されます。 これは、証明書を検証できないことを意味します。 それはまだあなたの接続を暗号化しています。
HTTPをHTTPSにリダイレクトするようにApacheを設定した場合は、リダイレクトが正しく機能するかどうかを確認することもできます。
http://server_domain_or_IP
これで同じアイコンが表示される場合は、リダイレクトが正しく機能したことを意味します。
ステップ6—永続的なリダイレクトへの変更
リダイレクトが正しく機能し、暗号化されたトラフィックのみを許可することが確実な場合は、暗号化されていないApache仮想ホストを再度変更してリダイレクトを永続的にする必要があります。
サーバーブロック構成ファイルを再度開きます。
- sudo nano /etc/apache2/sites-available/000-default.conf
を見つける Redirect
以前に追加した行。 追加 permanent
その行に、リダイレクトを302一時リダイレクトから301永続リダイレクトに変更します。
<VirtualHost *:80>
. . .
Redirect permanent "/" "https://your_domain_or_IP/"
. . .
</VirtualHost>
ファイルを保存して閉じます。
構文エラーがないか構成を確認してください。
- sudo apache2ctl configtest
準備ができたら、Apacheを再起動して、リダイレクトを永続的にします。
- sudo systemctl restart apache2
暗号化されたトラフィックのみを許可するようにリダイレクトを永続的にすることに成功しました。
結論
クライアント接続に強力な暗号化を使用するようにApacheサーバーを構成しました。 これにより、リクエストを安全に処理できるようになり、外部の関係者がトラフィックを読み取るのを防ぐことができます。