1

As part of an internal Client/Server application, I have created my own (self-signed) Certificate Authority (CA), as well as both Client and Server certificates signed by my CA.

Loading my CA certificates into FireFox in PEM format is relatively easy. Creating an HTTPS server in Go using my Server certificates is also (relatively) easy.

However my ultimate goal is to use double ended TLS where both the client and server authenticate each other.

To do this I must load my client certificate/key and my CA's public certificate/key into my browser.

Unfortunately FireFox and Chromium will not load PEM formated client certificates. They will only load client certificate/key bundles in the PKCS#12 format.

Each time I tried, FireFox (v73 on XUbuntu 19:10) refused to load my PKCS#12 by saying that there was a (general) format problem.

I know that my PKCS#12 file is formatted correctly since I am able to use the openssl pkcs12 -info command to correctly read the contents of my PKCS#12 file.

Both FireFox and Chromium use libnss3 to manage their x509 certificates. After many searches I finally noticed discussion on the web about how to use the certutil and pk12util libnss3-tools to interact with FireFox's cert9.db certificate database.

Using these two tools to try and load my PKCS#12 file I stumbled upon the "SEC_ERROR_REUSED_ISSUER_AND_SERIAL" error. The pk12util command provided the additional (helpful) message:

You are attempting to import a cert with the same issuer/serial as an
existing cert, but that is not the same cert.

So: What are the sources of “SEC_ERROR_REUSED_ISSUER_AND_SERIAL” errors when using self-signed x509 Certificates in PKCS#12 files?

2
  • Hi Stephen, welcome to security stackexchange! The format of the Stack Exchange network is a little different than blog posting sites; it's really designed around a question and answer model. It would fit the site better if you would rephrase this into a question someone else might ask; then you can post your solution as an answer to that question. – John Deters Mar 5 '20 at 19:26
  • 1
    @JohnDeters many thanks for your welcome and suggestion. I have attempted to break my submission into a more open ended question (there might be other answers) together with one particular answer. Over the years I have developed a deep respect for the StackExchange family of websites, but alas have never been focused on one area long enough to build up enough of a reputation to provide any answers... hence I was worried that I might not be able to answer my own question. It seems that I was mistaken.... it is good to learn new things. Again many thanks for your welcome. – Stephen Gaito Mar 7 '20 at 15:12
1

Here is the answer that I stumbled upon... there might be other answers, or work-arounds... if so, it would be good to collect them here.

After some struggle, I finally realized that the two certificates that pk12util was referring to were my client and my CA certificates (as bundled in the same PKCS#12 file). Both were signed by the same issuer (my CA) and both had been accidentally been given the same serial number in my Certificate Requests.

One of my problems while trying to understand this problem, has always been the fact that I could not find any "duplicate" certificates in the FireFox certificate database (either through the FireFox browser or using the certutil tool). Of course, in hindsight, the reason was simple, the two (conflicting) certificates had not yet been loaded into the certificate database, but were instead in my PKCS#12 file.

After recreating my CA, Server and Client certificates carefully making sure that each had a different serial number, I was able to load my PKCS#12 file, and more importantly I was able to have my client (browser) and (Go) server authenticate each other.

A complete working example of a Go based Certificate Authority with certificate creation as well as mutually authenticating client/server applications can be found on GitHub diSimplex / ConTeXtNursery.

I hope this question/answer helps others who have this same sort of problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.