はじめに ※本記事は2023/9/4時点の情報です。ご覧になっているタイミングによってはアップデートやドキュメントの変更があるかもしれません。 RDSがSSL/TLS接続に使用している認証局証明書である「rds-ca-2019」の有効期限（2024年8月23日）が1年を切り、RDSコンソール上に赤字や赤い丸が登場するようになりました。 既にいくつも更新に関する記事が上がっていますが、この記事では特に更新すべき証明書や、エンジン/バージョンによる再起動の要否に着目して記述したいと思います。 実際にデータベースを立ち上げて確認をしてみたので、そちらもご参考に！ 影響のある/ない接続の方式 早速ですが影響範囲の簡単な確認です。 証明書を使用しない接続 RDS Proxyを用いた接続 は今回の更新対象外です。特に対応しなくても、方式が変わらない限り接続ができなくなることは基本的にありません。 ただ
はじめに はじめまして、サイバートラストの坂田です。SSL サーバー証明書のサポートデスクでテクニカルサポートを主に担当しています。 このたび、さくらのナレッジに寄稿させていただくこととなりました。どうぞ、よろしくお願いいたします。 さて、今回は私がお客様からよく聞かれる、SSL/TLS (以降は、SSL だけに省略して記載します)に関するお話を以下の 2 本立てでご紹介します。 SHA-1 証明書の規制・影響の振り返りと最新動向 SSL 接続時によくあるセキュリティ警告・エラーとその対策 なお、SSL に関する基本的なお話は当社の坂本が寄稿している「改めて知ろう、SSLサーバー証明書とは？」シリーズをご一読ください。 第 1 部： SHA-1 証明書の規制・影響の振り返りと最新動向 SHA-1 証明書の規制の振り返り まず、SHA-1 証明書（署名アルゴリズムが SHA-1 の SSL
Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
1. SSL/TLSの基礎と最新動向 セキュリティキャンプ 2015 2015年8月12日 IIJ 大津 繁樹 更新版資料の置場 http://goo.gl/cX1M17 Github Repo: https://goo.gl/vRLzrj 2. 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト本部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当） • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ： http://d.hatena.ne.jp/jovi0608/ 3. はじめに • TLS(Transport Layer Security)の仕組みについて学んでいただき ます。 •
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
SSL 3.0 プロトコルには、通信の一部が第三者に解読可能な脆弱性が存在します。サーバ、クライアント間の通信において、SSL 3.0 を使用している場合、通信の一部が第三者に漏えいする可能性があります。 ただし、攻撃には複数の条件が必要で、例えば、中間者攻撃や、攻撃対象に大量の通信を発生させるなど一定の条件が必要になります。そのためただちに悪用可能な脆弱性ではありません。 サーバ管理者および利用者は対策の要否を検討し、必要に応じて後述の対策を実施してください。 図：脆弱性を悪用した攻撃のイメージ サーバもしくはクライアントのどちらか一方で、SSL 3.0 を無効化することで対策できます。 なお、SSL 3.0 を無効化することで次の影響を受ける可能性があります。 サーバ側で SSL 3.0 を無効にした場合 一部のクライアントから接続ができなくなる可能性があります。 クライアント側で S
JINS PC を使い始めました。普段はメガネをかけていないため、レンズに照明がうつり込むのが気になる、耳が痛い、と気になって気になってしかたがない yone です。効果があればよいのですが。 1. オレオレ認証局の活用 前回の記事で、オレオレ認証局 (プライベート認証局) の構築と、それを使ったウェブサーバ証明書の発行を紹介しました。記事の最後に、その他の証明書活用を紹介しましたが、今回はそのなかから「クライアント証明書」の事例を解説します。 2. クライアント証明書 一般公開しているウェブページではなく、特定の人だけに見せたいページを作る場合、Basic 認証を使うことが多いでしょう。ほぼ全てのブラウザが対応しており、広く使われています。 お手軽でよいのですが、盗聴・改竄に弱いという弱点があります。弱点を改善した Digest 認証というものがありますが、Basic 認証ほど普及してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
