タグ: GMO

Outlook で 証明書エラー表示を回避する blue.shared-server.net 編

我が社はオリジナルドメインを取得していますが、今日日SSL証明書を取得していません。未だにhttp://wagasha.com/です。https:ではなく。

さて、そんなオリジナルドメインで問題なのが、メールサーバーを設定すると証明書ではねられるケース「インターネット接続しているサ－バ－は、確認できないセキュリティ証明書を使用しています。対象のプリンシバル名が問違っています。」があります。

outlookはメールサーバーに kaisha.com としても通信するサーバーは *.blue.shared-server.net の為、通信は覗き見されて通名のインチキサイトに飛ばされていると解釈しているのです。実際その通りです。

ただ、そのことは承知なので何とか認めてもらおうと思います。

証明書のインストール 効果なかったけど

先のダイアログが出た際、「詳細」を確認し証明書インストールすればこれからは問題なくなるはずです。ですが、wagasha.com がと通信しているわけではないので、いつまでたってもダイアログは消えません。

通名ではなく本名で話をする 接続の実態の blue.shared-server.net に書き換える

この方法で毎度の証明書インストールがなくなります。

outlook – アカウントのプロパティ

アカウント設定 – サーバー名の設定で

受信メール:
ユーザー名 メールアドレスそのまま(onamae@kaisha.da.yo)
パスワード ○○○○
サーバー imap.blue.shared-server.net
ポート 993
暗号化方法 SSL/TLS
□ セキュリイで保護されたパスワード認証(SPA)でのログオンが必要 (はチェックしない)

送信メール:
サーバー mail.blue.shared-server.net 
ポート 465
暗号化方法 SSL/TLS
□ セキュリイで保護されたパスワード認証(SPA)でのログオンが必要 (はチェックしない)
☑送信(SMTP)サーバーには認証が必要です

こうすることでエイリアス通名での通信を避けることができ、うるさい証明書インストールもなくなりますよ。

根本的には証明書を取得すればいいだけ

なんだけど、通名排除ってことで。ネットの世界でも本人(サーバー)確認は必要なじだいなんだから。

2022/3/17 福島地震における通信障害状況まとめ

通信業者

NTT 固定電話の安定感が抜群。

通信に関しては NTTドコモが一番復旧は遅かった。

地震直後、NTTドコモの伝送経路故障というのがあるが、楽天には出ておらず、通信は何とかできる状態ではあったと思う。

どの通信業者も地震後5時間するとバッテリーが切れるので、地震後5時間以内に連絡を取り合ったほうが良さそうだ。

理由2022/3/16 23:362022/3/17 5:002022/3/17 7:002022/3/17 9:302022/3/17 12:022022/3/17 15:032022/3/17 17:47
NTT DoCoMo停電, 伝送経路故障福島県二本松市
福島市,
南相馬市
伊達市		福島県二本松市
福島市
南相馬市
伊達市		→福島県二本松市
福島市		→→解消
KDDI基地局バッテリー枯渇相馬市
南相馬市		→→解消
ソフトバンク停電,宮城県白石市
村田町
川崎市
福島県相馬市
南相馬市		→→→解消
楽天モバイル停電,宮城県
福島県		→→→解消
ドコモを利用しているため
NTT東 固定電話 ネット障害無し

こういうことがあるとやっぱり電源も独立しているNTT固定電話もあったほうが良いなあ。

データセンタ

ソフトバンク系列IDCフロンティア

福島白河データセンタを運用しているが障害無し。

GMO iCLUSTA+ byGMO ラピッドサイト共用

実は我が社GMOのレンタルサーバーだった。その為一日以上メールが停止してしまい、仕事が楽お客様に多大なる影響を与えてしまった。だからあれほど Google Workspace（旧称 G Suite）にしとけって言ったのに(下請けさんが既に導入済み)。

社内的にもメールが使えず、結果としてTEL / FAX が登場。リモートワークの人には USB で持ってきてもらうという時代に逆戻り。

ところで GMO 社の対応を纏めてみた。仮復旧までに1日半かかっている。

2022/3/16 23:36電源障害
2022/3/17 6:50電源障害復旧
起動
2022/3/17 11:21サーバ確認
調整
2022/3/17 12:12サーバ調整
サーバ起動
2022/3/17 13:12サーバ調整
サーバ起動
2022/3/17 13:58サーバ調整
サーバ起動
2022/3/17 15:05サービスサーバーの一部問題が解決に向かいそうな状況です。
2022/3/17 16:55現在メールサーバーの起動を確認しております。
受信については順次回復の見込みとなります。
2022/3/17 18:40メールサーバーにつきましては、一部除きメールの送受信が可能な状況となり、
ほぼ復旧を確認しております。
2022/3/18 5:48Web表示につきましても順次復旧している状況でございます。
2022/3/18 7:00Webサーバー、メールサーバー、コントロールパネルの起動が完了し、
現在確認作業を実施しております。
2022/3/18 8:00すべての起動作業完了、ほとんどのサービスにて回復を確認し、
現在、仮復旧となっております。
2022/3/18 9:00サービスの回復を確認し仮復旧となっており、
経過観察を行っております。

一本ドラマ出来そう。戦うIT土方が上司と反発しまた同僚(いるのか?)と結託し活躍しそうだ。

地震より間隔
2022/3/16 23:36電源障害0
2022/3/17 6:50電源障害復旧
起動		07:14:0007:14:00
2022/3/17 11:21サーバ確認
調整		11:45:00
2022/3/17 12:12サーバ調整
サーバ起動		12:36:00
2022/3/17 13:12サーバ調整
サーバ起動		13:36:00
2022/3/17 13:58サーバ調整
サーバ起動		14:22:00
2022/3/17 15:05サービスサーバーの一部問題が解決に<<<向かいそうな状況>>>です。15:29:00
2022/3/17 16:55現在メールサーバーの起動を確認しております。
受信については順次回復の見込みとなります。		17:19:0010:05:00
2022/3/17 18:40メールサーバーにつきましては、<<<一部除き>>>メールの送受信が可能な状況となり、
ほぼ復旧を確認しております。		19:04:00
2022/3/18 5:48Web表示につきましても<<<順次>>>復旧している状況でございます。30:12:00
2022/3/18 7:00Webサーバー、メールサーバー、コントロールパネルの起動が完了し、
現在確認作業を実施しております。		31:24:0014:05:00
2022/3/18 8:00すべての起動作業完了、<<<ほとんど>>>のサービスにて回復を確認し、
現在、仮復旧となっております。		32:24:00
2022/3/18 9:00サービスの回復を確認し仮復旧となっており、
経過観察を行っております。		33:24:0002:00:00

「向かいそうな」「一部を除き」「順次」「ほとんど」等あやふやな言葉連発。

大体だけど

  • 電源回復まで7時間
  • ハードウェア?起動・メールサーバの起動に10時間越え
  • Webサーバ・コントロールパネルの起動に14時間以上

ここまでの作業時間31時間。作業員の方お疲れ様です。一個一個の VM に access して systemctl してたら呆れるけどね。

BCP(事業継続計画)は?

そしてここまで時間が掛かる理由は、停電に備えてリカバリーする手順とプログラムが無かった。という事でしょうね。

最近電力会社のお陰で本当に停電しなくなったので、こういった事態に備えてなかったのでしょう。

「クラウド」とは名ばかり

この件て「クラウド」と冠されていても実際には一つのサーバしかない事。そして「クラウド」だから安心ではない事。「クラウド」だからダウンタイムが短いわけではない。

という良い教訓という事で。今回データが吹っ飛ばないだけよかったんだよ。きっと。

引用
https://xtech.nikkei.com/atcl/nxt/column/18/01994/031700001/
https://support.gmocloud.com/info/?c=support_all
https://support.gmocloud.com/info/detail.html?no=73647
https://support.gmocloud.com/info/detail.html?no=73636

InterQ (いつものプロバイダーにつながらなければQ2へ) by GMO