jreinhartas400
asked on
Firefox sec_error_unknown_issuer
Can anyone tell me why Firefox browser issues the sec_error_unknown_issuer for url: https://www.customrater.com/hello.html Server team tells me Entrust certificate and the chain certificate are in place for server. No errors from other browsers such as IE . . . just Firefox.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I will again check with the server admin for the site to ensure the chain certificate is installed. They tell me the certificate is actually installed on the load balancer which sets in front of the two physical Web servers. This was done to eliminate having to purchase two certificates. Not sure if it contributes to the issue or not.
That's fine as long as it doesn't violate the licensing for the cert vendor - most are okay with doing that but some don't like it. They would need the whole chain installed on that load balancer then.
As a side note, if this is going to be sensitive information like PII or PCI, then hopefully they are using an internal certificate on the servers so they can encrypt the last hop between the server and the balancer, otherwise they may be in violation of policy/standards if the last hop is not encrypted.
As a side note, if this is going to be sensitive information like PII or PCI, then hopefully they are using an internal certificate on the servers so they can encrypt the last hop between the server and the balancer, otherwise they may be in violation of policy/standards if the last hop is not encrypted.
ASKER
One last question. . . what is meant by ". . the whole chain installed. . . "?
Often there is more than one CA certificate, especially from commercial vendors. There may be 2 or 3 (I've seen up to 5) CA's in the issuing chain before it gets to the "end entity" (e.g. SSL server, email user, etc.) certificate.
The following is somewhat common:
Root CA
-- Issuing CA
-- Your Server
In IE, there are two different CA trust stores - the root store and the intermediate store. So the Root CA would be in the root store of the server and clients, but the Issuing CA intermediate (aka subordinate) is not necessarily there since there may be multiple intermediate CA's under the same root (e.g. if a root certificate provider offers resellers the ability to resell certificates under its root). MS used to include intermediates but has stopped adding more to their program because the list just got too big - those that were already accepted are maintained but there will be no new members to that group like there are for the root certificates.
So each tier signs the next tier, and the client needs to validate that "chain" up to the top (the root) - if it cannot get the intermediate certs or does not trust the root then the chain gets broken during signature validation. In order to fix this, the client could install that intermediate cert, but that would be cumbersome, so it is typically the web server's responsibility to have the root and all intermediate certificates in the chain installed so it can provide them to the client. The digital signatures make it so the source is not as important since the signature is what is being validated - either it was issued from the root or it was not.
The following is somewhat common:
Root CA
-- Issuing CA
-- Your Server
In IE, there are two different CA trust stores - the root store and the intermediate store. So the Root CA would be in the root store of the server and clients, but the Issuing CA intermediate (aka subordinate) is not necessarily there since there may be multiple intermediate CA's under the same root (e.g. if a root certificate provider offers resellers the ability to resell certificates under its root). MS used to include intermediates but has stopped adding more to their program because the list just got too big - those that were already accepted are maintained but there will be no new members to that group like there are for the root certificates.
So each tier signs the next tier, and the client needs to validate that "chain" up to the top (the root) - if it cannot get the intermediate certs or does not trust the root then the chain gets broken during signature validation. In order to fix this, the client could install that intermediate cert, but that would be cumbersome, so it is typically the web server's responsibility to have the root and all intermediate certificates in the chain installed so it can provide them to the client. The digital signatures make it so the source is not as important since the signature is what is being validated - either it was issued from the root or it was not.
The problem is with the chain certificate. Firstly double and triple check the chain certificate is installed correctly. If your 100% sure, log a ticket with Entrust and they will most likely send you a new chain certificate that is trusted.