The coleman2021.cer
certificate is issued by GeoTrust RSA CA 2018
. From this certificate, I cannot see if that is a root, or an intermediate (I think I remember that this is an intermediate, but I’m not sure).
So, the Spark keystores are completely empty, with one exception. The ‘truststore’ contains one certificate, the one for *.coleman.ru
. It just contains that one certificate. The other certificates from the chain are not in the Spark truststore.
One thing to note is that, when evaluating the certificate chain that is offered by your Openfire server, Spark will also use the truststore(s) provided by the JRE. These will be combined with the truststores that are provided by Spark itself. I do not know what is in the JRE truststore on your computer.
Adding the *.coleman.ru
certificate to the Spark truststore is not expected to make a difference (except for when you mark it as ‘exempt’, in which case it should always be accepted, I think), for this reason: When validating the certificate chain that is provided by the Openfire, Spark will discard the root CA from the chain that is provided by the Openfire server (if the root CA is part of that chain - it does not need to be). It will then try to ‘complete’ the chain again, using certificates that it knows it can trust (because they are in the truststores of Spark or the JRE). So, what Spark needs to have in its (or the JREs) truststore, is the root CA that (directly or indirectly) issued *.coleman.ru
So, when the certificate chain that is offered by your Openfire server is being validated by Spark, Spark will try to (re)construct a ‘path’ from the end-entity certificate that is in the chain (*.coleman.ru
) to a root certificate (the one that issued GeoTrust RSA CA 2018
). We can see that this root is not in the Spark truststore. My guess is that it is also not in the JRE truststore. This is why validation fails.
Because of the failure of the validation, Spark asks if you want to add the certificate as an ‘exception’ (so that it always will be accepted). Since the end-entity certificate is already in the truststore (but not ‘excepted’), Spark doesn’t actually add it. This might be considered a bug, but that needs to have some further analysis.
To rule out a different issue with certificate validation, it might be good to know if Spark will accept your servers certificate chain after you removed the *.coleman.ru
from Spark’s truststore. If you can then login (without Spark prompting you to add the certificate), then a) the root CA certificate is in the JRE store, and b) Spark has a bug (because it didn’t use it before).
If, after removing the *.coleman.ru
certificate from Sparks truststore Spark prompts you to add it, then I expect Spark to add it to the ‘exception’ store, and allow you to log in afterwards.
Another thing to test (and possibly the ‘correct’ way to configure your Spark) is to add (only) the root CA (instead of the *.coleman.ru
) to Spark’s truststore. Spark should then allow you to login, without prompting you for anything.