1Panel 版本：2.1.8
操作系统(设备)： debian13-x64
不知道为什么自签生成的fullchain.pem有三段，本来将签发机构导入windows受信任的根证书颁发机构可以网页访问了，但是在命令行抓数据的时候会报ssl错误，抓了下数据看了下
rewrite@debian:~$ openssl s_client -connect sub.debian.lan:443 -showcerts
Connecting to 192.168.5.15
CONNECTED(00000003)
depth=1 C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
verify return:1
depth=0 C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=debian.lan
verify return:1
Certificate chain
0 s:C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=debian.lan
i:C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
v:NotBefore: Apr 7 05:42:27 2026 GMT; NotAfter: Apr 7 05:42:27 2027 GMT
-----BEGIN CERTIFICATE-----
<域名证书内容>
-----END CERTIFICATE-----
1 s:C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
i:C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
v:NotBefore: Apr 7 05:31:59 2026 GMT; NotAfter: Apr 7 05:31:59 2036 GMT
-----BEGIN CERTIFICATE-----
<与签发证书ca.crt根证书内容一致>
-----END CERTIFICATE-----
2 s:C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
i:C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
v:NotBefore: Apr 7 05:42:27 2026 GMT; NotAfter: Apr 7 05:42:27 2027 GMT
-----BEGIN CERTIFICATE-----
<不知道什么根证书的内容>
-----END CERTIFICATE-----
Server certificate
subject=C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=debian.lan
issuer=C=CN, ST=Beijing, L=Beijing, O=FIT2CLOUD, OU=1Panel, CN=1Panel-CA
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: X25519, 253 bits
SSL handshake has read 2019 bytes and written 1642 bytes
Verification error: self-signed certificate in certificate chain
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 231AA4BBAFABA06F83CF72A11160124FCF71F59883EF0D78EC8A9FCF41EB95B9
Session-ID-ctx:
Resumption PSK: 4A3E8F9813D30DB5386BA3E7427F842608292F562196AAE374950EC2A2266168BA7846DD4941BD7B41B316E82D0DE358
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 600 (seconds)
TLS session ticket:
0000 - 43 5e 3d 44 2a 44 e4 fe-6e 3f 3f f2 65 31 90 d0 C^=DD…n??.e1…
0010 - ff 93 c8 52 e0 32 b6 ae-23 45 b8 ff 7a 70 d8 e4 …R.2…#E…zp…
0020 - 41 3f ef 16 c0 b1 59 71-75 7d 08 ed 7c 61 2a c5 A?..Yqu}…|a.
0030 - 52 e4 53 d1 f0 15 3e b4-a0 25 95 1c c7 9c 29 ef R.S…>…%…).
0040 - c3 e8 a5 d2 14 bc 9b 2a-5a 7f 68 5d 75 e3 25 a4 …*Z.h]u.%.
0050 - 3a ad 2d 94 3b 36 da 67-70 eb f8 15 c5 01 e6 71 :.-.;6.gp…q
0060 - ef d7 75 67 f2 18 ce 5c-3a 5b 6c 61 14 8f be 2d …ug…:[la…-
0070 - 48 8e 63 74 a9 61 cd b7-28 aa 6d 12 a1 cb 16 06 H.ct.a…(.m…
0080 - 7c 32 49 9e dd da 75 70-a0 21 0a 0c e3 02 19 64 |2I…up.!..d
0090 - 44 40 ff c2 14 86 b8 7a-77 f4 51 5a 55 36 6d 47 D@…zw.QZU6mG
00a0 - 28 dc cf f3 19 e8 8c fc-31 37 58 7a 56 76 c5 83 (…17XzVv…
00b0 - ff 55 25 cd 24 7c b2 86-67 ae 45 0b eb 68 ca 23 .U%.$|…g.E…h.#
00c0 - 58 6f 17 a9 31 81 ff 01-d2 c6 9b ee bc 48 ab c5 Xo…1…H…
00d0 - 18 74 fd ad a5 e0 b6 25-9c e1 1c 9f 19 24 9d 5a .t…%…$.Z
00e0 - a7 f0 84 f7 11 df 6a 48-d9 4c f8 63 ab 05 a7 87 …jH.L.c…
Start Time: 1775972925
Timeout : 7200 (sec)
Verify return code: 19 (self-signed certificate in certificate chain)
Extended master secret: no
Max Early Data: 0
read R BLOCK
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 3F9083FCD048CADB73B69E6FC5D132BF5B20290D0CA75E34DD4BCA5FBDA8C93B
Session-ID-ctx:
Resumption PSK: 81537596429BC75C71AEE8D3B8F93995FEDA4EA1C444B4C2C4966589C000D8D9353E59230C3E6C4653BFBB55C545B0A7
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 600 (seconds)
TLS session ticket:
0000 - 43 5e 3d 44 2a 44 e4 fe-6e 3f 3f f2 65 31 90 d0 C^=DD…n??.e1…
0010 - 41 85 39 96 8f de a0 7b-97 e3 6c eb a9 28 c1 65 A.9…{…l…(.e
0020 - 00 48 a2 43 8f f1 7f 93-e8 a2 e9 b1 e2 40 46 da .H.C…@F.
0030 - d9 23 d0 56 a8 89 2a 7f-da d9 9d 05 78 a4 0e 25 .#.V……x…%
0040 - 2c 77 07 be 9e 1b f1 70-ba 65 a5 76 81 0c 58 a6 ,w…p.e.v…X.
0050 - 04 ac 5d b1 1c 85 da c3-80 f1 67 e5 c7 12 7d a7 …]…g…}.
0060 - 0a a6 d5 e9 7f 63 a1 3b-b5 c9 5b 8b 83 72 7e 26 …c.;…[…r~&
0070 - aa a4 8a ec c1 04 b9 78-fc 63 92 c0 14 d0 f0 2f …x.c…/
0080 - 97 78 a3 f2 20 90 7e 0d-a4 a2 00 0d 68 af a0 65 .x… .~…h…e
0090 - f0 6f f1 82 bb ae 5e 8e-b8 5d 58 29 9c 89 74 00 .o…^…]X)…t.
00a0 - 3c eb 00 e1 a1 cc 7c a1-84 8b 98 a5 59 43 7a ae <…|…YCz.
00b0 - f0 bb f3 38 40 e6 8a 78-57 31 40 7c 0b 6b 13 b3 …8@…xW1@|.k…
00c0 - 2e 7a b2 42 f4 4a 5c ff-ff bc ff 6c d4 31 07 d7 .z.B.J.…l.1…
00d0 - a3 8b 0d f4 ef e8 b2 dc-73 28 e5 a8 de 47 75 98 …s(…Gu.
00e0 - a0 1f be d8 97 0d 76 a8-90 99 f8 b3 40 88 0e 30 …v…@…0
Start Time: 1775972925
Timeout : 7200 (sec)
Verify return code: 19 (self-signed certificate in certificate chain)
Extended master secret: no
Max Early Data: 0
read R BLOCK
DONE
rewrite@debian:~$
我把这三个证书保存并查看文本输出后，发现，0号证书是域名证书，1号证书和2号证书是根证书，1号证书的内容和面板下载的机构根证书ca.crt一致，但2号证书才是是0号证书真正的父证书，为什么会出现一个2？
可以看到0的X509v3 Authority Key Identifier:DB:A3:43:9D:45:DF:7D:35:63:76:7E:33:3B:D5:D7:CE:BC:DD:02:DA和2的 X509v3 Subject Key Identifier: DB:A3:43:9D:45:DF:7D:35:63:76:7E:33:3B:D5:D7:CE:BC:DD:02:DA一致但和1的X509v3 Subject Key Identifier: 1A:57:26:4C:B5:82:32:3D:58:5F:DF:09:FA:F6:8A:EA:7D:C2:60:49不一致