現在、サーバーとクライアントで相互 SSL を有効にする際に問題があります。
サーバー側では、ClientAuth を有効にして tomcat を構成し、クライアントの証明書をトラストストアに構成します。
したがって、ssl ハンドシェイク中に、サーバーの証明書要求を確認できます。
[java] *** CertificateRequest
[java] Cert Types: RSA, DSS, ECDSA
[java] Supported Signature Algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
[java] Cert Authorities:
[java] <CN=https-test.domain.com, O=Domain.com, L= XX, ST=XX, C=US>
サーバーがサブジェクト識別名で証明書を要求していることがわかります。ただし、クライアント側では、クライアントがキーをフィルター処理するときに、DN を発行者 DN として扱います。コードはこちらを参照してください: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6- b14/sun/security/ssl/SunX509KeyManagerImpl.java#378
したがって、これは問題につながります：
[java] Warning: no suitable certificate found - continuing without client authentication
[java] *** Certificate chain
[java] <Empty>
[java] ***
そのため、握手は失敗しました。
証明書情報の一部を次に示します。
Issuer: DC=com, DC=domain, CN=Domain. com Security
Subject: C=US, ST=XX, L=XX, O=Domain.com, CN=https-test.domain.com
ここでの私の質問は、なぜサーバーはサブジェクト DN でクライアント証明書を要求するのに、クライアントは IssuerDN でフィルタリングするのですか?
それらが正常に接続できるようにするには、クライアントの親証明書を使用してサーバーのトラストストアを構成する必要があります。サブジェクト DN は発行者と同じになります: DC=com、DC=ドメイン、CN=ドメイン。com セキュリティ
これに関するアイデアはありますか？これについては誤解があるかもしれませんが、それでも理由を知りたいです。