問題描述
.net 添加了客戶端證書，但仍收到無效證書 (.net added client certificate but still recieve an invalid certificate)
我用 SSL/TLS 做了一個小的客戶端服務器示例。當我在一台機器上測試它時一切正常，但是當我在另一台機器上擁有我的服務器時，我的客戶端被撤銷。
基本上，客戶端創建一個證書（SelfSigned），我將其複製到服務器。現在服務器將此證書存儲在他的受信任證書中，但是當我嘗試連接到我的服務器時，我被吊銷了。
X509Store^ store = gcnew X509Store(StoreName::Root, StoreLocation::LocalMachine); //windows Truststore!
store‑>Open(OpenFlags::ReadWrite);
store‑>Add(cert);
store‑>Close();
我可以看到這有效，因為證書在我受信任的根證書中，但是當我嘗試為了連接到我的服務器，他給了我一個證書列表（來自 RFC 的 certificate_authorities），而剛剛添加的證書不是其中之一。
我使用以下代碼啟動服務器：
TcpClient^ client = serverSocket‑>AcceptTcpClient();
SslStream^ sslStream;
sslStream = gcnew SslStream(client‑>GetStream(), false);
sslStream‑>AuthenticateAsServer(cert, true, SslProtocols::Tls, true);
authenticateServer 部分是我得到的地方
System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
我從調試中得到的是，在與他請求客戶端證書的部分握手時一切正常（客戶端在 java 中，所以這是 java 調試）
*** ServerHello, TLSv1
RandomCookie: GMT: 1449660634 bytes = { 128, 20, 156, 73, 60, 13, 107, 144, 124, 0, 148, 240, 5, 94, 16, 14, 25, 189, 27, 55, 27, 185, 101, 236, 44, 8, 144, 97 }
Session ID: {229, 66, 0, 0, 90, 25, 188, 202, 203, 197, 32, 150, 47, 124, 255, 204, 43, 45, 239, 205, 144, 194, 235, 58, 116, 90, 125, 192, 127, 44, 131, 95}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized: [Session‑14, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
** TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[read] MD5 and SHA1 hashes: len = 81
0000: 02 00 00 4D 03 01 56 68 11 DA 80 14 9C 49 3C 0D ...M..Vh.....I<.
...
0050: 00 .
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: C=C, ST=ST, L=L, O=O, OU=OU, CN=Server
Signature Algorithm: SHA512withRSA, OID = 1.2.840.113549.1.1.13
Key: Sun RSA public key, 2048 bits
modulus: 1808...291064931634275033537
public exponent: 65537
Validity: [From: Wed Dec 09 10:01:12 CET 2015,
To: Fri Dec 09 10:01:12 CET 2016]
Issuer: C=C, ST=ST, L=L, O=O, OU=OU, CN=Server
SerialNumber: [ 2ad334c8 74494189]
]
Algorithm: [SHA512withRSA]
Signature:
0000: 2A 69 12 08 ED 38 75 B9 DD 63 FE E3 2B 20 52 E3 *i...8u..c..+ R.
...
00F0: FB D5 FC EB F2 63 24 A4 AD F9 31 31 CE A8 02 6A .....c$...11...j
]
***
Found trusted certificate:
[
[
Version: V3
Subject: C=C, ST=ST, L=L, O=O, OU=OU, CN=Server
Signature Algorithm: SHA512withRSA, OID = 1.2.840.113549.1.1.13
Key: Sun RSA public key, 2048 bits
modulus: 18081618984...264273424659291064931634275033537
public exponent: 65537
Validity: [From: Wed Dec 09 10:01:12 CET 2015,
To: Fri Dec 09 10:01:12 CET 2016]
Issuer: C=C, ST=ST, L=L, O=O, OU=OU, CN=Server
SerialNumber: [ 2ad334c8 74494189]
]
Algorithm: [SHA512withRSA]
Signature:
0000: 2A 69 12 08 ED 38 75 B9 DD 63 FE E3 2B 20 52 E3 *i...8u..c..+ R.
...
00F0: FB D5 FC EB F2 63 24 A4 AD F9 31 31 CE A8 02 6A .....c$...11...j
]
[read] MD5 and SHA1 hashes: len = 880
0000: 0B 00 03 6C 00 03 69 00 03 66 30 82 03 62 30 82 ...l..i..f0..b0.
...
3FB0: 65 20 6C 61 20 41 62 6F 67 61 63 69 61 e la Abogacia
ReadThread2, READ: TLSv1 Handshake, length = 16317
*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Cert Authorities:
<EMAILADDRESS=info@netlock.hu, CN=NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado, OU=Tanusitvanykiadok, O=NetLock Halozatbiztonsagi Kft., L=Budapest, C=HU>
... //all certifications my server trust but the client certificate aint one of them
<CN=Autoridad de Certificacion de la Abogacia, O=Consejo General de la Abogacia NIF:Q‑2863006I, C=ES>
[read] MD5 and SHA1 hashes: len = 16317
0000: 0D 00 3F B9 03 01 02 40 3F B3 00 CC 30 81 C9 31 ..?....@?...0..1
...
3FB0: 65 20 6C 61 20 41 62 6F 67 61 63 69 61 e la Abogacia
[Raw read]: length = 5
0000: 16 03 01 00 04 .....
[Raw read]: length = 4
0000: 0E 00 00 00 ....
ReadThread2, READ: TLSv1 Handshake, length = 4
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
Warning: no suitable certificate found ‑ continuing without client authentication
*** Certificate chain
<Empty>
***
*** ECDHClientKeyExchange
ECDH Public value: { 4, 196, 28, 72, 78, 63, 148, 184, 247, 70, 246, 4, 21, 150, 30, 45, 74, 174, 199, 152, 153, 149, 232, 117, 118, 155, 206, 122, 168, 135, 155, 250, 130, 128, 35, 109, 198, 246, 95, 24, 150, 55, 162, 118, 227, 205, 207, 54, 147, 163, 44, 112, 167, 136, 21, 126, 34, 98, 157, 205, 44, 117, 143, 213, 85 }
[write] MD5 and SHA1 hashes: len = 77
0000: 0B 00 00 03 00 00 00 10 00 00 42 41 04 C4 1C 48 ..........BA...H
...
0040: A7 88 15 7E 22 62 9D CD 2C 75 8F D5 55 ...."b..,u..U
ReadThread2, WRITE: TLSv1 Handshake, length = 77
[Raw write]: length = 82
0000: 16 03 01 00 4D 0B 00 00 03 00 00 00 10 00 00 42 ....M..........B
...
0050: D5 55 .U
SESSION KEYGEN:
PreMaster Secret:
0000: AD 6C 40 88 86 19 1C 0B 76 67 9E 67 00 65 F2 5F .l@.....vg.g.e._
0010: 8B C7 87 1D B6 77 66 1E 96 47 49 CC 29 F1 EF 3E .....wf..GI.)..>
CONNECTION KEYGEN:
Client Nonce:
0000: 56 68 11 DE 90 96 ED 7F AC 28 50 1B 83 59 E5 50 Vh.......(P..Y.P
0010: 23 C5 A2 6D 59 B6 42 AF 78 DB 0A 7C FF A6 EF D7 #..mY.B.x.......
Server Nonce:
0000: 56 68 11 DA 80 14 9C 49 3C 0D 6B 90 7C 00 94 F0 Vh.....I<.k.....
0010: 05 5E 10 0E 19 BD 1B 37 1B B9 65 EC 2C 08 90 61 .^.....7..e.,..a
Master Secret:
0000: AE 80 BB 88 5C 64 65 98 FA A6 5C 9F 01 1D 2B 39 ....\de...\...+9
...
0020: 1D D9 6D 04 98 98 03 80 F9 9C 91 ED 9A F5 E9 F9 ..m.............
Client MAC write Secret:
0000: 05 84 E0 18 90 80 E0 D9 BC 52 13 49 29 E0 56 18 .........R.I).V.
0010: 31 D0 A2 CF 1...
Server MAC write Secret:
0000: 19 9B 99 44 55 59 CD 11 52 9B 5F BE 38 34 01 2E ...DUY..R._.84..
0010: E2 67 0C C8 .g..
Client write key:
0000: 78 0E 20 84 70 87 8D 81 F7 DF 02 BD EC 1C C3 7D x. .p...........
Server write key:
0000: 57 F6 B1 47 A6 57 83 68 F2 28 54 92 03 8A 17 C7 W..G.W.h.(T.....
Client write IV:
0000: DA F9 8E 8E 10 0C 21 EC BB 63 AC 16 2C 33 B1 9A ......!..c..,3..
Server write IV:
0000: 7A 18 E2 2F 4D AD 1D 01 7F 68 A5 CF 6D FC 84 8A z../M....h..m...
ReadThread2, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01 ......
*** Finished
verify_data: { 9, 94, 87, 61, 94, 171, 69, 203, 42, 71, 108, 59 }
***
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C 09 5E 57 3D 5E AB 45 CB 2A 47 6C 3B .....^W=^.E.*Gl;
Padded plaintext before ENCRYPTION: len = 48
0000: 14 00 00 0C 09 5E 57 3D 5E AB 45 CB 2A 47 6C 3B .....^W=^.E.*Gl;
...
0020: 6E DA 09 6B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B n..k............
ReadThread2, WRITE: TLSv1 Handshake, length = 48
[Raw write]: length = 53
0000: 16 03 01 00 30 0D 0B CE 0B 65 78 2F 19 2D EC 2A ....0....ex/.‑.*
...
0030: 52 96 52 F8 49 R.R.I
[Raw read]: length = 5
0000: 14 03 01 00 01 .....
[Raw read]: length = 1
0000: 01 .
ReadThread2, READ: TLSv1 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 01 00 30 ....0
[Raw read]: length = 48
0000: 60 52 C2 47 73 E3 B6 65 36 CE A3 A9 FC 60 0C 7F `R.Gs..e6....`..
...
0020: DE 06 62 17 FA 9C 22 FE 1E E5 2A C0 88 21 3E BC ..b..."...*..!>.
ReadThread2, READ: TLSv1 Handshake, length = 48
Padded plaintext after DECRYPTION: len = 48
ReadThread, handling exception: java.net.SocketException: Connection reset
所以要一切都很簡短：
如何讓我的服務器信任客戶端證書並將其包含在 certificate_authorities 列表中。我可以讓我的服務器不發送 certificate_authorities 列表嗎？
參考解法
方法 1:
I have found a working solution. Appearently there is a bug in Windows Server.
I just told the Server not to send a Trusted Client CA list since this is not critical for my application (Workaround Method 3). Since this is just a Workaround, note that this only applies to the given Enviroment.