Best Practice: to Include the Complete Certificate Chain in the KeyStore
Let's start from an example. Considering the following certification path, TrustAnchor issues IntermediateCert, and IntermediateCert issues EndEntiryCert.
In practice, I noticed that some smart card vendor may only import the end entity certificate into the store [1]. That is to say, for this example, the smart card only store EndEntiryCert. To build a certification path, the application will have to find a way to retrieve the intermediate certificate. It's not always easy for the application programmers. Yes, I have to say, it is possible, but it does not sound like the worthwhile effort.
Let's consider another example that we use the smart card as the key store of TLS communication. When client authentication is required, the TLS server may require the client offer a valid certificate issued by a certificate authority, "CN=TrustAnchor, OU=Example.COM". When client receive the message, if the smart card stores the intermediate certificate, IntermediateCert, it's fairly easy to build a certification path to the required certificate authority:
However, if the smart card does not store the intermediate certificate, IntermediateCert, the client would not be able to find a proper certification path to the certificate authority, "CN=TrustAnchor, OU=Example.COM". Hence, the server may terminate the TLS handshaking, and close the connection.
It is very simple to store the intermediate certificates in the key store (or smart card), for both of the smart card vendor or the application administrator. And it is a lot of complicated to have the application looking around to find where is the lost intermediate certificates, if it cannot find them in the key store. It does not sound like the worthwhile effort.
It is recommended that if one certification path consists of any intermediate layers, we had better store the intermediate certificates in the key store (or smart card) as a part of the complete certification path. Otherwise, it would be the potential interoperability problem.
Note [*]: Trusted certificates may only be set by token initialization application. The smart card vendor had better import the complete certificate chain during burning the card.
[1]: Handshake failure with PKCS11 token
TrustAnchor
| Subject: CN=TrustAnchor, OU=Example.COM
V Issuer : CN=TrustAnchor, OU=Example.COM
IntermediateCert
| Subject: CN=Intermediate, OU=Example.COM
V Issuer : CN=TrustAnchor, OU=Example.COM
EndEntiryCert
Subject: CN=EndEntiry, OU=Example.COM
Issuer : CN=Intermediate, OU=Example.COM
In practice, I noticed that some smart card vendor may only import the end entity certificate into the store [1]. That is to say, for this example, the smart card only store EndEntiryCert. To build a certification path, the application will have to find a way to retrieve the intermediate certificate. It's not always easy for the application programmers. Yes, I have to say, it is possible, but it does not sound like the worthwhile effort.
Let's consider another example that we use the smart card as the key store of TLS communication. When client authentication is required, the TLS server may require the client offer a valid certificate issued by a certificate authority, "CN=TrustAnchor, OU=Example.COM". When client receive the message, if the smart card stores the intermediate certificate, IntermediateCert, it's fairly easy to build a certification path to the required certificate authority:
EndEntiryCert (Stored in Smart Card)
^ Subject: CN=EndEntiry, OU=Example.COM
| Issuer : CN=Intermediate, OU=Example.COM
IntermediateCert (Stored in Smart Card)
^ Subject: CN=Intermediate, OU=Example.COM
| Issuer : CN=TrustAnchor, OU=Example.COM
TrustAnchor (The Server Recognized Certificate Authority)
Subject: CN=TrustAnchor, OU=Example.COM
However, if the smart card does not store the intermediate certificate, IntermediateCert, the client would not be able to find a proper certification path to the certificate authority, "CN=TrustAnchor, OU=Example.COM". Hence, the server may terminate the TLS handshaking, and close the connection.
EndEntiryCert (Stored in Smart Card)
^ Subject: CN=EndEntiry, OU=Example.COM
| Issuer : CN=Intermediate, OU=Example.COM
X
^
|
TrustAnchor (The Server Recognized Certificate Authority)
Subject: CN=TrustAnchor, OU=Example.COM
It is very simple to store the intermediate certificates in the key store (or smart card), for both of the smart card vendor or the application administrator. And it is a lot of complicated to have the application looking around to find where is the lost intermediate certificates, if it cannot find them in the key store. It does not sound like the worthwhile effort.
It is recommended that if one certification path consists of any intermediate layers, we had better store the intermediate certificates in the key store (or smart card) as a part of the complete certification path. Otherwise, it would be the potential interoperability problem.
Note [*]: Trusted certificates may only be set by token initialization application. The smart card vendor had better import the complete certificate chain during burning the card.
[1]: Handshake failure with PKCS11 token
