HTTPSにおけるクライアント認証(Mutual TLS)の話 - Qiita
Mutual TLSとはなにか 我々が例えばブラウザでウェブサイトを見るとき、接続先のサーバーが信頼できることを保証するためにHTTPSを使います。一方でサーバー側から見て接続してくるクライアントが信頼できることを保証するためにTLSクライアント認証という仕組みがあります。 これを同時にやることをMutual TLS(SSL)と呼びます。Mutualとは相互という意味です。 これは公式な定義がない用語ではありますが、結構広く使われているようです。 これから数回に分けてNginxを題材にMutual TLS設定の話を書いて行こうと思います。 ですがHTTPSについてはほとんど説明しません。なぜならHTTPSサーバーの設定についての記事は世の中に多く存在するためです。畢竟、TLSクライアント認証に関する話題がほとんどとなる予定です。 仕組みについては適宜記述しますが、どちらかというと設定の話が
Let's Encrypt に重大なバグが発覚。該当サイトは2020/3/4 までに対応が必須 - Qiita
Let's Encrypt にバグが発見されました。利用ドメイン全体の 2.6% のサイトに影響があるとの事です 有効な証明書の 2.6% に影響があるとの事です。影響があるサイトは 2020/3/4 までに対応が必要です。すでに期限は過ぎています。該当サイトには個別にメールが届きますが、メールが届かない場合もあるとの事なので注意して下さい。 この記事では問題の概要と該当するかどうかの確認方法、および対応方法について記載しています。 記事の修正を行いました（2020/3/6 追記） この記事は筆者の予想をはるかに超えて多くの方に読んで頂きました。ありがとうございます。改めて読み返してみると不完全な部分も多かったため、以下の修正を行いました。 2.6% の意味が不正確だったので修正 バグの概要と、その影響について以下の項に追記 問題の概要 どんな影響があるのか？ 確認方法の詳細、補足説明、注
SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する
以下順を追って説明します。 HelloRequest 相手にClientHelloを送信するよう促すメッセージです。送信しなくても構いません。 ClientHello ServerHello ClientHelloとServerHelloは、TLSのひとつめの肝です。後ほど説明します。 ServerCertificate サーバ証明書を送信します。中間CA証明書なども、ここで送ります。 ServerKeyExchange 鍵交換メッセージその１です。鍵交換はTLSのふたつめの肝で、これも後ほど説明します。 CertificateRequest クライアント証明書を送信するように促すメッセージです。クライアント証明書が必要な場合に送信します。何そのクライアント証明書って？と思った方は読み飛ばして構いません。 ServerHelloDone サーバからの送信終了を示すエンドマークです。 Cli
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
Modern Ciphersuite: 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-AES1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
