Resolve the Public Keys in Reply and Keystore Don't Match Error in Java

1. Error Description, Causes, and Possible Solutions to the Public Keys in Reply and Keystore Don't Match Error
2. Resolve the Public Keys in Reply and Keystore Don't Match Error in Java

Today’s tutorial discusses the keytool error: java.lang.Exception: Public keys in reply and keystore don't match error. It also highlights the possible reasons that result in this error.

Further, we will learn about the different solutions we can use to fix this error.

Error Description, Causes, and Possible Solutions to the Public Keys in Reply and Keystore Don't Match Error

We will try to access the web service hosted at port 443. The service provider shared three certificates: ABCD.cer, CCA_Certificate.cer, and CA_Certificate.cer.

We are required to add all of them to the KeyStore via creating a form chain for the SSL communication. The steps we followed from this article are given below in sequential order.

At this point, we got the error saying keytool error: java.lang.Exception: Public keys in reply and keystore don't match. What is this error all about? Why are we having this issue?

We get this problem for different reasons that are listed below:

1. We get this error when we try to generate a certificate with a different key pair.
2. This error occurs if we have used the same alias while importing a certificate and creating the JKS store.
3. Sometimes, installing certificates in the wrong order also results in this error.
4. We also go through this issue if the Root CA’s certificate is missing from the chain.

Now, the point is how to eradicate it. Let’s see that in the following section.

Resolve the Public Keys in Reply and Keystore Don't Match Error in Java

In our scenario, the link we were using guides how we can create an SSL KeyStore for the server, which is not what we want to achieve. What we did was start with creating new key pair.

Next, we added a trusted certificate to KeyStore, added another trusted certificate to KeyStore, and then we tried to import the server’s SSL certificate for our key pair.

At this point, we are failing because the generated SSL certificate is for an entirely different key pair. The three certificates that we have, include the following:

1. The web service’s SSL certificate
2. A CA certificate that signed SSL certificate
3. A root certificate that signed a CA

Now, we have to add the trust anchor to our TrustStore. By default, it is ${JAVA_HOME}/jre/lib/security/cacerts, with the outcome that our client accepts the SSL certificate of a web service.

Remember, during the SSL handshake, the SSL server sends an entire chain, excluding the root certificate, to a client. So, we must add a root certificate to our truststore as follows.

keytool -import -keystore ${JAVA_HOME}/jre/lib/security/cacerts -file CCA_Certificate.cer -alias CCARoot

Some additional steps are essential if a web service needs SSL client authentication. If we have never mentioned client authentication, then this is unnecessary.

This is how the error is fixed in our case, but there are other solutions we can try if we are in a different situation.

1. We need to generate the certificate again using the same actual key pair to eliminate this error.
2. There are some situations where the error is caused by using the same alias while creating the JKS store and importing the certificate. Then, we need to change the alias to resolve the error.
3. Make sure that the Root CA’s certificate is not missing from the chain.