2016-11-02 9 views
0

私は奇妙な問題に直面しましたが(これは何の処置もなしに解決されます:-))、どういうことが起こったか知っているかどうかを知りたいだけでした。タイムゾーンの変更はSSLハンドシェイクに影響しますか?

背景:

だから私のテストサーバーは、それがサポートしている銀行のリストを取得するにはREST URLを使って支払いゲートウェイ(第三者)に接続するロジックを持っています。バックグラウンド接続&常時サービスURL以来、私はhttpクライアント(何かthisのようなもの)のためにダミーのトラストストアを使用しました。私のアプリケーションは、UTCタイムゾーンのサーバで動作しています。

問題:

これはEOD 2016年10月31日EODから2016年11月1日に、それは始まっ方法です - whne HTTPSがREST URLにアクセスして、これまでそれは "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated" の例外をスロー。 Javaのバージョンはopen-jdk-1.7.0.09でした。&同じ構成の別のサーバーで試しましたが、状況は同じでした。あるサーバでjavaを1.7.0.101に更新したところ、動作し始めました。私は今日のためにcehckに問題を残しました&にNov 2, 2016ちょうどjvmを再起動するとすべて正常に動作します。証明書の検証/接続に問題はありません。私が見つけた1つの変わった事実は、からAmerica/Los Angelesに変更されたJavaのデフォルトタイムゾーンでした。また、夏時間がtrueに設定されました(Ok 10月が終了しました)。

質問:

は、SSLハンドシェイクでのタイムゾーンのための任意の接続はありますか?私は環境/コードに他の変化は見られません。誰かがこれについて何かを知っていますか? これは疑問の基準に違反しないことを望みます:-)

答えて

2

正しく書かれたTLSスタックでは、現在のタイムゾーンは関係ありません。証明書の有効期限はUTCで保存されるため、タイムゾーンとは独立しています。したがって、比較の時間もUTCにあるはずです。また、適切なOSでローカルタイムはUTCに内部的に保存されますが、Windowsはここでは例外です。したがって、すべてのUTCを使用する場合、タイムゾーンの変更は問題ありません。もちろん、誰かがタイムゾーンに応じて機能を使うことでこの素晴らしい理論を台無しにしているかもしれません。

+0

Windowsの例外はありません。内部的なシステム時間は確かにUTCです。現時点ではBIOSクロックだけが保持されていますが、これはこの質問とは関係ありません。 SSL/TLSはUTCのみに依存しているということは間違いありません。 –

関連する問題