Is root certificate in the trust store enough to establish a connection?

Asked 1/12, 2019 at 12:2 Answered 10/2, 2022 at 23:59

Is having the root certificate in truststore enough for establishing the connection with a website? If so, just to test, I've imported the root certificate of google to new trust store which I have created and pointed to that trust store. Even then I am getting the following exception. javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

But if I try to connect to google using default java trust store then it's working fine. Can someone please help me with this? TIA.

Cultured answered 1/12, 2019 at 12:2 Comment(13)

The entire certificate chain is needed – Moonwort 1/12, 2019 at 12:9

@Saptarshi Basu If that's the scenario, then I'm able to make the connection using java truststore cacerts, which contains just the root CA. Can you please explain me how this is working? – Cultured 1/12, 2019 at 12:44

This will help you understand: https://mcmap.net/q/1479442/-ssl-pining-how-can-a-public-key-ca-on-a-device-check-the-server-39-s-certificate . The operating system and Java already provide the complete chain of Globally accepted CA certificate chains – Moonwort 1/12, 2019 at 13:34

@Saptarshi Basu But if look into the ssl certificate of google website the chain length is 3. Out of which the only the root certificate is present in the java cacerts, the intermediate certificate and website certificates are not, then how the java cacerts able to validate the google certificate? I don't find any difference between the java cacerts and the truststore which I created, because both contains the root certificate. Then why is java cacerts is working where as my truststore is failing? – Cultured 1/12, 2019 at 13:37

The chain is not needed @SaptarshiBasu Using one of the certificates within the chain above google's certificate is enough. If you also want to verify the subject alternative name field, than you require the chain. – Heinz 2/12, 2019 at 0:44

@SaptarshiBasu That's not correct. Any certificate in the chain sent by the server will do in the truststore.The cacerts file contains just a set of trusted root certificates. – Astolat 2/12, 2019 at 1:6

@OP The issue here is probably that you aren't using the truststore you think you're using. Show your code, specifically how you are configuring the truststore. Run your client with -Djavax.net.debug=ssl,trustmanager,handshake and show the results. – Astolat 2/12, 2019 at 1:6

And why can't you use the built-in cacerts? – Astolat 2/12, 2019 at 1:13

@SaptarshiBasu What you state is not only incorrect but impossible. 'KeyStore.TrustedCertificateEntry: This type of entry contains a single public key Certificate belonging to another party.' See the Javadoc. – Astolat 2/12, 2019 at 3:47

@user207421. As you said may be i haven't added properly to the trust store I've created. So, I created a new truststore and added the root CA certificate and now its working fine, thank you. – Cultured 2/12, 2019 at 16:41

@SaptarshiBasu You haven't 'clarified' them at all. You have posted an answer containing completely different information, which flatly contradicts your comments above. – Astolat 3/12, 2019 at 0:50

@Astolat I said certificate chain is required for verification and I stand by it. But I'm happy to leave it here. – Moonwort 3/12, 2019 at 1:17

You said 'the entire certificate chain is needed' for a question which is about a truststore containing a single certificate, and which is not about how the server is configured. If you didn't mean the entire chain has to be in the truststore you should have said so when challenged, and in any case it's irrelevant because the server will deliver the chain unless misconfigured. And you're still wrong; see comment on your answer. – Astolat 3/12, 2019 at 1:32

I just tried out to build a https get request for google.com. Loaded GlobalSign certificate. Google's certificate is signed by this CA, so the ssl handshake should pass. Below is the code what I used and it works.

    @Test
    public void callGoogleWithRootCA() throws IOException, KeyStoreException, CertificateException, NoSuchAlgorithmException, KeyManagementException {
        String trustStorePath = "keystores-for-unit-tests/truststore.jks";
        String trustStorePassword = "secret";

        KeyStore trustStore;

        try(InputStream keystoreInputStream = this.getClass().getClassLoader().getResourceAsStream(trustStorePath)) {
            if (isNull(keystoreInputStream)) {
                throw new RuntimeException(String.format("Could not find the keystore file with the given location %s", trustStorePath));
            }

            KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
            keystore.load(keystoreInputStream, trustStorePassword.toCharArray());
            trustStore = keystore;
        }

        TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
        trustManagerFactory.init(trustStore);

        SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
        sslContext.init(null, trustManagerFactory.getTrustManagers(), null);

        HttpsURLConnection connection = (HttpsURLConnection) new URL("https://www.google.com").openConnection();
        connection.setSSLSocketFactory(sslContext.getSocketFactory());
        connection.setRequestMethod("GET");
        String responseBody = IOUtils.toString(connection.getInputStream(), StandardCharsets.UTF_8);
        int responseCode = connection.getResponseCode();

        assertThat(responseCode).isEqualTo(200);
    }

See here the specific certificate in the keystore file:

I couldn't upload the keystore file here, but this is the pem file I used for importing the certificate to a new keystore:

During the handshake process I am getting the following information:

javax.net.ssl|DEBUG|01|main|2019-12-02 01:29:04.529 CET|CertificateMessage.java:358|Consuming server Certificate handshake message (
"Certificates": [
  "certificate" : {
    "version"            : "v3",
    "serial number"      : "75 20 46 4B 8D AC DC 10 08 00 00 00 00 1D 8A 52",
    "signature algorithm": "SHA256withRSA",
    "issuer"             : "CN=GTS CA 1O1, O=Google Trust Services, C=US",
    "not before"         : "2019-11-05 08:46:45.000 CET",
    "not  after"         : "2020-01-28 08:46:45.000 CET",
    "subject"            : "CN=www.google.com, O=Google LLC, L=Mountain View, ST=California, C=US",
    "subject public key" : "EC",
    "extensions"         : [
      {
        ObjectId: 1.3.6.1.4.1.11129.2.4.2 Criticality=false
      },
      {
        ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
        AuthorityInfoAccess [
          [
           accessMethod: ocsp
           accessLocation: URIName: http://ocsp.pki.goog/gts1o1
        , 
           accessMethod: caIssuers
           accessLocation: URIName: http://pki.goog/gsr2/GTS1O1.crt
        ]
        ]
      },
      {
        ObjectId: 2.5.29.35 Criticality=false
        AuthorityKeyIdentifier [
        KeyIdentifier [
        0000: 98 D1 F8 6E 10 EB CF 9B   EC 60 9F 18 90 1B A0 EB  ...n.....`......
        0010: 7D 09 FD 2B                                        ...+
        ]
        ]
      },
      {
        ObjectId: 2.5.29.19 Criticality=true
        BasicConstraints:[
          CA:false
          PathLen: undefined
        ]
      },
      {
        ObjectId: 2.5.29.31 Criticality=false
        CRLDistributionPoints [
          [DistributionPoint:
             [URIName: http://crl.pki.goog/GTS1O1.crl]
        ]]
      },
      {
        ObjectId: 2.5.29.32 Criticality=false
        CertificatePolicies [
          [CertificatePolicyId: [2.23.140.1.2.2]
        []  ]
          [CertificatePolicyId: [1.3.6.1.4.1.11129.2.5.3]
        []  ]
        ]
      },
      {
        ObjectId: 2.5.29.37 Criticality=false
        ExtendedKeyUsages [
          serverAuth
        ]
      },
      {
        ObjectId: 2.5.29.15 Criticality=true
        KeyUsage [
          DigitalSignature
        ]
      },
      {
        ObjectId: 2.5.29.17 Criticality=false
        SubjectAlternativeName [
          DNSName: www.google.com
        ]
      },
      {
        ObjectId: 2.5.29.14 Criticality=false
        SubjectKeyIdentifier [
        KeyIdentifier [
        0000: 63 55 73 A0 9D C3 D5 FA   3C 1A 17 EA 0B 72 AB EF  cUs.....<....r..
        0010: D3 15 15 BB                                        ....
        ]
        ]
      }
    ]},
  "certificate" : {
    "version"            : "v3",
    "serial number"      : "01 E3 B4 9A A1 8D 8A A9 81 25 69 50 B8",
    "signature algorithm": "SHA256withRSA",
    "issuer"             : "CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2",
    "not before"         : "2017-06-15 02:00:42.000 CEST",
    "not  after"         : "2021-12-15 01:00:42.000 CET",
    "subject"            : "CN=GTS CA 1O1, O=Google Trust Services, C=US",
    "subject public key" : "RSA",
    "extensions"         : [
      {
        ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
        AuthorityInfoAccess [
          [
           accessMethod: ocsp
           accessLocation: URIName: http://ocsp.pki.goog/gsr2
        ]
        ]
      },
      {
        ObjectId: 2.5.29.35 Criticality=false
        AuthorityKeyIdentifier [
        KeyIdentifier [
        0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
        0010: DC 19 86 2E                                        ....
        ]
        ]
      },
      {
        ObjectId: 2.5.29.19 Criticality=true
        BasicConstraints:[
          CA:true
          PathLen:0
        ]
      },
      {
        ObjectId: 2.5.29.31 Criticality=false
        CRLDistributionPoints [
          [DistributionPoint:
             [URIName: http://crl.pki.goog/gsr2/gsr2.crl]
        ]]
      },
      {
        ObjectId: 2.5.29.32 Criticality=false
        CertificatePolicies [
          [CertificatePolicyId: [2.23.140.1.2.2]
        [PolicyQualifierInfo: [
          qualifierID: 1.3.6.1.5.5.7.2.1
          qualifier: 0000: 16 1C 68 74 74 70 73 3A   2F 2F 70 6B 69 2E 67 6F  ..https://pki.go
        0010: 6F 67 2F 72 65 70 6F 73   69 74 6F 72 79 2F        og/repository/

        ]]  ]
        ]
      },
      {
        ObjectId: 2.5.29.37 Criticality=false
        ExtendedKeyUsages [
          serverAuth
          clientAuth
        ]
      },
      {
        ObjectId: 2.5.29.15 Criticality=true
        KeyUsage [
          DigitalSignature
          Key_CertSign
          Crl_Sign
        ]
      },
      {
        ObjectId: 2.5.29.14 Criticality=false
        SubjectKeyIdentifier [
        KeyIdentifier [
        0000: 98 D1 F8 6E 10 EB CF 9B   EC 60 9F 18 90 1B A0 EB  ...n.....`......
        0010: 7D 09 FD 2B                                        ...+
        ]
        ]
      }
    ]}
]
)
javax.net.ssl|DEBUG|01|main|2019-12-02 01:29:04.566 CET|X509TrustManagerImpl.java:242|Found trusted certificate (
  "certificate" : {
    "version"            : "v3",
    "serial number"      : "04 00 00 00 00 01 0F 86 26 E6 0D",
    "signature algorithm": "SHA1withRSA",
    "issuer"             : "CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2",
    "not before"         : "2006-12-15 09:00:00.000 CET",
    "not  after"         : "2021-12-15 09:00:00.000 CET",
    "subject"            : "CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2",
    "subject public key" : "RSA",
    "extensions"         : [
      {
        ObjectId: 2.5.29.35 Criticality=false
        AuthorityKeyIdentifier [
        KeyIdentifier [
        0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
        0010: DC 19 86 2E                                        ....
        ]
        ]
      },
      {
        ObjectId: 2.5.29.19 Criticality=true
        BasicConstraints:[
          CA:true
          PathLen:2147483647
        ]
      },
      {
        ObjectId: 2.5.29.31 Criticality=false
        CRLDistributionPoints [
          [DistributionPoint:
             [URIName: http://crl.globalsign.net/root-r2.crl]
        ]]
      },
      {
        ObjectId: 2.5.29.15 Criticality=true
        KeyUsage [
          Key_CertSign
          Crl_Sign
        ]
      },
      {
        ObjectId: 2.5.29.14 Criticality=false
        SubjectKeyIdentifier [
        KeyIdentifier [
        0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
        0010: DC 19 86 2E                                        ....
        ]
        ]
      }
    ]}
)

So back to your issue, probably your keystore is not loaded. Could you validate if your keystore file is not null?

Heinz answered 2/12, 2019 at 0:35 Comment(1)

Thank you, it's working fine now, I tried by creating the new trust store. – Cultured 2/12, 2019 at 16:43

Here is a more detailed answer on how it works:

During the TLS handshake process, the server sends a certificate list forming a chain. In TLS 1.2 RFC 5246, it is explained as:

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.

The root of the certificate is always self-signed and for a globally accepted root CA (Certificate Authority), the certificate is stored in the client platform (viz. Mozilla, MacOS, Java, Android, Windows etc.). Therefore the server need not send this certificate.

The same RFC also mentions:

Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA.

In other words, the platform implementation will traverse down certificate chain and keep verifying the certificates until it hits a certificate that is in the trust store. Any certificate that is present in the trust store will not be verified and will be assumed as a trusted certificate.

This is mentioned in TLS 1.3 RFC 8446 as:

Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Absent a specific indication from an application profile, certificates should always be verified to ensure proper signing by a trusted certificate authority (CA). The selection and addition of trust anchors should be done very carefully. Users should be able to view information about the certificate and trust anchor.

It further says:

The signatures on certificates that are self-signed or certificates that are trust anchors are not validated, since they begin a certification path

Now, in case of Google, if we test the server in https://www.ssllabs.com/, we can see that the certificates www.google.com and GTS CA 101 are sent by the server, whereas GlobalSign certificate is present in the trust store of the platform.

Hope this clarifies my earlier comments.

Moonwort answered 2/12, 2019 at 17:32 Comment(2)

This isn't correct either. It doesn't have to be the root certificate. The ClientHello message contains the trusted issuers, and the server only has to send that part of its chain that terminates with a certificate signed by the trusted issuer. The trusted issuer doesn't have to be the root of the chain. It could for example be the server's own certificate. – Astolat 3/12, 2019 at 1:33

@Astolat if you just read past that paragraph, you'd have seen that mentioned as well where it says 'it traverses down the chain until it hits a certificate that is in the trust store' – Moonwort 3/12, 2019 at 1:37

sorry bit TLDR for Saptarshi Basu answer. here in my laymen terms

if you trust store only has the root cert the server must send the chain
if your trust store has the chain (so including the intermediate cert) the server can only send it's issued cert

Troubleshoot with https://gist.github.com/4ndrej/4547029#file-sslpoke-java and openssl (it uses the OS cert store)

openssl version -d
openssl s_client -connect google.com:443 -showcerts

Nicki answered 10/2, 2022 at 23:59 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags