だめだ、ネットワークの変更、ブラウザの再起動、システムの再起動も試してみたけど ConoHa ちゃんの証明書エラーが直らない。
> サービスの状況につきましては、コントロールパネル内のメンテナンス情報・障害情報をご確認ください。
コントロールパネルにログインできないんだよな
おまかんなのかどうかを検証しないといけない、ノートパソコンでログインできるかやってみるか
【急募】 ConoHa コントロールパネルにログインできる?
うわ、ノートパソコンからだとログインできる…… おまかんの可能性が高い…… なんで？ キャッシュとかシステム再起動時に全部死ぬようになってるんだけど。明示的に全部削除してみるか……
昨日 Chrome 更新したんだけど、もしかして Chrome バグってませんか
アクセスできる環境で見る証明書情報と指紋も完全に一致してるのに、この環境でだけ証明書エラーが出る
よく分かってないんだけど、証明書が正しいのは指紋で確認できていて、特定の環境でだけ証明書の検証エラーになることってあるんすかね。
サブドメインでだけ、死ぬ的な？
support.conoha.jp はつながる、manage.conoha.jp はつながらない。なぜ？ 名前解決の結果が違うのか
うちの環境で唯一アクセスできる Chromebook、こういうときに unk というか、ローカルに nslookup も dig もないから名前解決の結果が分からん。でも、キャッシュ期限が切れたあとにもう一度 dig しても結果変わらんので、たぶん問題ない、気がする。
ルート証明書の構成が違うのかと思ったけど、それだと *.conoha.jp に対して使用できる証明書において、conoha.jp と support.conoha.jp で正しく使えて、manage.conoha.jp で証明書エラーになる理由が説明できない。
証明書のへんなキャッシュが残ってるのかと考えたけど、証明書は指紋が一致していることで正しいを確認しているので、そこが問題ではない。
実は *.conoha.jp の証明書は manage.conoha.jp には使えないのでは？ ワイルドカード証明書について知識がないんだよね。
いや、仮にそうだったとして、それを VPS ホスティング事業者がやらかすとは思えないんだよな……
Firefox: アクセスできる
Chrome シークレットモード: アクセスできる
結論: Google Chrome のバグ
要考慮: 拡張機能の影響（テストのため、Advanced Font Config 以外の拡張機能・アプリはすべて無効化済）
証明書周りの不具合ダメだよ
アクセスできるはずのサイトにアクセスできないのはまだマシだけど、証明書の設定が不適切だったり攻撃を受けたりしてアクセスできてはいけないサイトに、それを検知できずにアクセスできてしまったりしたら最悪。何を信じればいいのか……
Chrome の設定をすべてふっとばすボタンを試したけどダメ。次の Chrome アップデートでしれっと直ってそうな案件だなあ……
2 月中に ConoHa サーバー移行間に合わなかったらどうしてくれるとさえ思い始めた。
% curl https://manage.conoha.jp/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
これ Chrome の問題じゃねーわ
システムだわ
え？ じゃあなんで Chrome のプライベートモードでアクセス「できちゃう」の？ そっちのほうが異常動作じゃんこれ
% sudo pacman -Qs openssl
local/openssl 1.1.1.d-2
The Open Source toolkit for Secure Sockets Layer and Transport Layer
Security
local/openssl-1.0 1.0.2.u-1
The Open Source toolkit for Secure Sockets Layer and Transport Layer
Security
これが問題ではないはず、ルート証明書ってどうやってシステムにインストールしてるんだろう
> デフォルトのインターネット SSL 証明書のトラストチェーンは ca-certificates パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: ca-certificates-cacert[リンク切れ: パッケージが存在しません], ca-certificates-mozilla) に依存しています。
ConoHa のワイルドカード証明書を提供している証明書発行機関の証明書は `ca-certificates-mozilla` が独自に認証してる気がする。それがインストールされてる環境だと証明書検証エラーが出ない。
@yakitama たびたびですみません。Conohaさんのワイルドカード証明書の検証にはまずGlobalSign RSA DV SSL CA 2018が必要なようです。support.conoha.jpからはワイルドカード証明書と一緒にこの証明書が提示されるのですが、manage.conoha.jpからは提示されません。なので、manage.conoha.jpはGlobalSign RSA DV SSL CA 2018を信用しているブラウザからは閲覧できて（きっとca-certificates-mozillaには含まれてそう）、そうでないブラウザからは閲覧できないのだと思います。
GlobalSign RSA DV SSL CA 2018の検証にはGlobalSign Root CA - R3が必要で、こちらはだいたいのブラウザが信用してるように思います。
https://gist.github.com/zunda/0a61081a4be903b4bb6f74b55d100d44
@zundan ありがとうございます、いまいちというか私も証明書の検証のチェインみたいなやつについて理解が浅く、たぶん適当なこと書いたので訂正いただけたのかなと思っております。自宅に帰ってみないと ca-cert.... の件は確認できないので、もうちょっとだけ調べてみようと思います。