皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

金融機関や大手企業においては絶対と言って良い程採用されている『EV（Extended Validation） SSLサーバ証明書』ですが、この証明書によってURLバーに表示される組織名が間もなく消えてしまいます。

グリーンバーが間もなく消えます

『EV SSLサーバ証明書』の場合、取得には登記簿の提出などの要件があることから『本物』であることを『グリーンバー』として表示し、安心材料の一つとなっていました。

しかし、米国では州を変えて申請することで既知の企業と同じ組織名を表示する『EV SSLサーバ証明書』が作れてしまうという落とし穴があったとされています。

（これ、日本においても会社法上、同一商号は最小行政区ですら要件次第では登記可能ですから同じようなことが言えるとは思いますが。。。）

つまり、『EV SSLサーバ証明書』で組織名が表示されていても『偽物』の場合があり得てしまうということです。

このようなことからGoogleは一定のテストを行ったようで、結果的には来月リリース予定の『Google Chrome 77』からは『グリーンバー』を表示しない仕様へ変更する予定をしています。

（詳細情報での組織名確認は可能です。）

また、ブラウザへの仕様変更は『Firefox』でも同じように『グリーンバー』を表示しない方向で進めているようで、iOSにおける『Safari』は既に非表示になっています。

今後の対策としては、ブラウザの機能にある『セーフブラウジング』やセキュリティソフトに搭載されている同様の機能を活用していくことで被害を防ぐことになるのかもしれません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭で書きました通り、以前にWordPressの更新が止まってしまう原因にてお伝えしたわけですが、新たにこんなケースもあることがわかりました。

WordPressの更新が止まる訳（続）

今回わかったケースでは、WordPress本体やプラグインの更新が途中で完全に止まってしまったというより、止まってしまったように見えるような現象です。

ダウンロードしている表示以降、完了しても一覧に戻るなどのリンクは表示されず、一見ダウンロード途中で止まっているように見えます。

このような現象が起きていた原因として、セキュリティソフトの存在があります。

単にセキュリティソフトが常駐していることがダメなわけではなく、ある特定のことを行っている場合に限ってです。

セキュリティソフトの中には、SSL/TLSのプロトコルをチェックする機能を搭載したものがあり、その中に、チェックを行う必要性のないWebサイトのSSL証明書を認識させておくことができるものもあります。

ここにWordPressを使っているWebサイトのSSL証明書を認識させておくと更新が途中で止まってしまっているかのように見える現象が発生します。

やはり、セキュリティソフトが搭載している機能は何らかの形で影響を与えるケースが多いですね。

同じ現象が発生している方、一度試しに認識させたSSL証明書を削除して更新を実行してみると正常な状態に戻ります。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

ある程度の方はセキュリティ（ウイルス対策）ソフトが原因でアプリケーションソフトを正常にインストールできなかった経験をお持ちかもしれません。

しかし、このセキュリティ（ウイルス対策）ソフトが原因となってしまう問題はそれだけではありません。

セキュリティソフトが原因で起こる問題

例えば、Windows 10などにおいては『Windows Defender』というセキュリティが標準で用意されていますが、通信を必要とするアプリケーションなどにおいては設定を変更したり、場合によっては一時的にファイアウォールを無効にした状態で作業をしないと前に進められないものもあります。

これはセキュリティ専門のメーカーが出しているセキュリティ（ウイルス対策）ソフトでも同じで、最悪は、一度それをアンインストール（削除）してみないとわからないというケースもあります。

細かいところで言えば、Google ChromeやFirefoxなどのブラウザソフトに用意されている拡張機能などに影響が出る場合もありますし、SSL/TLS証明書とセキュリティ（ウイルス対策）ソフトの絡みで影響が出る場合もあります。

先日、こんなケースに遭遇しました。

WordPressの本体更新やプラグインの更新において、『内部的には正常にダウンロードされて終了までたどり着いているものの、表示的にはダウンロード中で止まってしまっているように見える』というものです。

これ、結果的にはGoogle Chromeに拡張機能が加わった状態にて、セキュリティ（ウイルス対策）ソフト側に特定のWebサイトのSSL/TLS証明書がセキュリティ（ウイルス対策）ソフトに登録されていたことが影響していました。

こういったレアなケースもあったりしますので、パソコンにおけるトラブルの場合、一度はセキュリティ（ウイルス対策）ソフトが起因していることを疑ってみるのも必要と言えるでしょう。

次のChrome 66は、4月17日に安定版の公開が予定されています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

WebブラウザのGoogle Chrome 65がリリースされたばかりですが、次のバージョンChrome 66において一部のSSL証明書への信頼が停止されます。

Symantec系SSL証明書の信頼停止

以前にもこのブログで取り上げましたが、WebブラウザのGoogle Chrome 66において、Googleに信頼できないと判断された『Symantec系認証局（CA）』の『Thawte』、『VeriSign』、『Equifax』、『GeoTrust』、『RappidSSL』が発行したSSL証明書が、同Webブラウザにおいて信頼が停止されます。

さらに、10月16日に公開が予定されているChrome 70においては、これら以外の残りのSymantec証明書に関してもすべて信頼が停止されることが予告されています。

信頼が停止されたSSL証明書のままであった場合、Chromeにて当該サイトを表示する際にエラー警告が表示されるため、事業者にとっては最低でもイメージダウンやアクセス数の低下につながってしまいます。

これが表示された場合であっても詳細設定から『〇〇にアクセスする（安全ではありません）』をクリックすれば実際のページに進めますが、『安全ではない』と表示されている状態で先に進もうとする人は心理的に少ないです。

また、DigiCertがSymantecの証明書事業を買収した後にDigiCertから再発行された証明書は信頼できるものとして扱われるため、これらの措置の対象からは外れます。

問題が起きないようにするため、ウェブサイトのSSL証明書を直ちにチェックして対応する必要があります。

参考：『Google Security Blog:Distrust of the Symantec PKI: Immediate action needed by site operators』

追伸：1月20日より提供されているChromeの試験運用版（Canary）、3月15日にリリースされるChrome 66のβ版においては4月17日公開予定の安定版を待たずに警告が表示されます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨日、Microsoft（マイクロソフト）の月例パッチがリリースされたわけですが、それによって、ブラウザのEdgeやIE（Internet Explore）11においても対応しなくなったものがあります。

SHA-1証明書への対応の終了

今年に入って、Google（グーグル）のブラウザであるChromeはSSL証明書でSHA-1を使った証明書のサポートを完全に打ち切り、Mozilla（モジラ）のブラウザであるFirefoxはそれをデフォルトで無効にする措置を取りました。

これらに続き、Microsoft（マイクロソフト）のブラウザであるEdgeとIE（Internet Explore）においても今回、SHA-1アルゴリズムを使ったSSL証明書が使われたWebサイトをブロックする措置を取りました。

ただし例外的な措置として、エンタープライズ証明書や自己署名証明書はブロックされないものの、早期にSHA-2のSSL証明書に移行するように呼びかけをしています。

SHA-1アルゴリズムの危険性

SHA-1はSHA-2に比べてハッシュ値の長さが短いことから安全性が低下するため、数年前からSHA-2へ移行する動きが出ていました。

簡単に言えば、攻撃される危険性が高いため、安全性の高いものへ移行するということです。

これらのことから保護するため、各ブラウザにおいてSHA-1への対応を終了させたということです。

普段、あまり気に欠けないものかもしれませんが、自社のWebサイトにおいてもし未だSHA-1のSSL証明書が使われているのであれば、早急にSHA-2のSSL証明書に移行しなければいけません。

それは本当にブラウザ側のチェックだけによるものなのでしょうか？

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

少し前あたりから、主要なブラウザにおいてHTTPSアドレスに対するチェックの強化が行われています。

そのため、SHA-1のSSL証明書を利用している場合であったり、コンテンツ内に非SSLコンテンツを使用している場合などにおいて警告表示がされます。

しかし、それらには問題がない場合においても警告表示が出されてしまい、閲覧したいウェブサイトが表示されないケースもあります。

セキュリティソフトの影響によるもの

昨今のセキュリティソフトには、SSL/TLSプロトコルをチェックする機能が搭載されていることが多いですが、そのSSL/TLSプロトコルのチェック機能がうまく反映されなかった場合においても『安全ではない接続』として警告表示されることがあります。

こういった機能は、セキュリティソフトによって各ブラウザの『信頼されたルート証明機関』であったり、『認証局証明書』部分にセキュリティソフト会社のものを追加させている場合があり、それで中継させてSSL証明書のチェックを行っていたりします。

このような場合、すべてのブラウザとメールソフトを終了させ、当該機能を一度オフにし、セキュリティソフトに設定を書き込みします。

その後、再度セキュリティソフトの設定画面を開き、もう一度その機能をオンにしてセキュリティソフトに書き込みします。

この動作を行った後、各ブラウザにて確認すると通常通り閲覧できるようになったりします。

ただし、これでもNGなケースがないわけではありませんので、その場合は当該機能をオフにしてブラウザにて確認をしてみることになります。

サイバー攻撃、インターネット犯罪が増加するばかりの昨今においては、セキュリティソフト側もさまざまなチェック機能を搭載するようになっていますので、少々複雑化していることは事実ですのでご注意ください。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

先月の終りごろだったでしょうか。

Google（グーグル）のChrome（クローム）チームが、Symantec（シマンテック）が発行した証明書に対して、証明書の有効期間を短縮するなどの措置提案を行いました。

グーグルがシマンテックに提案した理由

Googleが公表したところによると、Symantecは証明書発行において不手際を繰り返しているとしています。

Googleは数ヵ月前からSymantecの証明書の不手際を調査しており、結果的には3万件にも上る証明書発行の不手際があったとしています。

また、Symantecは過去にも同様のことがあったとされ、GoogleはSymantecの証明書を信用できないものと位置付けたのでしょう。

しかし、Symantecはそれを事実ではないと反論しており、同社の証明書は信頼できるものと主張しています。

シマンテックのSSL証明書の行方

このまま行けば、Symantecをはじめ、Symantecの傘下にあるVerisign（ベリサイン）、Thawte（ソート）などを含めたSSL証明書がChromeブラウザにおいてエラーとなってしまう可能性があります。

ただし、もしそうなるにしても段階的な措置が行われるものとされており、3年以上かけて有効期間を短縮していくようです。

しかし、Symantecとその傘下のSSL証明書がエラーとされてしまうとなると、全世界で30%～40%ものSSL証明書がエラーとなってしまうため、現在、Symantec系列のSSL証明書を使用しているウェブサイトにおいては他社への移行を検討した方が良いかもしれません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨年、このブログにおいてもいくつか記事を書かせていただきましたが、昨年のGoogleの発表から、Webサイトの暗号化に関する動きが加速しています。

※　Webサイトの暗号化＝http://www.example.com/ ⇒ https://www.example.com/

しかし、Webサイトを暗号化（HTTPS化）するとなると費用がかかること、直ぐにはすべてがそうなるわけではないと高を括っていることなど、未だ日本においては浸透度合いが薄い状態にあります。

HTTPS化に費用がかかる理由

Webサイトを暗号化（HTTPS化）することに費用がかかる理由として、2つの理由があります。

１．認証局が発行するSSL証明書の取得・設定に費用がかかる

２．HTTPS化に対応させるための改修に費用がかかる

これらは自社において完結できるのであれば抑えることはできますが、Webサイトの管理を外部委託されている場合においては相応の費用がかかります。

企業イメージを損なわないために

本来の理由は訪問者（閲覧者）であるユーザーを守ることが趣旨ですが、事業者として企業のイメージも重要です。

『あそこの会社はセキュリティに対する意識が低い！』などとマイナスのイメージをもてれることは先々のビジネスにおいても影響する可能性があります。

そして、まずは発想を変えてください。

ご自身がセキュリティ的に守られていないWebサイトに対して安心感がもてるかどうかです。

おそらく大半の方は『安心感がもてない』と回答するはずです。

となれば、訪問者（閲覧者）であるユーザーも同じ心理が働いているはずで、それに関連して、Webサイトが安全な状態に保たれていれば企業イメージもマイナスには作用しないことになります。

また、これらは中小・零細企業、小規模事業者も例外ではありません。

むしろ、中小・零細企業、小規模事業者の方がそれらに対する意識を高めていただく必要性が今はあります。

※　CDNとは、Webコンテンツをインターネット経由で配信するために最適化されたネットワークのことです。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

CDNサービスの中でも無料プランが用意されていることで有名なCloudflareですが、この無料の範囲には注意しなければいけないものもあります。

※　無料プラン以外に、プロプラン（$20/月）、ビジネスプラン（$200/月）、エンタープライズプラン（$5,000/月）があります。

Cloudflareの仕組み

CloudflareなどのCDNは、レンタルサーバなどのオリジナルサーバとVisitorであるウェブサイトへの訪問者（ブラウザ）の間に存在します。

オリジナルサーバにあるコンテンツをCloudflareなどのCDNサービスが最適化（キャッシュや軽量化など）を行い、ウェブサイトへの訪問者に提供しています。

もちろん、ウェブサイトへの訪問者はそういったサービスが介在しているウェブサイトかどうかはわかりません。

通常のウェブサイトと全く同じように閲覧することになります。

CloudflareにおけるSSLの注意点

CloudflareのSSL（暗号化通信）には、Off、Flexible、Full、Full（strict）の選択があり、Offはもちろん暗号化通信なしですが、Flexibleはウェブサイトへの訪問者とCloudflareの間のみ暗号化通信され、Cloudflareとオリジナルサーバの間は暗号化通信されません。

また、FullのモードにおいてはCloudflareとオリジナルサーバ間においても暗号化通信がなされますが、Fullの場合はオリジナルサーバ側のSSL証明書が自作のものであってもよく、Full（strict）の場合のみ公的に信頼された認証局によって署名された有効なSSL証明書を要するというモードになっています。

つまり、完全な暗号化通信と公的に信頼された認証局に署名されたSSL証明書、これらの条件が必ず満たされていなければならないのはFull（strict）のモードのみということになります。

一般的に考えた場合、ウェブサイトの常時SSL化は訪問者のブラウザとオリジナルサーバの間が暗号化通信となり、そこには公的に信頼された認証局に署名されたSSL証明書が存在します。

ここから考えると、こういったCDNサービスを使う場合においてもすべてに暗号化通信がなされ、公的に信頼された認証局に署名されたSSL証明書が存在することがユーザーの安全性を確保するものと考えることが妥当でしょう。

そのあたりは是非念頭において活用していただきたいものです。

ちなみに、Full（strict）のモードはビジネスプラン、エンタープライズプランへのアップグレードや、Cloudflareにおける専用証明書の購入をしなくても使うことは可能ですが、ブラウザにてSSL証明書の発行先確認をした場合にはCloudflareのドメイン（Universal SSL）が表示されるため、訪問者に安心してもらうにはサイトシールなどにてドメインや企業名などの確認ができる状態を作っておくことが望ましいと思われます。

皆さん、こんにちは。

業務コンサルタントの高橋です。

以前にもHTTPが安全ではないこと、HTTPSを推奨する記事は書かせていただきましたが、今回、GoogleがChromeブラウザーの開発で新たな動きをしています。

Google Chrome の新たな機能

Googleが提供するChromeブラウザーの開発版では、HTTPSが採用されていない、つまり、HTTPのページに対してアドレスバーの先頭に×マークが付いた南京錠アイコンが表示される仕組みが導入されています。これが意味するところは、『HTTPページなので安全ではないページです。注意してください！』と警告を発するということです。
（現在のChromeブラウザー最新版では白いページアイコンの表示だけです。）

これまでのGoogleの動き

Googleは、少し前にもHTTPSをアルゴリズムに取り入れることや、HTTPSページを優先的にインデックスすることをアナウンスしてきており（参考：SSL暗号化通信のHTTPSは有利）、ウェブの暗号化に関する取組を推奨していることは明らかです。そこから考えると、現在開発中のChromeブラウザーに対する取組はごく自然なものと言えるかもしれません。

また、この取組はGoogleに限った話しではなく、以前に書かせていただいた通り世界的にHTTPS化への動きは進んでいます。

参考：今後のWEBはhttpからhttpsへ

今すぐHTTPS化を行うべきか？

これらの動きに対してHTTPS化をすぐに行うべきか？については、行える余裕があるのであれば行った方が良いでしょう。幸い、現在ではSNIというものがありますのでレンタルサーバー会社によってはそれが使えますし（参考：SNIを使ったSSL通信のススメ）、SSL証明書も安価なところがたくさんあります。一番手間がかかるのはウェブサイトのHTTPS対応になりますが、今後の情勢を考えると早めに移行されることがベターかもしれません。