翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 HTTP から HTTPS へのリダイレクトの設定 「Elastic Beanstalk 環境の HTTPS の設定」およびそのサブトピックでは、HTTPS を使用してアプリケーションへのトラフィックを暗号化できるように Elastic Beanstalk 環境を設定する方法について説明します。このトピックでは、エンドユーザーがアプリケーションへの HTTP トラフィックを開始した場合に、それをエレガントに処理する方法について説明します。これを行うには、HTTP から HTTPS へのリダイレクトを設定します。これは、HTTPS の強制と呼ばれることもあります。 リダイレクトを設定するには、まず、HTTPS トラフィックを処理するように環境を設定します。次に、HTT
オレオレ証明書を作成するJava の keytool でオレオレ証明書を作成することができます。 下記のコマンドを実行すると「keystore.p12」というファイルが作成されます。 > keytool -genkey -alias tomcat -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keystore.p12 -validity 3650 キーストアのパスワードを入力してください:password 新規パスワードを再入力してください:password 姓名は何ですか。 [Unknown]: 組織単位名は何ですか。 [Unknown]: 組織名は何ですか。 [Unknown]: 都市名または地域名は何ですか。 [Unknown]: 都道府県名または州名は何ですか。 [Unknown]: この単位に該当する2文字の国コードは
こんにちは、リサリサです。 p12ファイルをACMに登録したので、記事にしておきます。 p12(PKCS#12)とは? Personal Information Exchange Syntax Standard という規格で定義されたフォーマットのファイルです。Windowsに証明書をインポートする際に使ったりします。 秘密鍵、証明書、中間CA証明書(ある場合)を含んでいますが、テキストエディタなどで開く事が出来ず、このままでは ACM にインポートできません。 やりたいこと p12形式の証明書をACMに登録したい。 やってみた 秘密鍵、証明書、中間CA証明書を取り出す ACMの登録には p12形式ではなく、秘密鍵、証明書、中間CA証明書がそれぞれ pem形式で必要なので、まずはそれぞれを取り出します。 openssl を使用して取り出します。 #秘密鍵 openssl pkcs12 -i
最初に言っておきます。 mitmproxyは、開発の生産性をUPさせるモノです。 上手く使えば、開発の生産性がかなり向上します。 しかし、悪用しようと思えば悪用も可能です。 SSL通信であっても、通信を傍受できてしまいます。 つまり、パスワードをのぞき見することが可能になります。 でも、これは確実に犯罪です。 したがって、決して悪用はしないください。 今回は、そんな危険な可能性を持ったmitmproxyを紹介します。 本記事の内容 mitmproxyとは?mitmproxyのシステム要件mitmproxyのインストールmitmproxyの動作確認 それでは、上記に沿って解説していきます。 mitmproxyとは? mitmproxyとは、SSL/TLS対応のインターセプトプロキシです。 わけがわからないですね。 もうすこしわかりやすく説明します。 インターセプトとは、通信の傍受という意味で
やまゆです。 現在 TLS の実装として一番に挙げられるライブラリは OpenSSL 1.1 ですね。 他に Google fork の BoringSSL や LibreSSL などがありますが、もともとはどちらも OpenSSL の実装をベースにしていますので、やはり大元としては OpenSSL になります。 執筆現在の OpenSSL 安定板バージョンは 1.1.1l です。 2.x はリリースされず 3.0 が次のリリースになる予定です。 このツイートによると、 来週火曜 に正式リリースされるようです。 追記 2021/09/07) OpenSSL 3.0.0 がリリースされました! こちらの記事から変更点について挙げていきます。 ライセンスの変更。今までは OpenSSL と SSLeay のデュアルライセンスでしたが、 Apache License 2.0 に変更されます。 バ
開発環境でもSSL対応をする理由 開発環境でのSSL対応方法 証明書の作成 SpringBootで証明書の設定 端末で証明書を信頼 本番環境のSSL対応は? 開発環境でもSSL対応をする理由 最近のwebアプリケーションでは、SSL対応させることが当たり前になっていますよね。 Let's Encryptなどもあり、無料で設定することもできるようになってきました。 ただ、webアプリケーションによっては、SSL対応をしている場合としていない場合で動作が変わることもあります。 特に開発環境では、SSL対応を考慮に入れずに開発してしまうこともあるのではないでしょうか。 本番環境にアップしてから考慮漏れに気付き、焦ってしまうこともありますよね。 よって、開発環境と本番環境の環境の差異を極力なくすためにも、開発環境でSSL対応をしたいという方もいるはずです。 今回はそんな方のニーズにお応えするための
SSL 証明書を米国東部 (バージニア北部) リージョンに移行して CloudFront ディストリビューションで使用する方法を教えてください。 AWS Certificate Manager (ACM) に SSL 証明書があり、これを Amazon CloudFront ディストリビューションに関連付けたいと思っています。ただし、証明書は米国東部 (バージニア北部) (us-east-1) の AWS リージョンにはないため、証明書をディストリビューションに関連付けることができません。証明書の移動方法がわかりません。 解決策 ACM の既存の証明書をあるリージョンから別のリージョンに移行することはできません。代わりに、ターゲットリージョンに証明書をインポートまたは作成します。 ACM 証明書を CloudFront ディストリビューションに関連付けるには、米国東部 (バージニア北部)
CloudFront でビューワーとの通信に使用する最小の SSL/TLS プロトコル。 ビューワーとの通信を暗号化するために CloudFront が使用できる暗号。 セキュリティポリシーを選択するには、セキュリティポリシー に該当する値を指定します。以下の表は、各セキュリティポリシーで CloudFront が使用できるプロトコルと暗号化方式の一覧です。 ビューワーは、CloudFront との HTTPS 接続を確立するために、これらの暗号のうち少なくとも 1 つをサポートする必要があります。CloudFront は、ビューワーがサポートする暗号化方式から一覧順で暗号化方式を選択します。「OpenSSL、s2n、および RFC の暗号名」も参照してください。
TLS 1.0およびTLS 1.1はセキュリティ上、脆弱であると考えられており、多くのベンダが使用停止を進めている。Microsoftも同社のサービスやプロダクトにおいてTLS 1.0および1.1の使用停止を進めている。しかし、この作業は一度に進められているのではなく、サービスやプロダクトごとに個別に進められている。どのサービスでいつ利用できなくなるのか、まとまった情報は公開されていない。 Microsoftはこのほど「TLS 1.0 and 1.1 deprecation - Microsoft Tech Community - 1620264」において、同社のサービスおよびプロダクトにおけるTLS 1.0/1.1サポート廃止のタイムラインを簡単にまとめた情報を公開した。どのサービスがいつサポート廃止となるかを確認できる。 掲載されている主な情報は次のとおり。
Amazon CloudFront now supports TLSv1.3 for improved performance and security. Amazon CloudFront is a global content delivery network (CDN) that enables you to securely distribute content to viewers with low latency and high availability. Amazon CloudFront supports HTTPS using Transport Layer Security (TLS) to encrypt and secure communication between your viewer clients and CloudFront. TLSv1.3 is t
AWSチームのすずきです。 Amazon CloudFrontが TLSv1.3サポートのアナウンスがありました。 Announcement: Amazon CloudFront announces support for TLSv1.3 for viewer connections TLSv1.3をサポートするWebブラウザで、CloudFront を利用したサイトへの接続を行い、 CloudFront が TLSバージョン1.3サポートとなった事を確認する機会がありましたので、紹介させていただきます。 ブラウザ Google Chrome バージョン: 85.0.4183.83(Official Build)を利用しました。 SSL Labs SSL Labsを利用してブラウザのテストを行いました。 TLSv1.3サポートする事を確認しました。 検証サイト Developers.IO
When building inter-connected applications, developers frequently interact with TLS-enabled protocols like HTTPS. With recent emphasis on encrypted communications, I will cover the way in which the JDK evolves regarding protocols, algorithms, and changes, as well as some advanced diagnostics to better understand TLS connections like HTTPS. Most developers will not have to do this level of diagnosi
症状 クライアントとサーバーが TLS/SSL プロトコルを使用して接続を確立できない場合、TLS/SSL handshake の失敗が発生します。Apigee Edge でこのエラーが発生すると、クライアント アプリケーションは、「Service Unavailable」というメッセージとともに HTTP ステータス 503 を受け取ります。API 呼び出しで TLS/SSL handshake の失敗が発生すると、このエラーが表示されます。 エラー メッセージ HTTP/1.1 503 Service Unavailable 加えて、TLS/SSL handshake の失敗が発生すると、次のエラー メッセージが表示されることもあります。 Received fatal alert: handshake_failure 考えられる原因 TLS(Transport Layer Securi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く