最近のUTMは暗号化した通信パケットを複合して、セキュリティに問題があるかを確認してパケットを転送する言わばプロキシのような動作で、通信のセキュリティを担保をするSSL deep inspection機能があります。
■SSL Inspectionのイメージ
今回Soliton SecureDesktop(リモートデスクトップ）を利用して社内にリモートログインをするときに、UTMのdeep inspection機能により失敗した例の解決方法を備忘で記載しています。
■Soliton SecureDesktopの動作イメージ
これはサーバとクライアント間でサーバ証明書を交換するときに改ざんされていないか確認をする動作によるものです。
目的はクライアントが特定のサーバの証明書または公開鍵を事前に信頼する仕組みで、SSL/TLS通信で中間攻撃を防ぐために行うものです。
■エラーログの概要
UTMに表示されているSSLのログに証明書の異常、サーバー証明書とSNI(ドメイン名)が一致しない
■出力ログ抜粋
service="SSL"
profile="deep-inspection"
eventsubtype="certificate-anomaly"
msg="Server certificate and SNI mismatched"
SolitonのリモートデスクトップサービスはクライアントとストリーマがSolitonのSecureDesctop Center
にアクセスしリレーサーバを経由してデスクトップを提供するサービスに見える。
今回のSSLのログではサーバ証明書とドメイン名が一致していないというエラーログがあるため、deep inspection機能でUTMの証明書を利用して暗号化するパケットがSolitonのサーバ証明書と違うとエラーがでている。
ここでUTMを挟まないでリモートデスクトップが成功している場合と、失敗している場合のTLS/SSLのシーケンスを確認すると成功時はサーバがCertificateRequestメッセージを送信してクライアント認証を要求しているが成功時は、クライアントからサーバにCertificateVerifyメッセージを送信しているが失敗時は送信していないことがわかります。Solitoin SecureDesktopはクライアント認証をするタイプのサーバと想定されます。
■クライアント認証が要求されている場合
サーバーがCertificateRequestメッセージを送信してクライアント認証を要求する
クライアントは証明書を送信する必要があります
証明書を送信した場合は、その後にCertificate Verifyメッセージで署名による証明が必要です
Certificate Verifyメッセージが送られない場合、通信は失敗します（ハンドシェイク失敗）
■クライアント認証が要求されていない場合
サーバーがCertificateRequestメッセージを送信しない
クライアントは証明書もCertificate Verifyメッセージも送信する必要がありません
この場合は通信は正常に継続されます（一般的なWebサイトへのHTTPS接続など）
■中間的なケース
クライアント認証がオプション設定の場合
クライアントが証明書を送信しない場合は、Certificate Verifyも不要で通信継続
クライアントが証明書を送信した場合は、Certificate Verifyが必須
Certificate Verifyメッセージの有無による通信失敗は、サーバー側のクライアント
認証設定に依存します。
多くの一般的なWebサイトではクライアント認証は不要なので、Certificate Verifyメッセージがなくても通信は成功します。
■結論
UTM配下でdeep inspectionを利用している場合、Soliton SecureDesktopを利用してリモートデスクトップを接続する場合は、Solitonのドメイン向けの通信に対してdeep inspection機能を除外（無効）にする必要があります。
Solitonのドメイン向けの通信はdeep inspection機能を除外（無効）にすることによりUTMにより、サーバ証明書が書き換えられないため、クライアント側でSolitonのサーバ証明書が確認できるようになりTLSによる暗号化の共有鍵交換ができるようになり正常に通信することができました。