I'm trying to install a GoDaddy SSL certificate on IIS, but Google Chrome still reports ERR_CERT_AUTHORITY_INVALID. The IIS download included a .crt, a .pem, and gd_dc-r1-g2_iis_intermediates.p7b. The CSR was created years ago on another machine, but I still have the original private key. I created a PFX with OpenSSL, imported it into IIS, and bound it to the site. I also imported the available R1 and G2 certificates into the server's certificate stores and restarted IIS and the VM. IIS appears to show the complete chain, but Chrome still rejects the certificate, and external testing indicates that the chain ends at the R1 certificate. Could this be caused by GoDaddy's Starfield cross-signed chain, an incorrectly selected intermediate, or IIS failing to send the proper intermediate certificates? What is the correct way to build and install the PFX and certificate chain?
4 Answers
Importing a root certificate into the server’s intermediate store does not necessarily fix what remote browsers receive. Verify the binding, hostname, SNI settings, expiration, and the chain presented over the network rather than relying only on the IIS certificate viewer. If the external checker shows that IIS is not sending the intermediate, install the intermediate in the Local Computer intermediate store and rebind the PFX. Also test from a clean client because Chrome may have cached an earlier chain.
Make sure the PFX was built from the private key that matches the CSR used for this certificate. You can verify that by comparing the public key or modulus from the certificate and key with OpenSSL. The P7B is a certificate bundle, not a private key, and can be imported into Windows or converted to PEM certificates for use with OpenSSL. A typical command is `openssl pkcs12 -export -out site.pfx -inkey site.key -in site.crt -certfile intermediates.crt`, where `intermediates.crt` contains the appropriate GoDaddy intermediate certificates.
GoDaddy’s newer certificates can involve the Starfield hierarchy and cross-signed roots. Different clients build that chain differently, which can make Chrome fail even when the certificate looks complete in IIS. Check the certificate actually being served with an external TLS checker, then remove obsolete or cross-signed copies from the server and configure IIS to send the current intermediate chain. The server should normally send the leaf certificate plus intermediates; clients provide the trusted root.
This kind of failure has also appeared with GoDaddy certificates issued through Starfield. If the correct intermediate chain is installed and the key matches but Chrome still fails, the practical fix may be to use the exact current Starfield intermediate bundle supplied for that certificate or replace the certificate with one from another issuer. An online chain checker is useful because it shows precisely where validation stops.

Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures