SSLHandshakeException: bad_certificate. Server log: SEC_ERROR_REUSED_ISSUER_AND_SERIAL

[Nope Torres]

Our Java Swing + Visual Basic APP let users authenticate against server with SSL connection. Now two user in the same entity client sharing a smart card suddenly encounter a problem: they cannot connect to the server with Java part, but with VB modules it is normal.

This error occurs suddenly; I suspect some server modifications; but only Java part cannot connect, VB part works normally. (VB modules connect to same URL)

This error only occurs with certs of one issuer.


I use these lines to configure my keystore and the context: (I don't use cacert as the truststore; I have my own)

myKeyStore = KeyStore.getInstance("Windows-MY", "SunMSCAPI");
myKeyStore.load(null, null);

// KEYSTORE
KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance("SunX509");
keyManagerFactory.init(myKeyStore, "".toCharArray());

AliasKeyManager akm = new AliasKeyManager(myKeyStore, sAlias, "");
KeyManager[] managers = new KeyManager[] { akm };

// TRUSTSTORE
KeyStore trustStore = KeyStore.getInstance("JKS");
InputStream tsis = new FileInputStream(Constantes.AUT_CERTIFICACION_FILE);
trustStore.load(tsis, Constantes.AUT_CERTIFICACION_PWD.toCharArray());
tsis.close();

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

context = SSLContext.getInstance("SSL");
context.init(managers, trustManagerFactory.getTrustManagers(), new SecureRandom());
if (sf == null)
    sf = context.getSocketFactory();
con.setSSLSocketFactory(new SecureSSLSocketFactory(sf, this));

At the end of ssl debug information, I see these lines:

Thread-7, READ: TLSv1.1 Alert, length = 2
Thread-7, RECV TLSv1.1 ALERT:  fatal, bad_certificate
%% Invalidated:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
Thread-7, called closeSocket()
Thread-7, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

At server side, I see this line in the log:

[07/Jul/2017:13:33:18] failure ( 3354): HTTP3068: Error receiving request from xx.xxx.xx.xxx (SEC_ERROR_REUSED_ISSUER_AND_SERIAL: Attempting to import a cert which conflicts with issuer/serial of existing cert.)

I have searched a lot, but found only related issues with Firefox, not Java. They normally delete cert8.db to fix this in FF, but my case is different.


Where can I start to find the cause of it? I don't understand the part of "importing", import what? Into where? Where is the conflict? May I have a book explaining this thoroughly?

[Matt Wong]

Well, I tried a quick Google search - and it seems that there is some sort of cache and that there somehow two different certificates with the same serial.
I'm not a security expert - but I think this can't be solved by clearing the unknown cache but rather to revoke the problem certificates an issue some new ones with new, different, serials.

[Nope Torres]

Matt Wong wrote:Well, I tried a quick Google search - and it seems that there is some sort of cache and that there somehow two different certificates with the same serial.
I'm not a security expert - but I think this can't be solved by clearing the unknown cache but rather to revoke the problem certificates an issue some new ones with new, different, serials.

Thanks for your reply. Actually I should stress that this problem occurs after our server admin deleted some SHA1 certificate. At server side we have ANCERT cert of SHA1 and SHA256 at the same time in truststore, with the same serial number. They think that SHA1 are not safe so they eliminated them and now user have problem. Does it have something to do with the certificate cache you mentioned? I don't find anything about this information.

The user cert has this structure: Ancert Root  -> ancert sub-root -> user cert. I thought it was because sub root and root are SHA1 certs and in the server truststore they now only have SHA256 cert with same serial number, so the bad-certificate problem. But I am wrong, because I then examined the user cert of another affected user (reported later), and I see that in his chain, the root and sub-root are both SHA256; if my guess stands, he would not be affected.


If you can post some links about the cache problem I will be very appreciated.

[Nope Torres]

ANCERT is the issuer of the user/sub-root/root cert.

[Nope Torres]

@Matt Wong just in case..... if no notification via quote was sent.

[Tim Moores]

if no notification via quote was sent.

It is being sent regardless of the content of the post.

[Nope Torres]

Tim Moores wrote:

if no notification via quote was sent.

It is being sent regardless of the content of the post.

Thanks.

Now I seem to understand why. Before this, can I ask a question? When in Windows, with MSCAPI provider, how does Java build the user cert chain? Just loading the cert in the cert file, or looking up the chain in the Windows Internet Explorer cert store?

[Matt Wong]

Well, if your cert-chain got destroyed and you're unable to re-create it, then I guess you have to build a new one starting by creating a new root key-pair and a new root certificate. Otherwise, if there're multiple certificates under the same root identified by the same serial number you're trust chain is broken and can't be used anymore. That's what this error message is about.

[Nope Torres]

Matt Wong wrote:Well, if your cert-chain got destroyed and you're unable to re-create it, then I guess you have to build a new one starting by creating a new root key-pair and a new root certificate. Otherwise, if there're multiple certificates under the same root identified by the same serial number you're trust chain is broken and can't be used anymore. That's what this error message is about.

Thanks Wong, I really appreciate your answer. You are correct about the broken chain, but there is another way to solve this problem.

I have posted this question in stackoverflow.com, and finally (like many other questions that I posted there), I solved it by myself, so I think it is not considered as cross-posting; I didn't waste others' effort/time/labour to a extend that they could solve it for me.

In short, the chain can be restored by deleting the SHA1 root cert in the IE trust store, leaving only the SHA256 root cert; Java seems to pick the chain directly from IE trust store and the first it sees is the first it picks up to build it; but unfortunately, the SHA1 comes first and with that, we have a broken chain because at server side, SHA1 is deleted; what makes the situation worse, is that these two has the same serial number; so the conflict.

VB code didn't break, because Microsoft implementation of certificate engine has a better way of picking the chain: build all chain, verify them all and pick the best to send to server. I guess it sees the two possibilities: with SHA1 and SHA256, and by its own standard, it thinks the latter is better and always sends it, so the error never happens for VB code. This is my guessing.

All details are in this post:

https://stackoverflow.com/questions/45507285/sslhandshakeexception-after-deleting-sha1-cert-received-fatal-alert-bad-certif/45836082#45836082

This has been tested in the user machine and the result is as expected, proving my theory.