Let’s Encryptは、無料の自動化されたオープンな認証局（CA）であり、一般の人々の利益のために運営されています。Let’sEncryptの背後にある主な原則は次のとおりです。
Let’s Encryptの背後にある主要な原則は無料です。ドメイン名を所有している人は誰でも、Let’sEncryptを使用して信頼できる証明書を無料で取得できます。
- 無料： ドメイン名を所有している人は誰でも、Let’s Encryptを使用して、信頼できる証明書を無料で取得できます。
- 自動： Webサーバーで実行されているソフトウェアは、Let’s Encryptと対話して、簡単に証明書を取得し、使用できるように安全に構成して、自動的に更新を処理できます。
- 安全： Let’s Encryptは、CA側と、サイトオペレーターがサーバーを適切に保護するのを支援することの両方で、TLSセキュリティのベストプラクティスを推進するためのプラットフォームとして機能します。
- 透明： 発行または取り消されたすべての証明書は公に記録され、誰でも検査できるようになります。
- オープン： 自動発行および更新プロトコルは、他の人が採用できるオープンスタンダードとして公開されます。
- 協同組合： 基盤となるインターネットプロトコル自体と同様に、Let’s Encryptは、1つの組織の制御を超えて、コミュニティに利益をもたらすための共同の取り組みです。
（出典：https：//letsencrypt.org/about/）
まず、Let'sEncryptサービスのいくつかの暗い側面について言及する必要があります。無料の公開認証局とオープン認証局のアイデアは素晴らしいものですが、それは私たちにも多くの問題をもたらします。開発者は、証明書を取得するシステムをできるだけ単純にすることを試みましたが、それでもサーバー管理のより高いスキルが必要です。したがって、ISPConfig（http://www.ispconfig.org/）のような開発者の多くは、このソリューションを直接実装しています。これにより、システム全体に対するより効果的な展開と監視がはるかに簡単かつ柔軟になります。
多くの人が、Let'sEncryptを本番サイトに実装することを決定しました。私はこれが非常に（しかし本当に非常に）注意せずに行われるべき非常に悪い考えだと思います。 Let's Encryptは自由をもたらしますが、SHA-256RSA暗号化での証明書の使用を制限します。 SHA-256のサポートは、過去数年間で改善されています。ほとんどのブラウザ、プラットフォーム、メールクライアント、モバイルデバイスはすでにSHA-256をサポートしています。ただし、Windows XP pre-SP3などの一部の古いオペレーティングシステムは、SHA-256暗号化をサポートしていません。多くの組織は、ユーザーエクスペリエンスの問題に遭遇することなく、SHA-256に変換できます。また、多くの組織は、古くて安全性の低いシステムを実行しているユーザーにアップグレードを勧めたいと思うかもしれません。
このチュートリアルでは、この非互換性に簡単に対処しますが、それでも厄介な方法です。
- Apacheバージョン2.4以降
- OpenSSLバージョン1.0.1e以降
- Apachemod_rewriteが有効になっています
前述のように、インターネットにはまだSHA-256署名と互換性のないデバイスがあります。一部のWebサイトにSSLを導入することを余儀なくされたとき、次の2つのオプションのどちらかを決定する必要がありました。
- Let's Encryptを使用すると、無料で利用できますが、すべてではありません。
- 128ビットの署名付きの証明書を購入する。
まあ、それでもオプションはありません。 1は、ずっと前に顧客に約束されていた唯一の方法でした（：これ以上の理論はありません：
私は必要なことを説明したことを望みます、そして今、私たちは私たちのウェブサイトのサポートされていない視聴者に対処することができます。 SP2以下のWindowsXPマシンを使用している人はたくさんいます（はい、まだたくさんあります）。したがって、これらの人々をフィルタリングする必要があります。
「/etc/apache2/sites-available/your_domain.com.conf」で、ファイルの最後に次を追加します。
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !(NT\ 5) [NC]
RewriteRule ^(.*) https:// your_domain.com [R]
RewriteCondは、ページにアクセスするゲストのhttpヘッダーから文字列を取得します。こちらで確認して詳細を確認できます：http：//www.useragentstring.com/
使用した条件は、「文字列に「NT 5」が含まれていない場合」のようなものを示しています。RewriteRuleは、ドメインのhttpsバリアントに[R]をリダイレクトするルールを実行/適用します。NT5は、WindowsXPデバイス用のOSバージョンの文字列です。 。このリダイレクトを使用しない場合、互換性のないユーザーはhttpsWebサイトにアクセスできません。
このリダイレクトを使用しないと、互換性のないユーザーはhttps Webサイトにアクセスできなくなります。このソリューションは、一部のソリューションとして100％完全ではないことを警告する必要があります
一部のゲストは関連情報や実際の情報を提供する必要がないため、このソリューションが100％完璧ではないことを警告する必要があります。私はAWstatsと協力して、自分のページにアクセスしている不明なシステムの割合を把握しました。これは約1.3％であるため、リクエストはほとんどありません。互換性を確保するために不明なオペレーティングシステムを処理する場合は、条件に不明を追加することもできます（RewriteCond％{HTTP_USER_AGENT}！（NT \ 5 | unknown）[NC]）。
Awstats
互換性のない訪問者を正常に「リダイレクトしない」（httpの安全でない世界にとどめる）と、https側に集中できます。
HTTPS構成
ここで、証明書がすでにWebサーバーに割り当てられており、有効になっていることを前提としています。
vhost構成ファイルに、次を追加します。
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLProtocol All -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder On
ここで使用されているCipherSuiteは、通常より少し長くなっています。互換性を高めるためです。 https://cipherli.st/またはhttps://mozilla.github.io/server-side-tls/ssl-config-generator/
から独自のものを入手できます。繰り返しになりますが、高度なセキュリティポリシーと互換性を満たすための完全な構成を取得することはできません。妥協点を見つける必要があります。
これらの設定を使用した後、https：//www.ssllabs.com/ssltest/index.html
でサーバーの構成と互換性をテストできます。互換性のあるデバイスと互換性のないデバイスの長いリストが見つかります。また、独自の「完璧な」ソリューションを示すための詳細情報もあります。