Webでは、Webサイト、Webサーバー、またはWebアプリケーションに対して発行される証明書とは何ですか?
証明書、Webサイト、Webサーバー、Webアプリケーションのどれを処理する必要がありますか?
たとえば、NginxでWebアプリケーションを実行すると、HTTPSおよび証明書をサポートするようにNginxを構成するための 記事 が表示されます。
HTTPSと証明書をサポートするためにWebアプリケーションを実装する必要があるかどうか疑問に思っていましたか? (そうしないと、Webアプリケーションの開発が簡単になります)
Webサーバーは複数のWebサイトをホストできるため、Nginxの構成と証明書がWebサーバーレベルとWebサイトレベルのどちらにあるのかも疑問に思いましたか?
ありがとう。
Webサイト自体は単なるHTMLドキュメントであり、スクリプトとスタイルシート、および他のリソース(外部スクリプト、スタイル、画像など)への参照が含まれている可能性があります。ドキュメント自体は、HTTPとHTTPSのどちらで提供されているか、また提供されている場合は、どの証明書を使用したかを認識していません。
代わりに、これらはWebサーバーによって処理されます。 nginxなどのWebサーバーには、証明書と、証明書に関連付けられた秘密鍵を与えることができます。 HTTPSを処理するように構成されている場合、Webサーバーはこの証明書をすべての着信TLS接続で使用します。
Nginxに関して、「Webサイト」と「Webサーバー」を混同しているようです。 Webサイトは1つのドキュメントであり、「Webサーバー」はnginxの1つの論理ユニットであり、独自の構成と、より重要なのはホスト名を備えています。
そのため、nginxは次のように構成できます。
server {
listen 443;
server_name server1.example.org
ssl_certificate cert1.pem;
ssl_certificate_key key1.pem;
}
server {
listen 443;
server_name server2.example.org
ssl_certificate cert2.pem;
ssl_certificate_key key2.pem;
}
...
ホスト名server1.example.orgでWebサーバーに到達すると、cert1.pemにある証明書を提供します。同様に、server2.example.orgとして到達した場合、cert2.pemからの証明書を提供します。
同様に、「Webアプリケーション」は、サーバー側のロジックが背後にあるドキュメントの単なるファンシーな名前です。ただし、これも証明書やTLS接続を処理しません。実際、証明書を変更するとコードベースを変更する必要があるため、Webアプリケーションを移植すると、移植性が大幅に低下します。
この分割は、2つの異なるタスクを分離するため、意図的に行われました。 Webサーバーのタスクは、着信接続の受け入れ、HTTP要求の解析、TLS接続の処理などです。これがすべて完了すると、Webサーバーは解析された要求をWebアプリケーションに転送し、Webアプリケーションはすべてのアプリケーションロジックを処理します。