Let's EncryptのルートCA期限切れで OpenSSL 1.0.2が思わぬ事故を起こす件
これは、Let's Encryptを支えるこの二人のルートCAと OpenSSLの物語である。 DST Root CA X3 (2000-2021) ISRG Root X1 (2015-2035) 〜2021年1月〜 ISRG Root X1「いままで一緒にやってきたDST Root CA X3さんの寿命が間近・・・このままだと僕を信頼してくれていないベテランの（具体的にいうと2016年くらいまでの）古いクライアントたちは Let's Encryptさんを信用してくれなくなっちゃう・・・どうしよう」 DST Root CA X3「どれ、わしが死ぬ前に(有効期限が切れる前に)お前が信頼に値する旨を一筆書いて残せばいいじゃろう。サラサラ」 Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3 Validity Not Bef
転送データの暗号化 | Documentation | Google Cloud
フィードバックを送信 転送データの暗号化 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 これは Google が暗号化によってどのようにデータを保護しているかに関する 3 番目のホワイトペーパーです。このホワイトペーパーでは、Google Cloud と Google Workspace での転送データの暗号化について詳しく説明します。 Google ではすべての Google プロダクトで、顧客データを高度に保護するとともに、セキュリティ保護の方式についても可能な限り透明性を確保するよう努めています。 このコンテンツの最終更新日は 2022 年 9 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティ ポリシーとシステムは変更される場合があります。 CIO レベルの概要 Google では転送データの信頼
RFC 2818 - HTTP Over TLS 日本語訳
RFC 2818 - HTTP Over TLS 日本語訳 原文URL : https://datatracker.ietf.org/doc/html/rfc2818 タイトル : RFC 2818 - HTTPオーバーTLS 翻訳編集 : 自動生成 [要約] RFC 2818は、HTTP Over TLS（HTTPS）の仕様を定義しており、セキュアな通信を提供するために設計されています。このRFCの目的は、TLSを使用してHTTP通信を暗号化し、認証することで、データの機密性と信頼性を確保することです。 Network Working Group E. Rescorla Request for Comments: 2818 RTFM, Inc. Category: Informational May 2000
HTTP Over TLS
English HTTP オーバー TLS (HTTP Over TLS) このメモの位置付け このメモは、インターネットコミュニティに情報提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布には制限はありません。 著作権表記 Copyright (C) The Internet Society (2000). All Rights Reserved. 要旨 このメモは、「インターネット越しの HTTP コネクションをセキュアにするための TLS の使い方」を記述します。現在の実践は、HTTP オーバー SSL（TLS の前身）とし、異なるサーバーポートの利用によって、セキュアにされたトラフィックをセキュアでないトラフィックと区別するものです。本書は、その実践を TLS を使って文書化します。併読文書は、通常の HTTP と同一のポート上で H
Chromeがコモンネームの設定を非推奨化、そのエラー対策としての自己署名証明書のCSRの作り方
ニュースソース：TEXT/PLAIN 以下は 2017年3月10日に公開されたThe Latest on Certification Authority Authorizationを要約したものです。 自己署名証明書を利用しているサイトにChromeでhttpsアクセスした場合、「Your connection is not private」のエラーが表示されることがあります。 原因は証明書のSubjectAltName（SAN）が正しく設定されていないことです。 1997年に成立したX.509v3は、証明書がドメイン名とのバインディングを示す方法として、SubjectAltName（SAN）にDNS名またはIPアドレスを設定する方法、または証明書のsubjectにコモンネーム（CommonName）属性を設定する方法を定めました。 問題は、コモンネームには不明確性があり、そのサポートは、
イマドキの証明書は全部マルチドメイン証明書 - Qiita
はじめに マルチドメイン証明書とワイルドカード証明書も、複数のドメインを1枚の証明書でSSL/TLS化できるということは同じ。ここのまとめはよくまとまっている。 https://www.bestssl.net/faq/hikaku-wild-sans/ このまとめに加えて、いくつか最近の事情について補足をした方がよさそうなので、以下に記載。 マルチドメイン証明書とは？ 証明書には、CN(Common Name)という必須項目がある。例えば、ブラウザでのURL入力時にhttps://www.example.org/index.html にアクセスする際には、FQDN(www.example.org)がCNフィールドに設定されているFQDNと一致している証明書が使われていた（過去形にした理由は、後述を参照）。 しかし、CNというフィールドは１つのFQDNしか登録できない。 www.exampl
Let’s Encrypt証明書発行を「acme.sh」で発行する (ワイルドカード） | ex1-lab
acme.shで無料SSL証明書を発行する CentOS 6系のサーバーでPythonのバージョンが古く、最新のcertbot を使えなかったのでシェルスクリプトで動作する「acme.sh」でワイルドカード形式の無償SSL証明書を発行しました acme.shをインストール acme.shをダウンロードしてインストールします。インストールは簡単にcurlでダウンロードしてシェルを実行すればインストールできます $ cd /usr/local/src $ curl https://get.acme.sh | sh 一度ステージング環境で実行します。ワイルドカード証明書を発行するのでDNSにTXTレコードの登録が必要ですので、その必要な値が表示されます ステージングで一度実行 .acme.sh/acme.sh --test --dns --yes-I-know-dns-manual-mode-e
理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
さくらのサポート情報
カスタマーセンターからのお知らせ 2019-04-26 08:45:57 UTC2019年ゴールデンウィーク お問い合わせ窓口の営業・各種お手続きについて 2019-04-26 08:46:25 UTC5月1日よりJPドメインでのアクセスができなくなったお客様へ 2019-04-26 08:45:57 UTCさくらインターネットを騙る「なりすまし・フィッシングメール」にご注意ください 2019-04-26 08:45:57 UTC3月18日 破産者の住所・氏名を公開するサイトに関する問い合わせについて 2019-04-26 08:45:57 UTC2019年1月以降、急にメールの送受信ができなくなったお客様へ 2019-04-26 08:45:57 UTCFreeBSDのアップデートに伴う変更点 (2019/4/18 更新) カスタマーセンターからのお知らせ一覧へ メンテナンス・障害情報
迫るSHA-1の廃止、SHA256への移行～各ベンダーが利用期限見直しの動き～
サイトの安全性を担保するために電子署名を用いたSSLを現在では、数多くのWebサイトが利用していると言われています。しかし、その暗号アルゴリズムが破られると通信の安全は保障できなくなり、なりすましやフィッシングに悪用されることが予測されます。 かねてからSHA-1証明書からSHA256証明書への移行は2016年12月31日までが期限と言われていましたが、ここに来てその期限を2016年中頃に前倒しする動きも出てきています。SHA256への移行の背景を改めて説明するとともに、各ブラウザベンダーの動きをご紹介します。 SHA-1証明書の問題と当初の移行期間とは SHA-1証明書は電子的な情報の信頼性を担保するために用いられます。本来、電子情報の信頼性を確保するために電子署名、秘密鍵、公開鍵を使った暗号基盤が利用されています。電子情報に対して電子署名をするためには、RSA暗号と言われる秘密鍵を使っ
Redirecting to ssl-config.mozilla.org...
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
TLS1.2への移行の必要性～TLS1.2への有効化が始まる現状の動きとは
今や多くのWebサーバ管理者が使用しているSSL/TLS。ネット犯罪などの改ざんを防止する方法として便利な反面、脆弱性の問題は次々と発覚し、その都度移行対応は必須の状態です。今、なぜTLS1.2への移行が必要なのか、SHA-2への移行の問題や既にTLS1.2を有効化した大手企業の現状などをご紹介します。 SSL3.0、TLS1.0、TLS1.1の脆弱性とそれに伴う情報漏えいリスク POODLE、Heartbleed、FREAKなど既に発見されている脆弱性の問題を振り返る ネット通販で何かを購入する時はクレジットカードを使う。10年前はそれを「危険」と感じていた人が多かったにも関わらず、今やネット通販の市場は拡大するばかりで購入者は増えるばかり。その人気を支えているのがSSL/TLSの暗号化通信。送信元のIDやパスワード、住所やクレジットカード番号を暗号化し、第三者がそのデータを閲覧出来ない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Minimum TLS version for google cloud standard app engine projects
【対処法】Let's EncryptのルートCA証明書が失効してWindows10でエラーが出てるときは？｜りょっぴ｜note
TLS 1.3 is now on by default for Google Cloud services | Google Cloud Blog
Google Online Security Blog: Broadening HSTS to secure more of the Web
TLS1.3 Study まとめ