IIS7 – How to Fix Intermediate SSL Certificate Not Sending

certificateiisssl

We have a GlobalSign Domain certificate for our domain. I've installed the certificate into IIS and added the GlobalSign Domain Intermediate certificate to the Intermediate certification authorities for the local computer

It seems that IIS is not sending through the intermediate certificate (causing an error in firefox), just the domain certificate. I've verified this with OpenSSL and also various websites including GlobalSign's own health checker.

Looking In IIS, I can follow through the chain and each certificate is "ok", without the option to install any indicating they already are.

Any ideas on what may be wrong?

Best Answer

Finally managed to find a solution. For some reason, It must not of bound correctly in IIS. Removing and rebinding the certificate in IIS fixed the issue.

Related Solutions

SSL user authentication not working in Apache

Solved it. turns out it was a permissions problem:

I have set up a similar setting on a clean Debian Squeeze machine and it worked right from the start. The difference in debug output was:

[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 2, subject: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA 
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 0, subject: /CN=kettensaege@massaker.de/emailAddress=kettensaege@massaker.de, issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2

on the 'good' side, vs:

[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[error] [client 80.252.98.156] Certificate Verification: Error (20): unable to get local issuer certificate

on the 'bad' side.

The main difference between the two setups are the permissions for the /conf dir of the apache installation where the CA-certs reside. For security reasons we have the permissions set to 750 and the dir owned by root. Moving the CA files to a dir readable (or to be precise 'executable' to be used in path) made the problem disappear.

So it seems that though mod_ssl claims to read the certificates at server startup it still needs access to the hashed files while running (and having dropped it's root privileges).

Ssl – openssl s_client reports certificate OK, but other clients report problems

Turned out there was a repeated certificate in the chain. openssl doesn't mind that, but gnutls does - and svn uses gnutls (as does LDAP and mutt, in case they are your problem). Here is the gnutls-cli command (for Ubuntu/Debian systems at least):

$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 www.aptivate.org

Though you can see the chain with either gnutls or openssl. In the openssl output from above you can see there is a repeated certificate.

Certificate chain
 0 s:/O=*.aptivate.org/OU=Domain Control Validated/CN=*.aptivate.org
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
 1 s:/O=*.aptivate.org/OU=Domain Control Validated/CN=*.aptivate.org
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
 4 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com

For gnutls to validate this, the i: (issuer) of each item in the chain must match the s: (subject) of the next item.

In this case I had put the certificate in it's own file, and put it in the chain file. So 0i did not match 1s. This was enough to make svn reject the certificate.

Any bad ordering causes this problem. So if you had 2 and 3 the wrong way around you would get validation errors.

Best Answer

Related Solutions

SSL user authentication not working in Apache

Ssl – openssl s_client reports certificate OK, but other clients report problems

Related Topic