Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am at a loss as to what else I might try in order to debug this issue with a Starfield Wildcard SSL Certificate.

The problem is that in certain browsers (Safari or the most-updated chrome you can get for OS X 10.5.8 for example) the certificate comes up as untrusted, even on the root domain.

My server setup / background info:

  • General LAMP setup - CentOS 6.3 - on a Godaddy VPS
  • Starfield Technologies Wildcard SSL certificate
  • Installed using the instructions from godaddy's support pages
  • ssl.conf lines are basically as follows:

    SSLCertificateFile /path/to/cert/mysite.com.cert
    SSLCertificateKeyFile /path/to/cert/mysite.key
    SSLCertificateChainFile /path/to/cert/sf_bundle.crt

Everything seemingly worked fine until the other night when I noticed the problem in OS X, I assume it's more browser version related, but have only been able to replicate it on that particular machine.

What I have tried:

  • Updating sf_bundle.crt from godaddy's cert repository and Starfield's repository versions
  • Following This ServerFault answer from Jim Phares - changing the ChainFile line to sf_intermediate.crt from Starfield's repository
  • Using http://www.sslshopper.com/ssl-checker.html on my url
    • It says the domain is correctly listed on the certificate but comes up with an error that reads The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate.

What might I try next to remedy the untrusted certificate issue?

Let me know if there is any other information needed that might help debugging this issue. Thanks in advance!

Solution:

My problem ended up being that I had forgotten to add the SSLCertificateChainFile line to the virtual host(s) in my httpd.conf and had only been editing those lines in ssl.conf instead, thanks for all the suggestions!

share|improve this question
    
Did you come across this? serverfault.com/questions/85737/… –  cjc Nov 7 '12 at 22:25
    
here is a starfield cert that's working ok on the page you referenced; sslshopper.com/ssl-checker.html#hostname=mail.omniweb.com my guess is something with your configuration options. fwiw in my ssl.conf the "/path/to/cert/mysite.com.cert" is wrapped in "quotes" and my keyfile is a ".pem" not a ".key" –  user16081 Nov 7 '12 at 22:41
    
@cjc yes I did see that post and tried that but it didn't seem to have any effect. –  Austen Cameron Nov 7 '12 at 23:13
    
@user16081 Thanks for the link, I will try to dig deeper within ssl.conf configuration and see if I can come up with anything. Out of curiosity are you on a godaddy VPS too, or centOS 6 at least? –  Austen Cameron Nov 7 '12 at 23:15
    
CentOS 5, not hosted on Godaddy –  user16081 Nov 8 '12 at 15:03

1 Answer 1

up vote 5 down vote accepted

Two things you can do:

  1. Verify the intermediate chain
  2. Clean up the intermediate chain

Verify the intermediate chain

As the error seems to indicate, there is something off about your intermediate certificate chain. You should check where you got your certificate from and that you got the correct intermediate bundle.

You should verify the "hash" and "issuer's hash" of every certificate in the chain with the openssl x509 -noout -hash and openssl x509 -noout -issuer_hash commands. Try this to get the issuer hash of your certificate:

cat /path/to/cert/mysite.com.cert | openssl x509 -noout -issuer_hash

Then try to find a certificate with this hash in the sf_bundle.crt file that you specified as SSLCertificateChainFile. You may have to extract the certificates (or just copy paste them to the command):

cat first_cert_from_sf_bundle.crt | openssl x509 -noout -hash

Check all of them. If none have this hash, then something is wrong right there. Keep doing these checks until you find a certificate which has the same -hash and -issuer_hash. This is your root certificate.

If something is missing, you can check the other intermediate files here https://certs.starfieldtech.com/anonymous/repository.seam. Download these and compare their -hash against the -issuer_hash where you got stuck.

If everything is okay, then ....

Clean up the intermediate chain

I have seen this also help when you get odd validation errors. Make sure that your intermediate chain lists only the required certificates and in the correct order (it is easier if it is in PEM format). In other words, if your chain is Your cert -> cert A -> cert B -> Starfield Root cert. Try appending these in this order (you can skip the first and last) so your intermediate chain looks something like this:

-----BEGIN CERTIFICATE-----
cert A
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
cert B
-----END CERTIFICATE-----

I personally like to keep all these certificates (personal certificate, followed by intermediate ones, followed by the root certificate) in the same file. Then I just specify this file as both the SSLCertificateFile and SSLCertificateChainFile.

share|improve this answer
    
Thank you for your reply! I have checked the intermediate chain (sf_bundle.crt) and found the same hash as mysite.com.crt inside it. I split the sf_bundle into two files for testing (there were two certs in there) and found that only one hash matched the -issuer_hash. The order (within sf_bundle.crt) was Cert A -> Cert B with cert A being the hash-matched certificate. I have tried swapping the order of these and nothing seems to change with the SSL checker. I apologize for my limited SSL experience, perhaps you could clarify cleaning up the certificates? Thanks. –  Austen Cameron Nov 8 '12 at 16:31
    
I marked this as the correct answer because you were so helpful. I had ensured the SSL config lines were correct in my ssl.conf file, but forgot that I needed the SSLCertificateChainFile line within the virtual host in httpd.conf... so that ended up being the problem. –  Austen Cameron Nov 8 '12 at 19:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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