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.
    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

Popular posts from this blog

TLS Server Name Indication Extension and Unrecognized_name

Image
Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem , the ADT handshake alert , and the jarsigner issue with timestamp.geotrust.com , etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension. Background "Unrecognized_name" is an error alert, define by RFC4366 .  In section 4 of RFC4366 : - "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366 : If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). From above sections, we see that "unrecognized...
Read more

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider. The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989 , and was published in 1992 as an Informational RFC (RFC 1319) .; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown." Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation. You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in ...
Read more

JEP 115: AES-GCM CipherSuites in JDK 8

Image
Chengdu, China RFC 5288 describes the use of AES in Galois Counter Mode ( GCM ) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 ) providing both confidentiality and data origin authentication. Java SE had already defined the AES-GCM interfaces in Java SE 7 .  In the coming Java SE 8, as an implementation of JEP 115 , AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider. The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_...
Read more