sec_error_unknown_issuer

delmartime.secured-ecommerce.net uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

This is the wildcard certificate which configuration we have been using for years. We renewed it yesterday and had to swap it out. Now we are having these firefox problems.

The users httpd.conf contains this.

SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
SSLCACertificateFile /usr/local/directadmin/data/users/delmartime/domains/delmartimes.com.cacert
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

The certificate was correctly put into server.crt.
The key was correctly put into server.key
The content of the ca-bundle comodo sent me with the cert is in the delmartimes.com.cacert file. Everything checks out and after a server reboot.... (Error code: sec_error_unknown_issuer)

Is DA bypassing the ca-bundle somewhere? This is the server wide wildcard using the server shared IP. Has worked great for many years, but obviously no more.

Server ssl log reports a little differently.
[21/Dec/2010 22:24:44 09895] [error] SSL handshake failed (server localhost:443, client 74.93.163.38) (OpenSSL library error follows)
[21/Dec/2010 22:24:44 09895] [error] OpenSSL: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

Running latest DA and custombuild, but Apache 1.3.

Any help greatly appreciated.

BigWil

Check to make sure the CA file is really available at the location to which your SSLCACertificateFile directive is pointing. Make sure the ownerships, rights, etc., are such that it can be found.

Failing that, get Comodo support involved.

Jeff

@Jeff
Apache wouldn't start if CA file was not readable.

@BigWil
I think, you need to check OpenSSL installation. And re-compile apache, if OpenSSL was updated just after apache was installed.

zEitEr said:

Apache wouldn't start if CA file was not readable.

Click to expand...

Perhaps I wasn't as clear as I should have been. If the pointer to the Cert pointed to a file contained the wrong CACert, or if the line didn't exist at all, apasche wuld start.

But yes, I agree, I'm taking a leap.

Once everything is double-checked I'd still say get Comodo support involved.

We troubleshoot installations when Certificates are bought from us; Comodo should be willing to do that for their clients as well.

Jeff

The error


as I recollect can be caused by double installation of different versions of OpenSSL library. It was possible to install OpenSSL from customapache script (disappeared from custombuild). So if you've got one copy from yum/pkg/ports and other version installed from sources. There can be such a mess.

Thanks guys. I actually did get Comodo involved. I ended up not using the Premium Legacy Wildcard and went to the Premium Wildcard instead and it worked fine. I still have a suspicion that the ca-bundle is being ignored and that it is chaining up with the browser embedded root certs instead. That's why firefox was having an issue because the correct root for the Premium Legacy wasn't found in Firefox but it was in the others. The newer non-legacy chains up in all the browsers since the correct root for those IS found there.

I think this is an issue only with the shared server wide cert. Individual customer certs on their own IP seem to act fine. I'm getting ready to make the jump from Apache 1.3 to 2.x finally. So instead of tracking the issue down now I'm just going to do it under the 2.x in the coming year. Everything seems to be working at the moment.

Thanks for the suggestions.

Wil