パスワードを忘れた? アカウント作成
14981577 story
暗号

Let's Encrypt、ルート証明書切り替えに向けて古いAndroidへの対策を呼びかけ 83

ストーリー by headless
対策 部門より
Let's Encryptがルート証明書の切り替えに向け、古いバージョンのAndroidへの対策をサイトオーナーとユーザーに呼びかけている(Let's Encryptのブログ記事The Registerの記事)。

5年前にLet's Encryptが立ち上げられた際にはIdenTrustのクロス署名を得たルート証明書「DST Root X3」を使用することで、メジャーなソフトウェアプラットフォームすべてで信頼される証明書をすぐに発行することが可能だったという。しかし、DST Root X3は2021年9月1日に失効する(ただし、実際に証明書を見ると有効期限は日本時間2021/9/30 23:01:15となっている)。他のCAからクロス署名を得た証明書を使い続けることはリスクが高いため、Let's Encryptでは既に独自のルート証明書「ISRG Root X1」を発行している。このルート証明書はメジャーなソフトウェアプラットフォームから信頼されているが、2016年以降更新されていないソフトウェアには信頼されない。Androidではバージョン7.1.1よりも古いバージョンが該当するとのこと。

Androidは更新されない古いバージョンが多数存在することで知られるが、Android Studioのデータによると9月時点でAndroid 7.1よりも古いバージョンのシェア合計は33.8%(StatCounterの10月分Androidバージョン別シェアデータでは18.87%)だったという。DST Root X3が失効するまでにAndroidの古いバージョンが使われなくなることは期待できないため、Let's Encryptでは早めに情報を提供することでサイトオーナーと古いバージョンのAndroidユーザーに事前の対策を促している。

ユーザーは使用しているAndroidのバージョンが5.0(Lollipop)以降であれば、Firefoxを使用することで証明書エラーの問題を解決できる。FirefoxはISRG Root X1を信頼しているため、AndroidバージョンにかかわらずLet's Encryptの証明書を使用するサイトで証明書エラーが表示されることはない。ただし、Android 4.4 KitKat以前のバージョンも2%前後のシェアがあり、現在使われているすべてのAndroidバージョンをカバーすることはできない。Googleが昨年Android 10にデザートの名前を付けないことを発表した際、Androidのアクティブデバイスが25億台に達したと述べていたので、5千万台前後が残されることになる。

また、Let's Encryptでは2021年1月11日にISDG Root X1移行に向けたAPI変更を計画しているが、オプションでDST Root X3を用いることも可能になるという。ホスティングプロバイダーを通じてLet's Encryptの証明書を利用している場合、すぐにISRG Root X1へ切り替えるか、DST Root X3を失効まで使い続けるかはホスティングプロバイダー次第となる。そのため、不明な点はホスティングプロバイダーに問い合わせる必要がある。

DST Root X3を使い続けることで、サイトオーナーは2021年9月1日まで証明書の問題を先送りできるが、長期的な解決にはならない。対策としては、古いバージョンのAndroidユーザーに対してFirefoxの使用を推奨するバナーを表示したり、HTTPにフォールバックしたりするほか、Let's Encryptの使用をやめて古いバージョンでも信頼されるCAに変更するといった対策が挙げられている。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2020年11月09日 0時06分 (#3920641)

    Android Studioのデータによると9月時点でAndroid 7.1よりも古いバージョンのシェア合計は33.8%

    とのことだが、自分のサイト(エンタメ系ブログ)のGoogleアナリティクスでは n = 627,669 で 9.68% しかなかった

    そもそも、Androidの割合が32.91%しかないので、全体(PCやiPhoneも含む全体を分母とした場合)からすると、僅か 3.18% だ。

    [ISRG Root X1 が利用可能な Android 7.1.1 以降の割合]

    分母: Android デバイス利用者のセッション
    期間: 2020-10-01 - 2020-10-31
    セッション数: 627,669
    セッション持続時間: 30分間 (最後のアクセスから30分以内の次ページアクセスは1セッションに含み新たなセッションとしない)
    11 : 0.41%
    10 : 56.33%
      9 : 20.15%
      8.1.0 : 0.93%
      8.0.0 : 12.19%
      7.1.2 : 0.31%
    合計 : 90.32%

    7.1.0 以下のAndroid : 9.68%(バージョンがばらけまくってて全部足すのが面倒なので全体から7.1.2以上を引いて計算した)
    分母 = Android デバイスが全体に占める割合: 32.91%

    影響: 32.91% * 9.68% = 3.18%

    Android利用者の割合を調べる上での注意として、ユーザーではなくセッション でデータを見る必要あり。
    (最近のiPhoneのSafariはGoogleアナリティクスのトラッキングCookieを勝手に定期的に消すプライバシー機能があるので、新しいユーザーと認識されてiPhoneのユーザーの割合が異常に高くなる)

    自分のサイトとAndroid Studioのデータで3倍もの違いがあるのは驚きであるが、サンプル数は十分にあるので「世界」と「日本」の違いが大きいと思われる。
    一応なんだかんだで、日本は世界3位のGDPの国なので、それなりにスマホ端末にお金をかけて買い替えているのかもしれない。
    また、恐らく、「世界」では日本と違って2年ごとに端末を買い替えないと実質損する制度があまり普及しておらず、古いAndroidの買い替えが進んでいなかったのではないだろうか。
    2021/9/30 まではまだ1年弱あり、3~4割は買い替えるだろうから、この3%というデータは更に少なくなって、2%とかそのへんまで落ちるであろう。

    とはいっても、2%というのは無視できる数値ではない。
    導入コストや人件費を無視して単純計算した場合、7.1.0 以下のAndroidに対応している証明書が年1000円で買えるので、年5万円以上稼いでいるサイトなら有料の証明書を買った方が得ということになる。

    ジャンルによって利用者の端末の傾向が違うかもしれないので、自分のサイトのアクセス解析をみてみるとよいだろう。

    • by Anonymous Coward

      Androidの割合が32.91%しかないので、全体(PCやiPhoneも含む全体を分母とした場合)からすると、僅か 3.18% だ。

      個人サイトだとどうでもいいと判断されますが
      ショッピングサイトですと
      コンバージョンも鑑みいくらの損失になるか
      という判断になりますので
      判断権限のある方の考えによっては
      僅かでも損失が出ることは許されない
      てかもっと緩くして稼げ
      ってことになりかねないかと
      もちろんそれによるデメリットやコストには耳を塞ぐ形で

      # 重要なのは感情だという管理職の方が多かったりするのはフィクションの世界だけじゃなかったり

      • by Anonymous Coward

        ショッピングサイトですと
        コンバージョンも鑑みいくらの損失になるか
        という判断になりますので

        を検討するまでもなく

        7.1.0 以下のAndroidに対応している証明書が年1000円で買えるので、年5万円以上稼いでいるサイトなら有料の証明書を買った方が得

        の方で終了な気がする

        1年ごとに証明書入れ替える人件費を考えても、Let's Encryptの更新スクリプトが正常に動作しているか監視(手動、もしくはそのためのスクリプトの作成)するコストも必要だし、沢山のサーバを管理しているサーバ屋さんとかでない限り有償証明書の方が優位なんじゃないかな。
        CertbotクライアントもPythonのバージョン等に依存するし大胆なアップデートを繰り返すなど安定している状況にはないから、1年後にも今のまま設定等一切弄らず動く保証も何もなく情報収集コストもかかる。

  • by Anonymous Coward on 2020年11月08日 19時34分 (#3920560)

    よいのでは?

    • androidって全機種でルート証明書インストール可能なのかな?

      昔オレオレ証明書を入れようとしてどうしても成功しなかった記憶がある
      Gingerbread/HoneycombかICSの頃の話だけど。

      親コメント
      • by Anonymous Coward on 2020年11月08日 20時12分 (#3920574)

        前回のストーリーで既出のやりとり。

        端末側の証明書を更新すれば? (#3868695) | Let's Encrypt証明書を使用しているWebサイト、Android 7.1以前の端末での閲覧に影響か | スラド [srad.jp]

        システムのルート証明書ストアとユーザのルート証明書ストアに分かれていて、後者はroot権限なくても自由にインストール可能。
        ただし、画面ロック「なし」「スワイプ」との両立ができないという訳のわからない仕様。あと起動時に毎回警告が出るようになる。
        現実的にはGoogle Play開発者サービス側でシステムの証明書を自動更新するしかないと思うし、そうすべきだと思う。

        親コメント
        • by Anonymous Coward on 2020年11月08日 22時24分 (#3920626)

          ただし、画面ロック「なし」「スワイプ」との両立ができないという訳のわからない仕様。あと起動時に毎回警告が出るようになる。

          ルート証明書をインストールすれば、例えば、自宅内に全ての通信を中継するプロキシサーバ的なものをたてて、大手メールサービスのサーバになりしまして本物と中継することができてしまう。
          つまりは、息子・娘・配偶者のメール等のやり取りを監視することだってできてしまうのだよ。

          ロック無しのスマホだったら勝手に第三者がX.509ルート証明書をインストールできてしまうでしょ。
          だから、ロック無しのスマホにはそもそも独自のルート証明書をインストールできないようにするのが正解。
          警告が出るようにするのも、万が一PINの盗み見などで不正にルート証明書を第三者がインストールした場合に知ることができるために必要。

          この必要性が理解できないような人は、ルート証明書のインストールなんて危険なことはしない方が良い。
          偽サイトから偽のルート証明書をインストールしかねない。

          親コメント
          • by Anonymous Coward on 2020年11月09日 10時57分 (#3920729)

            ロック無しのスマホだったら勝手に第三者がX.509ルート証明書をインストールできてしまうでしょ。

            ↑これは真

            だから、ロック無しのスマホにはそもそも独自のルート証明書をインストールできないようにするのが正解。

            ↑これは偽

            この叙述トリックをモデレータが見破れずに #3920626 が (スコア:4, 参考になる) となっているのが悲しい。
            ロック無しのスマホに独自のルート証明書をインストールできないようにしたところで、第三者は勝手にロックを設定して独自のルート証明書をインストールできてしまうので、そもそも対策になっていない
            (厳密には、次回ロックされた場合に本来の利用者が解除できず被害の拡大を防げることもあるけど、それについても抜け道があったりするので割愛)
            第三者が勝手にルート証明書を閲覧したりアンインストールしてしまうことが防げるだけ。そこには何の意味もない。

            親コメント
          • by Anonymous Coward on 2020年11月09日 8時21分 (#3920694)

            ロック無しのスマホだったら勝手に第三者がX.509ルート証明書をインストールできてしまうでしょ。

            うわぁ……問題を理解してない教科書テンプレ回答のマジレスきちゃった。
            継続的な侵害防止のため警告表示は妥当だけど、画面ロックとkeychainが連動する必要は一切ない。
            この仕様はAndroidが画面ロックのPINをkeychainの暗号化に使い回してる設計の悪さ故の制約。
            LinuxもMac OSもログインパスワードとkeychainのパスワードは別に設定できる。
            そもそもkeychainの暗号化は認証情報の漏洩による侵害の拡大を防ぐためのものなので、秘密鍵を含まないルート証明書は暗号化して保存する必要すらない。
            セキュリティのためと偽って必要のない不便を強いるのは害悪でしかない。

            親コメント
        • by Anonymous Coward

          VPNでも同様の挙動になるので、エンプラ向け機能を使うときは画面ロック「なし」「スワイプ」が使えないみたい。

  • by Anonymous Coward on 2020年11月08日 20時00分 (#3920569)

    ので、うちではLet's Encryptを使うのやめました。
    予算だけ確保して、より具体的な日程が分かってから、
    その日程に合わせてもうちょっとマシな証明書を買う予定。

    • by Anonymous Coward

      有効期限1年の証明書しか使えなくなったので、自動更新できないCAは使う気になれない。

      • そもそも、サーバというのは、リソースやディスクI/Oの急変だの急に吐かれたエラーログやら数秒に1回のサービス動作チェックへの応答がないときの対応やらその他で24時間体制で監視・対応するもの
        (それができないなら、できる業者にroot持たせた方が良い)
        1年に1回の更新を手動でやったとして、サーバ1台管理する手間に加わる割合なんて微々たるものでしょ
        手動の場合は、
        ・11ヵ月に1回の更新タスクを職場の共有スケジューラー等にスケジュール
        ・普通にサーバ証明書をチェックして Not After まで1か月切ったら警告する管理スクリプトの作成
        などの対応をして、1年に1回手動で更新すればいい

        Let's Encrypt で自動更新している人、本当に安全な方法で出来てる?
        公式サイトは勿論、あちこちの情報サイト見ても、毎秒数百以上のアクセスがあるようなWebサーバで安全に更新できるようなスクリプトは全く見かけない

        certbot certonly --webroot -w /home/www/www.example.com --noninteractive --post-hook "systemctl reload httpd.service" のような方法での解説、よく見かけるけど、
        まずユーザーの端末の時計が数分狂っていたりタイムゾーンがずれていたりなんてこと(特に海外では)はよくあることなので Not Before 前の証明書扱いでエラーになるわけで
        新たに取得した証明書は2~3日は寝かした方が良い
        ユーザーの端末の時刻やタイムゾーン設定が絶対に合っている仮定しても、FirefoxだとOCSPが反映される数分間はエラー扱いになることが多いので、最低でも10分は待たないと駄目

        そして、毎秒数百以上アクセスがあるようなWebサーバーだと再起動で少しでも負荷があがると直後の負荷が心配だから何かあったとき有人で対応できるときじゃないとリロードなんてすべきではない。
        極端な話、スマートニュースやYahoo!ニューストップにサイトが掲載されたなどで急激なトラフィックが生じて負荷がぎりぎりのときにreload走ったら困るでしょ。
        AWSのAuto Scalingだって急激なトラフィック急増には対応できないってのに
        ってことで、サーバーのリロードは負荷状態が問題ないことを確かめたタイミング、かつ深夜などの影響が少ない時間帯、かつ有人で即座に人が対応できる状態でやるべき

        負荷状況といっても、データベース負荷とか現在のコネクション数とか帯域とか色々見るところあるからなかなか自動化は難しい
        Webサーバーのレスポンスが1~2秒遅延しただけで、いっきにDBサーバにまとまってSQLクエリが流れて、そこで過負荷でトラブルなんてこともよくある
        Webサーバーのreloadっていうのは結構危険な作業だったりする

        ってことで色々考えると、管理しているサーバの台数が数十やそこらだったら、変に自動化せずに手動でやったほうがトータルで良いと思われる

        それでも、どうしても自動化したいならば、証明書の更新を自動化できるとこなんてCAなんて山のようにある
        国内だと https://www.fujissl.jp/fujissl-go/ [fujissl.jp] とか
        日本は古い体制のところが多いけど、海外含めればむしろ大手で自動化に対応できていないとこの方が少ないぐらい

        親コメント
        • by Anonymous Coward on 2020年11月09日 1時32分 (#3920660)

          などの対応をして、1年に1回手動で更新すればいい

          そうは言うけど、こういう話もあって、いつか有効期限1年の証明書も出なくなるかもしれない。

          何度も短縮し過ぎ?!SSL証明書の有効期間がどんどん短くなる理由とは? [sakura.ad.jp]

          現在、CA/Browser フォーラムでは397日から9ヶ月→6ヶ月→90日と段階的に有効期間を短縮していく施策が検討されており、数年のうちに実施される可能性があります。

          なお、自分の場合、今のところ1年に1回手動で更新している。会社指定のCAを使わないといけないので、自動化できるかどうかはそこ次第。

          親コメント
        • by Anonymous Coward on 2020年11月08日 22時15分 (#3920623)

          FirefoxだとOCSPが反映される数分間はエラー扱いになることが多いので、最低でも10分は待たないと駄目

          ググったら、
          https://help.sakura.ad.jp/360000143762/ [sakura.ad.jp]

          JPRS社のSSL証明書は、OCSPレスポンダにSSL証明書の情報が登録されるまでに最大30分程度かかる場合があります。
          このため、SSL証明書が発行された直後はOCSPによる失効情報の検証ができず、有効なSSL証明書として認識されないため、サイト閲覧時にエラーが出る可能性があります。
          OCSPに対応しているブラウザをご利用の場合、SSL証明書発行直後は正常にサイトが閲覧できない可能性があります。
          また、ブラウザのキャッシュにより1度アクセスすると最大6時間程度アクセスできない可能性があります。

          だそうだが、Let's Encryptの情報は出てこなかった。
          Let's Encryptだと最大何分?

          親コメント
          • by Anonymous Coward on 2020年11月09日 1時01分 (#3920655)

            仮に CDN でキャッシュ機能があるとしてもサーバーに設定して証明書を使い始めるまでは OCSP リクエストがされることはないので、レスポンスがキャッシュされてしまうことはないと思います。
            Let's Encrypt は、証明書を発行してから OCSP データベースに反映するまでのタイムラグもほぼゼロじゃないでしょうか。発行後すぐにレスポンスが返ってきそうです。

            新規発行でも OCSPへの反映に 30 分もかかるのは遅くないですか? CRL と中途半端に統合していてバッチ的に処理がなされているのでは?

            親コメント
        • by Anonymous Coward

          場末のショボいレンタル web サーバを手動更新してるけど、そんな大規模な人気サイトじゃないから、気にせず reload しちゃってるわw
          というか、たぶん永久にそうならないけど、人気出たら CDN に肩代わりしてもらおうと思ってました。

          負荷が高いサーバだと、考えることがたくさんあるのですね。
          ところで、 CDN を使えば、オリジンサーバにはそこまで心配しないでもいいような気がしますが、別に考慮しなくちゃいけないこと出てきたりするのでしょうか。

        • by Anonymous Coward

          無料なところはともかく、有料のSSL証明書発行してるところは、
          顧客のWebサイトの証明書を監視して、期限が近づくと警告するサービスをやればいのに

          2か月前でメール警告、1か月前で再度メール警告、2週間前にメール&電話&手紙の両方で警告、みたいな

          • by Anonymous Coward
            電話はさておき、メールはやってるんじゃないかと思うけど。てか、Let's Encryptですら何回かくるし。
      • by Anonymous Coward

        Let's Encrypt以外で自動更新できるCAのおすすめありますか?
        # ローバラかませてると対応難しいですが
        # 全部CDN任せにしちゃうのが簡単そう

      • by Anonymous Coward

        ドメイン証明のみなら、自動更新で可能でも、
        組織の実在証明とか、EV SSL証明が必要な金融業界や、大手通販サイトでは、
        自動更新できないCAが必要になるのでは?

    • by Anonymous Coward
      必要ならユーザーも積極的に対応するだろうけど、
      ニュースサイトとかそういうのだと、見れるところに流れていくだろうし、
      ゲームなら古いAndroid切れる絶好の機会だったり?(有料コンテンツ利用率は低そうだし)
      どういうユーザーかとユーザーとの関係にもよるのでしょうね。
  • 良い機会 (スコア:0, すばらしい洞察)

    by Anonymous Coward on 2020年11月08日 20時27分 (#3920577)

    Android 7.1よりも古いバージョンなんて
    ネットに繋がっている事自体が害悪ですので
    Let's Encryptだけでなくむしろ
    全ての証明書で同様の事態になったほうがいいですね

    証明書だけ対応させる裏技なんてのももってのほか

    買い替えかROM焼きできっちりセキュアに使う義務を
    ユーザー、キャリア、ベンダ全てに課してほしいものです

    # そして「あなたの端末は危険」詐欺が大賑わいに

    • by Anonymous Coward

      根本的に見直すと言うなら、階層型の認証基盤の考え方が古い。
      古いと言うか、人類の歴史の中で階層型の信頼関係なんてものがうまく機能したことがあるとも思えん。

      • by nekopon (1483) on 2020年11月09日 9時27分 (#3920711) 日記
        Zimmermann 先生どーもこんちは
        親コメント
      • by Anonymous Coward

        根本的に見直すと言うなら

        というか
        SSL3.0やTLS1.0やTLS1.1のときと同様に
        切り捨て前提でいいんじゃないかと

        問題は世間の情報取り上げ情況なので
        世間への啓蒙努力をもっと頑張ろうで十分かと

    • by Anonymous Coward

      古いOSが害悪だとか言ってる自称中級者は結構いるが、
      OSが古いことによって第三者に迷惑かけることはほとんどない。

      ってかボットネットを構成するのは管理の甘いサーバ。
      あと今やOSのセキュリティホール狙うのはハードルが高いので
      普通はミドルウェアを狙う。

      • Re:良い機会 (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2020年11月08日 22時57分 (#3920629)

        古いOSが害悪だとか言ってる自称中級者は結構いるが、
        OSが古いことによって第三者に迷惑かけることはほとんどない。

        ってかボットネットを構成するのは管理の甘いサーバ。
        あと今やOSのセキュリティホール狙うのはハードルが高いので
        普通はミドルウェアを狙う。

        この手の主張をする阿呆が未だに絶えないのは確かに問題だな

        親コメント
        • by Anonymous Coward

          月例パッチが数か月どころか下手したら年単位にあたっていないAndroidは山のようにある
          世界でいえば下手したらAndroidの半数以上がまともにパッチあてされていないんじゃないかな
          そんな脆弱なAndroidにみんなは銀行アプリ(世界では通帳無しが常識だからアプリがないと明細すらまともに見れない)も何もかも入れて使っているけど大きな問題は起きていない

          世の中に何億と脆弱なAndroid端末があるのに、日常でAndroidスマホのrootが乗っ取られて訳の分からないアプリがインストールされたとか何もしていないのにロック画面に広告が表示されるようになったとか、そういう被害に遭う人は居ない訳ではないが極わずか

          デジタルガジェットのセキュリティにうるさい人でも、リアルでのセキュリティはガバガバだったりするよね
          在宅時にピッキングで侵入してちょっとナイフ突き付けて左手の指でも折って脅せばパスワードマネージャーのマスターパスワードすらしゃべりそう(笑)
          日本でもそういう手口でビットコイン強盗が既に行われているのだよ

    • by Anonymous Coward

      古いスマホをwifi運用して、ベッドや風呂で使ったりしてる人は多いのでは?
      寝落ちしてバッテリ干上がっても、wifi運用のサブ端末なら安心

  • by Anonymous Coward on 2020年11月08日 20時54分 (#3920587)

    サイト証明書のチェックって
    ブラウザのお仕事かと思っていましたが
    OSのお仕事だったんでしょうか?

    ストアのGoogle chromeの自動アップデートで古いAndroidでも
    サイト証明書のチェックは可能かと思いましたが
    Google chromeのサポートが
    Android 7.1以下をサポートしないってことなんでしょうか?
    FirefoxはAndroid5.0でも問題でないみたいですし

    それともAndroid Webviewが更新されないために
    Android Webviewを利用するアプリで
    Let's Encrypt証明書のサイトへの接続エラーが出ますよ
    ということなのでしょうか?
    それならお店アプリで問題がという話で頷けます

    Android Webviewの更新状況次第で
    接続エラーが出るアプリが出るよ
    ということでいいのかな?

    • by Anonymous Coward on 2020年11月08日 21時11分 (#3920598)

      問題になるのは、標準ブラウザ・Android Webviewを使ったブラウザアプリ・OSのストアを使っているGoogle Chrome だけ。

      Firefoxは独自の証明書ストアを使っているので全く問題ない。

      といっても、ストアまで独自で持っているのはFirefoxぐらいだから、Firefox以外の全ブラウザに影響するといえる。

      親コメント
    • by Anonymous Coward on 2020年11月09日 0時40分 (#3920649)

      ブラウザの作りによる
      基本的に最近のOSはSSL/証明書関連のAPIが整備されており、それ使えばOSまかせに出来る

      FirefoxはOSに頼らずに自前でやる

      親コメント
    • by Anonymous Coward

      サイト証明書をチェックするのはブラウザのお仕事。
      サイト証明書のチェックにはルート証明書が必要。
      ルート証明書の管理・更新は基本的にOSの仕事。

      • by Anonymous Coward

        >ルート証明書の管理・更新は基本的にOSの仕事。
        現在の主流はそうなんですが、本来はOSの仕事ではないです
        あくまでもHTTPSを必要とするシステムが行うべきものです

        • by Anonymous Coward on 2020年11月09日 2時52分 (#3920670)

          そんなことを言い出したらスマホのAPIの9割は「OSの仕事」ではない
          つまりOSの仕事という言葉の意味がスマホとパソコンでは全く異なる

          親コメント
          • by misz (9022) on 2020年11月09日 12時47分 (#3920761)
            PCでもWindowsは「インターネット オプション」の「コンテンツ」の中に「証明書」の設定があり、Chromeから証明書設定画面に行くと同じ設定画面になるので、証明書管理が「OSの仕事」になっているような気がします。
            親コメント
        • by Anonymous Coward

          とはいってもHTTPSを使うものが増えた今となっては、個別にルート証明書を管理するのがいいやり方だとは思えないな

    • by Anonymous Coward

      サイト証明書が信頼できるかどうかの確認には最終的にルート証明書が必要。

      > 他のCAからクロス署名を得た証明書を使い続けることはリスクが高い

      となると新たなルート証明書の取得を自動で行うのはなりすましの可能性を排除できないので
      自力で信頼できる証明書を入手して手動でインストールするか、OSに最初から組み込まれているルート証明書を使うしかない。

      「どうやって信頼できる形でルート証明書の更新を行うか」は古くからの問題で、完全な解決策と言えるものはないみたい

  • by Anonymous Coward on 2020年11月08日 22時12分 (#3920622)

    https://srad.jp/story/20/08/11/0411203/ [srad.jp]
    公式に告知されたってだけで話自体はとくに新しいものじゃないよね?

    • by Anonymous Coward

      ていうかほとんど同じ議論をボケ老人のように繰り返していてさすが老人会…ってなった

      • 昔は、スラドをインターネット老人会扱いするのはただの自虐ネタだったんだけど、
        今では本当にインターネット老人会になっているので笑えなくなっている。

        IT系の職場にいるなら新入社員にでも聞いてみると良い。
        「スラドってサイト知ってる?」って

        数十人新入社員居ても誰一人知らないなんて状況だろうな。

        スラド・はてブ・GIGAZINEあたりは本当に老人向けサイトなのが実情なので、それらのサイトを見ている人は注意した方がいい。
        そういったサイトばっかり見ていると、若い人の話題についていけなくなる。

typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...