I'm trying to install a GoDaddy SSL certificate on IIS, but 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. GoDaddy's instructions refer to a certificate bundle .crt file, while the IIS package provides a .p7b instead. I used OpenSSL to create a PFX from the certificate, private key, and a GoDaddy PEM bundle, then imported the R1 and G2 certificates into the server's certificate stores. The certificate is bound to the IIS site, and IIS Manager displays the complete chain, but Chrome still rejects it. Reboots and restarting IIS made no difference. The chain appears to terminate at the R1 certificate. What is the correct chain and certificate-store setup for this GoDaddy certificate?
4 Answers
This may be related to GoDaddy’s Starfield hierarchy and its cross-signed roots. Some clients handle the R1/G2 chain differently, so having certificates visible in IIS Manager does not necessarily mean the server is sending the correct chain to clients. Check the certificate with an external TLS checker to see exactly what IIS is presenting, then remove obsolete or cross-signed copies from the server and install only the current GoDaddy intermediate chain needed by the issued certificate. The root certificate generally should not be sent by the server; clients are expected to trust it locally.
The .p7b is a certificate bundle, not a private-key container. You can open it in Windows or convert/extract its certificates with OpenSSL, but it cannot replace the private key. For IIS, the normal result should be a PFX containing the leaf certificate and matching private key. Install the intermediate certificates in the local computer Intermediate Certification Authorities store, bind the PFX to the site, and test the live endpoint externally. Do not rely only on the chain shown inside IIS Manager, because that view can include certificates installed locally that are not actually being served.
Make sure the PFX was created with the private key that belongs to this exact certificate. The fact that the CSR was generated on another machine is not a problem as long as the original key is the matching one. You can verify the modulus or public key of the certificate and key with OpenSSL before rebuilding the PFX. If they do not match, IIS may import the certificate but cannot use the intended private key correctly.
The PFX was created with the old key stored elsewhere, using OpenSSL. That key should be checked against the renewed certificate rather than assuming it is the matching one.
Importing a root certificate into the intermediate store—or installing every available R1 and G2 certificate indiscriminately—can create an incorrect chain. Identify the issuer of the leaf certificate and follow that exact issuer path. Remove duplicate, expired, or cross-signed versions, then rebuild the PFX and rebind it. Chrome may expose the problem even when other applications use a different trust store or cached chain.
I ran into the same behavior after a renewal. The certificate was issued through Starfield, and installing the matching Starfield intermediate/root chain fixed it on some systems. An online chain checker helped identify which certificate was actually missing.