2017-10-10 18 views
2

現在、クライアント証明書認証を使用するWCFサービスのプロトタイプを作成中です。アプリケーションをIISに直接公開できますが、IIS ARR(Application Request Routing)を使用してSSLオフロードを許可することもできます。クライアント証明書にARRとAuthorizationContextを使用したthumprintが異なる

ドキュメントを掘り下げた後、両方の設定を正常にテストできました。

  1. X-Arr-ClientCert - ARRを使用する場合の証明書を含むヘッダーです。
  2. X509CertificateClaimSetは - IISに直接発行されたときに、これは

は、要求が許可されていることを確認するために、クライアント証明書を取得する方法ですが、私はどこかに設定されている期待拇印に証明書の拇印と一致します。驚いたことに、さまざまな方法で証明書を取得するとき、同じ証明書には異なる拇印があります。

何が起こっているかを確認するには、私はBase64での両方の証明書に「のRawData」プロパティを変換し、それは同じだということを発見した、X509CertificateClaimSetの場合とを除いて、スペース証明書データでがあり、 ARRの場合はそうではありません。それ以外の場合は、両方の文字列は同じです:

comparison of base64 strings

は私の質問: は誰にもこのに実行された、と私は実際にサムプリントに頼ることができますか?そうでない場合、私のバックアップ計画はSubjectとIssuerのチェックを実装することですが、私は他の提案にもオープンしています。

私が含まれている以下のいくつかの(簡体字)のサンプルコード:

string expectedThumbprint = "..."; 
    if (OperationContext.Current.ServiceSecurityContext == null || 
    OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets == null || 
    OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets.Count <= 0) 
    { 
    // Claimsets not found, assume that we are reverse proxied by ARR (Application Request Routing). If this is the case, we expect the certificate to be in the X-ARR-CLIENTCERT header 
    IncomingWebRequestContext request = WebOperationContext.Current.IncomingRequest; 
    string certBase64 = request.Headers["X-Arr-ClientCert"]; 
    if (certBase64 == null) return false; 
    byte[] bytes = Convert.FromBase64String(certBase64); 
    var cert = new System.Security.Cryptography.X509Certificates.X509Certificate2(bytes); 
    return cert.Thumbprint == expectedThumbprint; 
    } 
    // In this case, we are directly published to IIS with Certificate authentication. 
    else 
    { 
    bool correctCertificateFound = false; 
    foreach (var claimSet in OperationContext.Current.ServiceSecurityContext.AuthorizationContext.ClaimSets) 
    { 
     if (!(claimSet is X509CertificateClaimSet)) continue; 
     var cert = ((X509CertificateClaimSet)claimSet).X509Certificate; 
     // Match certificate thumbprint to expected value 
     if (cert.Thumbprint == expectedThumbprint) 
     { 
     correctCertificateFound = true; 
     break; 
     } 
    } 
    return correctCertificateFound; 
    } 

答えて

0

、私の問題が解消されたことが表示されます。私は間違いを犯したかどうかは分かりませんが、マシンを再起動すると助けになりましたが、いずれの場合でも、両方の認証方法で拇印が信頼できるようになりました。

0

わからないあなたの正確なシナリオが何であるか、私はいつも、サーバー<確保するタコ展開アプローチ言っていました - >触手を(クライアント)コミュニケーション。これは、Octopus Tentacle communication articleに記載されています。基本的に、SslStreamクラス、自己署名X.509証明書、およびサーバーと触手の両方で構成された信頼できるサムプリントが使用されます。同僚によるピアレビューのために再度テストを設定する際

-Marco-

+0

こんにちはマルコ、 おかげさまで、デプロイメントシナリオに進むと、Octopusをもう少し詳しく見ていきます。 この質問のシナリオは、証明書(TLS相互認証)を使用してサービスコンシューマを認証することです。展開は懸念事項の1つですが、この特定の質問とは関係ありません:) – Erik

関連する問題