先日、マンホールマップのログイン機能に障害が発生しました：
通常、マンホールマップ（PC版）のトップページにアクセスすると、画面右上には "Login with Twitter" マークが表示されます（未ログインの場合）：
で、ここをクリックして、Twitter の OAuth 認可によってマンホールマップにログインして・・・という流れでログインするのですが、ここに問題が発生していると「現在、何らかの障害によってログインできません。」というメッセージが表示されます：
一般的には Twitter API の障害が発生していることを示すメッセージなのですが、先日マンホールマップで発生していたものは Twitter API には障害が発生していないにも関わらず、上記のようなメッセージが表示されていたのでした。 ちなみに Twitter API の稼動状態はこちらで確認できます：
API Status | Twitter Developers
さて、上記の原因はなんだったのでしょうか？ ちなみにマンホールマップは Java で開発された Web アプリケーションで、この Twitter の OAuth 認可の部分は Twitter4J を使って実装しています（最新版の 4.0.4 でも、スナップショット版の 4.0.5 でも再現）。で、問題部分のコードは以下のようになっていました：
リクエストトークンを取得するための Twitter.getOAuthRequestToken() メソッド実行時に Exception が発生していました。それまでに設定しているのは Twitter API の Consumer Key と Consumer Secret だけで、これは正しい値が設定できていました（というか、正しく動いていた時から何も変えてません）。 で、その下の catch 内で以下のようなスタックトレースが出力されていました：
問題の getRequestOAuthToken() を実行した時に "Invalid signature on ECDH server key exchange message" というエラーメッセージが出力されています。何コレ？"Invalid signature" って言われても、この時点ではこちらは Key と Secret 以外何も指定してないので間違えているとは思えないけど・・・？？
しつこいようですが、今までは何の問題もなく動いていたコードが、ある時を境に急にこのような挙動になってしまいました。となると、Java ソースコードに直接の原因があるとは考えにくい・・・
しかもこの問題、何が厄介かというと、デバッグしようとしてローカルの Eclipse 内で動かすと、このエラーも Exception も発生しないのです。ちゃんと動いてしまいます。更に言うと、別のサーバー内に同様の Java + Tomcat 環境を作って、同じ war をデプロイして実行しても発生しない。要はこの本番サーバーだけで発生するエラーだったのです。。 となると環境依存か、原因特定は更に厄介だぞ・・・
とりあえず緊急でサーバーを１つ作り、そちらに Java と Tomcat を導入し、アプリの war をデプロイ、したら動きました。なので、応急処置としてはこれでなんとかなります。この応急処置サーバーで運用を続けながら原因追求と解決を続けます。 ああ、クラウドってこういう時に便利なのね。。。
さて、このエラーメッセージをググってみると分かるのですが、SSL 関連の Exception のようなのです。はて、マンホールマップに SSL 関連モジュールなんか使ってたっけ？？ 何よりも仮に使っていたとしても、実行コードは Twitter4J の中だし、指定しているのは Key と Secret だけで変えようがないし、他のサーバー環境だと動いちゃうし・・・ 念のため API Key と Secret を新たに取得し直して見ましたが、状況は変わりませんでした。
次に行ったのは JDK と Tomcat のアンインストール、および再インストールです。環境は CentOS だったので、 JDK のアンインストールは以下の手順で行いました：
同様にして、Tomcat も以下の手順でアンインストールしました：
でもってそれぞれを再インストールします：
これで Java と Java アプリケーションサーバーはまっさらな状態に戻りました。この状態でマンホールマップの JAR をインストールしてアクセスしたところ・・・ 何も変わらない・・・ orz
全く原因が思いつきません。いよいよヤバい。 改めてこの ECDH なるものを調べてみると暗号化のアルゴリズムっぽいようでした：
ECDH アルゴリズムの概要
暗号化アルゴリズムの、鍵の交換の所で（しかも今まで動いていたものが、ある時から）動かなくなった、ということになります。いよいよ OS レベルの中身がぶっ壊れてしまったか？？ と思ったのですが、最後の希望を託してインストールした全ライブラリを更新してみることにしました：
で、Tomcat をリスタートしてアクセスしてみたら・・・ 直りました！ 助かった！！
↑直ったのはついさっき
後は緊急運用サーバーからこちらに切り替えれば対処完了（予定）。 結局「これ」という直接の原因は分からなかったけど、古いライブラリでは対応しない機能を使っていた、ということなんでしょうかね～。
自分が作って運用しているウェブサービスの多くはクラウド上で動いてますが、このマンホールマップに関しては自宅サーバーで（更に言えば ThinkPad で）運用することにまだこだわっています。今回のエラーはその信念を揺るがすものでしたが、とりあえず解決できました。もうしばらく自宅サーバー運用を続けることができそうです。 v(^o^)
通常、マンホールマップ（PC版）のトップページにアクセスすると、画面右上には "Login with Twitter" マークが表示されます（未ログインの場合）：
で、ここをクリックして、Twitter の OAuth 認可によってマンホールマップにログインして・・・という流れでログインするのですが、ここに問題が発生していると「現在、何らかの障害によってログインできません。」というメッセージが表示されます：
一般的には Twitter API の障害が発生していることを示すメッセージなのですが、先日マンホールマップで発生していたものは Twitter API には障害が発生していないにも関わらず、上記のようなメッセージが表示されていたのでした。 ちなみに Twitter API の稼動状態はこちらで確認できます：
API Status | Twitter Developers
さて、上記の原因はなんだったのでしょうか？ ちなみにマンホールマップは Java で開発された Web アプリケーションで、この Twitter の OAuth 認可の部分は Twitter4J を使って実装しています（最新版の 4.0.4 でも、スナップショット版の 4.0.5 でも再現）。で、問題部分のコードは以下のようになっていました：
String authorizationURL = null;
try{
Twitter twitter = new TwitterFactory().getInstance();
twitter.setOAuthConsumer( TWITTER_CONSUMER_KEY, TWITTER_CONSUMER_SECRET );
RequestToken requestToken = twitter.getOAuthRequestToken(); ←ここで Exception 発生
String token = requestToken.getToken();
String tokenSecret = requestToken.getTokenSecret();
:
:
}catch( Exception e ){
e.printStackTrace();
}
リクエストトークンを取得するための Twitter.getOAuthRequestToken() メソッド実行時に Exception が発生していました。それまでに設定しているのは Twitter API の Consumer Key と Consumer Secret だけで、これは正しい値が設定できていました（というか、正しく動いていた時から何も変えてません）。 で、その下の catch 内で以下のようなスタックトレースが出力されていました：
Invalid signature on ECDH server key exchange message Relevant discussions can be found on the Internet at: http://www.google.co.jp/search?q=3cc69290 or http://www.google.co.jp/search?q=45a986b4 TwitterException{exceptionCode=[3cc69290-45a986b4 3cc69290-45a9868a], statusCode=-1, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=4.0.5-SNAPSHOT(build: 9b7efa6faa540a9defb3e6ba9122a356155986b1)} at twitter4j.HttpClientImpl.handleRequest(HttpClientImpl.java:179) at twitter4j.HttpClientBase.request(HttpClientBase.java:57) at twitter4j.HttpClientBase.post(HttpClientBase.java:86) at twitter4j.auth.OAuthAuthorization.getOAuthRequestToken(OAuthAuthorization.java:115) at twitter4j.auth.OAuthAuthorization.getOAuthRequestToken(OAuthAuthorization.java:92) at twitter4j.TwitterBaseImpl.getOAuthRequestToken(TwitterBaseImpl.java:292) at twitter4j.TwitterBaseImpl.getOAuthRequestToken(TwitterBaseImpl.java:287) at me.juge.geoimgweb.AppInfo.GetAuthorizationURLTwitter(AppInfo.java:361) at me.juge.geoimgweb.AppInfo.GetAuthorizationURL(AppInfo.java:350) at org.apache.jsp.stats_jsp._jspService(stats_jsp.java:928) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:745) Caused by: javax.net.ssl.SSLKeyException: Invalid signature on ECDH server key exchange message at sun.security.ssl.HandshakeMessage$ECDH_ServerKeyExchange.(HandshakeMessage.java:1098) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:278) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913) at sun.security.ssl.Handshaker.process_record(Handshaker.java:849) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1093) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) at twitter4j.HttpClientImpl.handleRequest(HttpClientImpl.java:137) ... 30 more
問題の getRequestOAuthToken() を実行した時に "Invalid signature on ECDH server key exchange message" というエラーメッセージが出力されています。何コレ？"Invalid signature" って言われても、この時点ではこちらは Key と Secret 以外何も指定してないので間違えているとは思えないけど・・・？？
しつこいようですが、今までは何の問題もなく動いていたコードが、ある時を境に急にこのような挙動になってしまいました。となると、Java ソースコードに直接の原因があるとは考えにくい・・・
しかもこの問題、何が厄介かというと、デバッグしようとしてローカルの Eclipse 内で動かすと、このエラーも Exception も発生しないのです。ちゃんと動いてしまいます。更に言うと、別のサーバー内に同様の Java + Tomcat 環境を作って、同じ war をデプロイして実行しても発生しない。要はこの本番サーバーだけで発生するエラーだったのです。。 となると環境依存か、原因特定は更に厄介だぞ・・・
とりあえず緊急でサーバーを１つ作り、そちらに Java と Tomcat を導入し、アプリの war をデプロイ、したら動きました。なので、応急処置としてはこれでなんとかなります。この応急処置サーバーで運用を続けながら原因追求と解決を続けます。 ああ、クラウドってこういう時に便利なのね。。。
さて、このエラーメッセージをググってみると分かるのですが、SSL 関連の Exception のようなのです。はて、マンホールマップに SSL 関連モジュールなんか使ってたっけ？？ 何よりも仮に使っていたとしても、実行コードは Twitter4J の中だし、指定しているのは Key と Secret だけで変えようがないし、他のサーバー環境だと動いちゃうし・・・ 念のため API Key と Secret を新たに取得し直して見ましたが、状況は変わりませんでした。
次に行ったのは JDK と Tomcat のアンインストール、および再インストールです。環境は CentOS だったので、 JDK のアンインストールは以下の手順で行いました：
# yum list installed | grep jdk （インストール済み JDK を確認） java-1.7.0-openjdk.x86_64 java-1.7.0-openjdk-devel.x86_64 jdk.x86_64 2000:1.7.0_79-fcs （候補は３つ、全部削除してもよいと判断） # yum remove java-1.7.0* （上２つをアンインストール） # yum remove jdk* （一番下をアンインストール）
同様にして、Tomcat も以下の手順でアンインストールしました：
# yum list installed | grep tomcat （インストール済み tomcat を確認） tomcat6.x86_64 6.0.24-90.el6 @base tomcat6-admin-webapps.x86_64 tomcat6-el-2.1-api.x86_64 tomcat6-jsp-2.1-api.x86_64 tomcat6-lib.x86_64 6.0.24-90.el6 @base tomcat6-servlet-2.5-api.x86_64 （候補は６つ、全部削除してよいと判断） # yum remove tomcat6* （まとめてアンインストール）
でもってそれぞれを再インストールします：
# yum install java-1.7.0-openjdk-devel # yum install tomcat6 tomcat6-admin-webapps
これで Java と Java アプリケーションサーバーはまっさらな状態に戻りました。この状態でマンホールマップの JAR をインストールしてアクセスしたところ・・・ 何も変わらない・・・ orz
全く原因が思いつきません。いよいよヤバい。 改めてこの ECDH なるものを調べてみると暗号化のアルゴリズムっぽいようでした：
ECDH アルゴリズムの概要
暗号化アルゴリズムの、鍵の交換の所で（しかも今まで動いていたものが、ある時から）動かなくなった、ということになります。いよいよ OS レベルの中身がぶっ壊れてしまったか？？ と思ったのですが、最後の希望を託してインストールした全ライブラリを更新してみることにしました：
# yum update -y : : : # /etc/init.d/tomcat6 restart
で、Tomcat をリスタートしてアクセスしてみたら・・・ 直りました！ 助かった！！
↑直ったのはついさっき
後は緊急運用サーバーからこちらに切り替えれば対処完了（予定）。 結局「これ」という直接の原因は分からなかったけど、古いライブラリでは対応しない機能を使っていた、ということなんでしょうかね～。
自分が作って運用しているウェブサービスの多くはクラウド上で動いてますが、このマンホールマップに関しては自宅サーバーで（更に言えば ThinkPad で）運用することにまだこだわっています。今回のエラーはその信念を揺るがすものでしたが、とりあえず解決できました。もうしばらく自宅サーバー運用を続けることができそうです。 v(^o^)
コメント