サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Let's Encryptでこれまで長く使用されてきたIdentrust社発行のDST Root X3ルート証明書が、日本時間2021年9月30日23時1分15秒に期限切れになりました。十分時間を取って事前に移行計画や影響範囲、救える環境、救えない環境などアナウンスをしてきましたが、やはり、期限切れ以降、様々なサービスや製品で接続できないといった声が上がってきました。 特にOpenSSLに関しては、OpenSSL 1.0.2以前に影響があると9月13日に事前の注意喚起がOpenSSL公式ブログであったにもかかわらず、製品やサービスの奥底で使われていて気づかなかったのか、様々なOSや製品で古いものが組み込みで使われていたために影響が広かったように思います。 OpenSSLからの注意喚起の概要 2021年9月30日にLet's EncryptのDST Root X3ルート証明書の期限が切れるに
これは、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
tl;dr 驚くべきハックにより旧Androidも引き続き証明書エラーなくサイトを閲覧できそうです いよいよ5/4に標準の証明書チェーンが切り替わります 前回までのおさらいAndroid7.1以前でLet's Encrypt証明書のサイトが見られなくなる Let's Encryptの証明書切替周りその後 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしています。現在は、IdenTrustのルート証明書(DST Root CA X3)が使われています。 正確に言うと、ISRGは新しい認証局なのでそのルート証明書の普及率も当然低く、中間証明書はIdenTrustのルート証明書でクロスサインされており、それが標準で使われています。標準がDSTになっているだけで、ISRGのルート証明書のチェーンの証明書も指定すれば今で
crt.sh Certificate Search Enter an Identity (Domain Name, Organization Name,etc), aCertificate Fingerprint (SHA-1 or SHA-256) or a crt.sh ID: Advanced... © Sectigo Limited 2015-2025. All rights reserved.
Let’s Encryptのルート証明書とは？ Let's Encryptを運営している非営利団体のISRG（InternetSecurity Research Group）は2014年に設立された新しい認証局です。もちろん、当時は設立されたばかりなのでISRGのルート証明書は様々な端末にインストールされていませんでした。そのため、別の認証局であるIden Trustが2000年に発行した「DST Root X3」というルート証明書を利用し、クロス署名された中間CA証明書を現在も利用しています。 この間（2014年～現在まで）ISRGは何をしていたかというと、各OS（Windows、Mac、Android等）やMozilla（Firefoxブラウザの開発元）に対して、自社のルート証明書である「ISRG Root X1」をインストールしてもらうようにお願いをして、徐々にインストール済み端末
追記: その後の動きについて書きました → Let's Encryptの証明書切替周りその後 このサイトはLet's Encryptで証明書発行しているのでタイトルの件が気になったのだが、どうもあまり話題になっていない。恥ずかしながらSSL周り詳しいわけじゃないので、誤っているかも知れない。識者の意見を求む。 Let's Encryptが使われているサイトがAndroid7.1以前のバージョンで今年の9月29日以降見られなくなる可能性がある 延命策は用意されそうだが、それも来年の9月29日まで Let's Encryptのルート証明書切り替え計画に起因している Let's Encryptのルート証明書の変更 Let's Encryptはルート証明書を自身(ISRG)の認証局のルート証明書(ISRG Root X1)に切り替えようとしている。現在は、IdenTrustのルート証明書(DST
2020年03月04日掲載 障 害 発 生 の お 知 ら せ さくらインターネット株式会社 平素よりさくらインターネットをご利用いただき、誠にありがとうございます。 さくらのレンタルサーバ/マネージドサーバの無料SSL機能において認証局による 一部SSL証明書の失効処理が行われました。該当証明書の再発行を行っておりま すが、数量が多く時間を要する見込みです。詳細は以下の情報をご確認ください。 ＜ 記 ＞ 発生日時 : 2020年03月04日09時00分 - 2020年03月04日11時00分 影響範囲 : さくらのレンタルサーバ/マネージドサーバの無料SSL機能の一部 障害内容 : 認証局（Let's Encrypt）のSSL証明書発行プログラムのバグに より認証が不十分なSSL証明書が発行されていたことが判明しま した。認証局による失効処理が2020年3月4日9時頃より開始され ており
BRIGHT VIE Advent Calendar 2017 - Qiita の7日目です！ アドベントカレンダーも1週間目！ 今のところ走り続けれていますが、執筆が続いているためそろそろバテてきており... 今日は軽めな感じで。。。 はじめに 弊社でもパブリックな証明書やプライベート証明書など様々なタイプのSSL証明書を利用しているのですが、 組織としてきちんと動き出す以前は、SSLの証明書チェックが無かったり、 運用中にもかかわらず有効期限切らせてしまったりといったことが結構起きている状況でした;; 最近では、Let's Encryptなども利用しており、cronで更新処理を組み込んだりしてりおけば安心ですが、 念のため自動更新の場合でも正常に更新がされているのか、 手動の場合には更新し忘れがないかをチェックしたいといった場合はあるかと思います。 簡易的なチェック方法 弊社で利用して
はじめに 背景と目的 元ネタは、@ozuma5119氏のスライド個人でEVSSL証明書が欲しい話でした。スライド36枚目から、オレオレEVSSL証明書1を作ってブラウザ(Firefox)に認識させようという試みが説明されているのですが、結局成功していませんでした。 そこでこの話に触発されて、 オレオレEVSSL証明書をブラウザ(Firefox)に認識させることはできるのか 件のスライドの説明よりもっと楽な方法はないか 件のスライドでうまく行かなかった理由は何か を調べた話になります。 前提 SSL/TLSの本当に基礎については、拙記事SSL/TLSの見落とされがちな「認証」という基本機能をご覧ください。その中でEVについても軽く触れています。 また、今回の話の全体像をつかむためには、冒頭で紹介したスライドを一読されることをお勧めします。 注意本記事の趣旨はあくまで、ブラウザがEVだと認
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
先日のエントリー 「TLSとSPDYの間でGoogleChromeがハマった脆弱性(CVE-2014-3166の解説)」で予告した通り、今回不正なSSL証明書を見破る Public Key Pinningの機能について解説します。 Public Key Pinning は2種類の方法があります。あらかじめブラウザーのソースコードに公開鍵情報を埋め込む Pre-loaded public key pinning と、サーバからHTTPヘッダでブラウザに公開鍵情報を通知するHTTP-based public key pinning (HPKP)の２つです。Chromeは既に両者の機能を実装済ですが、ちょうど近日リリースされる Firefox 32 の Stable バージョンから Pre-loaded public key pinning が実装されました。Firefox32リリース記念と
1. はじめに、Googleがハマったシリーズ第3弾。今度はChrome の脆弱性がテーマです。 先日(8月12日頃）突然GoogleChromeでSPDYの機能が一旦停止されました。CloudFareの人が気づいてspdy-devへのMLの問い合わせし、すぐGoogleのaglさんからの返事で計画的で一時的なものであることがわかりました。twitterやfacebookもSPDYが全て使えなくなり非常に驚いたのですが、直後にChrome の Stable/Beta/Dev チャンネルがアップデートされ、ほどなくして問題なくSPDYが使えるようになりました。 この理由は公式には明らかにされていませんが、Chromeのリリースアナウンスにヒントがありました。そこには、 HighCVE-2014-3166: Information disclosure in SPDY.Credi
先月、大手 CAの Comodoが外部からの攻撃によって、偽証明書を発行してしまうという事件が起こった。本記事では、この事件の問題点の整理、攻撃手法の詳細、改善策の状況などについてまとめたいと思う。 何が起こったのか？ Comodoは認証局(CA)を運用し、SSLで利用される公開鍵証明書の発行などを行っている大手プロバイダの一つ。security spaceの 2010年3月のマーケットシェア調査によると、9%程でシェア5位につけている。(ちなみに GeoTrust,GoDaddy, Verisignの上位3社で50%以上を占める、寡占業界である。) その Comodoが 3/23付けの自社ブログにおいて、登録局(RA)の一つが外部から侵入されて、不正なSSL証明書が発行されてしまったことを明らかにした。(侵入が起きたのは 3/15のこと。) SSL認証局が偽の証明書を発行、大手サイトに
GoogleやFirefoxによると、WoSignは不正な証明書を発行していたことが判明。別の認証局のStartComを買収していたことも隠して「ブラウザコミュニティをあざむこうと画策した」とされる。中国の認証局WoSignと傘下のStartComが不正な証明書を発行していたことが分かったとして、米MozillaやGoogle、AppleがそれぞれのWebブラウザで両社の証明書を信頼できない証明書として扱うと表明した。Googleは10月31日のブログで、Chrome 56（2017年1月にリリース予定）以降のバージョンではWoSignとStartComが10月21日以降に発行した証明書を信頼できる証明書として扱わないと表明した。 それより前に発効された証明書については当面の間、条件付きで信頼するが、そうした例外は両社の証明書を使っているWebサイトに対して信頼できる別の認証局への移行
この記事について Let's encryptは無料で使用できるSSLプラットフォームです。certbotコマンドを使って、簡単にSSL証明書の取得と更新ができます。 しかし、あまりに簡単で手軽すぎるためか、ネット上ではやや問題のある手順が紹介されているケースが見られました。私なりにベストと思われる手順をまとめておきますので、改善点があれば教えてください。DNSの設定、Webサーバのセットアップ、certbotのインストールは完了しているとします。またcertbotのコマンド名はcertbot-autoで、$PATHが通っていると想定します。 証明書の取得 以下のような補助スクリプトを準備します。
前回の記事、「Let's Encryptから無料・安全なSSL証明書を取得してNginxに設定するまで」で、Let's Encryptから無料のSSL証明書を取得する方法を紹介しました。 Let's Encryptは、2015/11/17現在ベータ運用中ではありますが、だからと言って発行されたSSL証明書に問題がある訳ではありません。 その証拠に、Let's Encryptから取得したSSLサーバ証明書をnginxに設定し、Qualys SSL Testで検査したところ、無事「A+」評価が獲得できました。 (※役に立つかわかりませんが、テスト結果の完全なスクリーンショットも置いておきます。サイズが大きいので注意 / 0.5M) ちょっと長いですが、設定の手順をご紹介します。 (どちらかというとQualys SSL TestでA+を取る設定についての一般的な話で、Let's Encryptの
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できるCookieの改変についてはSe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
