why does cert store contain *multiple* copies same Intermediate SSL Cert?
Hello,
Two questions I hope you all can help us with:
1. What are the circumstances under which a server would fail to provide the Intermediate to the browser? One can say "misconfigured server," but do others have experience with some typical cases where Firefox can't get the Intermediate from a server and figured out why. In researching this issue of "missing Intermediate" (not sending down the Chain or Intermediate). We think the problem is on the server side and we have asked the application developer will look into why his app isn't sending down the Intermediate. But with their development deadlines, they may not get to it soon. I thought some on this forum might have seen past examples or conditions under which Firefox was not given the Intermediate by the server. So this is a little general, but if you have past examples, I'd love to know.
2. From working on the above issue, we came up with a question that is the kind of the opposite: how does it come to pass that on some of our workstations the FireFox certificate store sometimes contains multiple copies of the below (and other) Intermediate Certs:
"Entrust Certification Authority - L1K Software Security Device"
We'd like to understand the mechanism by which multiple (2-3) identical lines / copies of the L1K Intermediate SSL Cert end up in Certificate Manager. Why are there the duplicates? If I understand correctly, if a Software Security Device (Intermediate SSL Cert) is not in the Cert store, the server will provide the chain (or is it just the intermediate?) to FireFox and Firefox will install that Intermediate (since it already has the Root, which for this L1K intermediate cert is Entrust G2, and thus can trust L1K). On maybe 20-30% of the Firefox installs we checked, they have more than one line entry for L1K. They don't seem to be causing any problem, we are mainly curious to know the whys of the appearnce/installation of multiple copies of the same SSL Intermediate Cert.
For both we tested on a bunch of Windows 10 (some Win 7) workstations running mostly between FFox 56-60, with some very few on FFox 48 or older. The "not getting an Intermediate SSL cert" issue does not seem to depend upon the version of the Windows workstation or of FireFox, we think it is server side hence my request for the experiences of others where this happened to them, under what case/situations.
thank you,
Alain
Solution choisie
During the initial handshake, well before the webapp runs, and without asking the browser, the server should send a site certificate and a bundle of 1 or more intermediate certificates needed to verify that the site certificate was issued under the authority of a trusted root certificate.
- If the intermediate cert checks out, Firefox will cache it for future reference. (A Refresh, or manually removing the cert9.db/cert8.db file, will clear the accumulated certs.)
- If an intermediate certificate is not sent, but Firefox already has it in its store, then the omission is not fatal. However, unlike other browsers, Firefox never tries to retrieve missing intermediate certificates from issuers' websites.
So it is luck of the draw -- based on your previous browsing -- whether you will get an incomplete chain error when the server fails to send one.
To verify that the server sends a complete chain, you can test using https://www.ssllabs.com/ssltest/.
(1) The problem would be in the server's SSL configuration, most likely, a required file available from the certificate issuer is missing from a particular folder.
(2) Certificate names apparently do not need to be unique if they have different serial numbers. Example attached of the 3 Entrust L1K certs my Firefox has accumulated.
Lire cette réponse dans son contexte 👍 0Toutes les réponses (3)
Solution choisie
During the initial handshake, well before the webapp runs, and without asking the browser, the server should send a site certificate and a bundle of 1 or more intermediate certificates needed to verify that the site certificate was issued under the authority of a trusted root certificate.
- If the intermediate cert checks out, Firefox will cache it for future reference. (A Refresh, or manually removing the cert9.db/cert8.db file, will clear the accumulated certs.)
- If an intermediate certificate is not sent, but Firefox already has it in its store, then the omission is not fatal. However, unlike other browsers, Firefox never tries to retrieve missing intermediate certificates from issuers' websites.
So it is luck of the draw -- based on your previous browsing -- whether you will get an incomplete chain error when the server fails to send one.
To verify that the server sends a complete chain, you can test using https://www.ssllabs.com/ssltest/.
(1) The problem would be in the server's SSL configuration, most likely, a required file available from the certificate issuer is missing from a particular folder.
(2) Certificate names apparently do not need to be unique if they have different serial numbers. Example attached of the 3 Entrust L1K certs my Firefox has accumulated.
Hello and thank you for your helpful reply.
> the server should send a site certificate > and a bundle of 1 or more intermediate certificates . . . > If the intermediate cert checks out, Firefox will cache it for future reference. Agreed, this works on all our other servers using the Entrust L1K Intermediate, just not on the Peoplesoft (PSoft) server.
> manually removing the cert9.db/cert8.db file Perhaps our testing was incomplete, but we found it was enough to remove the L1K from Certificate Manager and retry. With all servers except the PSoft, it gets the Chain fine and automatically adds back in the L1K. PSoft fails with untrusted SSL cert.
> If an intermediate certificate is not sent, but Firefox already > has it in its store, then the omission is not fatal. That is also our observation. We can pre-seed the L1K by going to a working server, then hitting the PSoft server works.
> So it is luck of the draw Isn't it server malfunction? All our internal servers with L1K properly repopulate the cert store with the L1K except this one PSoft server. Our work-around pending a fix is to send users to an internal L1K website, FFox then gets the L1K and user can immediately go to PSoft server with no SSL error.
> To verify that the server sends a complete chain, you can test using > https://www.ssllabs.com/ssltest/. The server in question is only accessible internally. But you gave me the idea to instead use openssl to check the cert chain:
openssl s_client -showcerts -servername example.com -connect example.com:12300 </dev/null
This returns only 1 SSL cert, not the chain and returns this error at the bottom: "Verify return code: 21 (unable to verify the first certificate)" Other working SSL servers polled with openssl return the root, intermediate (L1K), and cert and a return code of 0.
> (2) Certificate names apparently do not need to be unique if they > have different serial numbers. Thanks for the image of the 3! I also just learned about duplicate L1K's from Entrust's support. One L1K intermediate cert is the current G2 -> L1K. Another goes from the EV Legacy root to G2 to L1K (a different one). I don't have the third but Entrust confirmed all 3 are valid.
thanks again for your help,
Alain
evenalain said
> So it is luck of the draw
Isn't it server malfunction? All our internal servers with L1K properly repopulate the cert store with the L1K except this one PSoft server. Our work-around pending a fix is to send users to an internal L1K website, FFox then gets the L1K and user can immediately go to PSoft server with no SSL error.
I think most likely it's a missing file on the server, but it could be a malfunction. I'm not a server guy.