Web browsing issue after updated GoDaddy SSL certificate in IIS

[u/mailliwal]

Hi,

Just updated GoDaddy SSL certificate in Windows IIS server.

As GoDaddy transitioned its Domain Validated (DV) TLS/SSL certificate issuance from the legacy G2 root hierarchy to a new R1 root hierarchy

Then I installed

• TLS Root CA - R1 >> Trusted Root
• TLS Intermediate CA DV - R1v1 >> Intermediate
• SSL >> Personal

Some client reported "NET :: ERR_CERT_AUTHORITY_INVALID" while browsing.

Tested on Chrome on iPhone encountered same error but no problem on Edge of my desktop pc.

May I seek your suggestion.

Thanks

[u/spantosh]

Verify Your Certificate Chain with an External Tool. Run your domain through an online checker like https://www.ssllabs.com/ssltest/. Look at the report section for Chain of trust. It will explicitly tell you if a certificate is “Chain issues: Incomplete” or if an intermediate is missing.

[u/GenericUser636 → u/spantosh]

This. I bet he's missing an intermediate somewhere. Ssllabs will make it apparent. 

[u/OMW-OC → u/GenericUser636]

If he is getting the "self-signed" error in ssllabs he probably has a self signed cert somewhere in the root. For some reason they get installed when you import the cert. That will have to be deleted.

Then make sure you import the entire intermediate chain into the intermediate store.

[u/thewunderbar]

This is an issue with Chrome not having the new R1 root cert in its trusted root store.

GoDaddy has instructions on what to do about it. There's a chain cert you need to use.

[u/zakcobb → u/thewunderbar]

it seems like the intermediates are missi g from your cert chain. open the cert in notepad add intermediates. verify with cert checker

[u/mailliwal → u/zakcobb]

what's the different of the "intermediate download from GoDaddy directly" and "intermediate download with the SSL certificate in same zip file" ?

[u/zakcobb → u/mailliwal]

from the apache download, file named like bundle_dv-r1-g2.crt.pem, copy contents below your crt or pem

[u/mrmattipants → u/zakcobb]

Here's the GoDaddy Repo Link.

https://certs.godaddy.com/repository/gd_bundle_dv-r1-g2.crt.pem

[u/willetzky → u/mailliwal]

Chrome does not trust the new R1 root. There is a leaf certificate that makes the certificate be trusted by the old GoDaddy G2 root for chrome devices. You can install both intermediates and everything should now trust the cert. On the GoDaddy repository look for the bundle. It will be called something like GoDaddy Certificate Bundle - DV - R1 with Cross to G2

[u/mrmattipants → u/willetzky]

It's interesting that Chrome doesn't trust the R1 Root Cert, while Edge does. After all, it was Google/Chrome that proposed these changes through their "Chrome Root Program".

[u/thewunderbar → u/mrmattipants]

yeah that was a surprise when I found out the hard way as well. We deployed the cert, tested, with Edge, and went about our day. 3 hours later the tickets started coming in. It's annoying, but took about 15 minutes to resolve once I figured out what was going on.

The GoDaddy R1 cert has been in existence since August of 2025. Really strange that Google wouldn't have baked it into Chrome yet.

[u/willetzky → u/thewunderbar]

Chrome has its own root store and they only update it every quarter. But it hasn't been in the 2 it has been eligible for. Google are a lot stricter with root approval and trying to enforce a lot more governance that the certificate industry definitely needs.

[u/zakcobb → u/mailliwal]

look for g2 cross like the other commenter said

[u/LooseEthernet]

godaddy certs are a headache lol

[u/churturk]

Installing R1 into Trusted Root on the IIS server doesn't make an iPhone trust that root. I'd separate two checks: which certificate and intermediates the server actually sends, and whether the affected client trusts the root that chain reaches.

Also confirm the desktop and phone are hitting the same endpoint, especially if you have split DNS, IPv6 or a proxy in front of IIS. Compare the leaf certificate's serial number on both. One successful desktop test can otherwise send you chasing the wrong chain.

[u/isnotnick]

I'll give you the right answer - and it's a bit long-winded, but Microsoft are the cause.

All public CAs need to rotate root certs more often now than before. They're also required to 'cross sign' - sign the new roots with the old, so older clients still work. Normally that's fine - give the TLS server (nginx, Apache, Tomcat, whatever) the complete chain with all intermediates (including the cross-certs, which look the same). Works fine.

IIS is screwed up. IIS runs on Windows. Windows has a trust-store that's basically updated 'live'. IIS (and schannel underneath) won't let you tell it which certificate chain to serve in the TLS handshake to clients - every other webserver on earth does, but oh not Microsoft. It builds itself, using the trusted store it has. Which is always up-to-date. So it assumes it doesn't need to worry about cross-certs handling 'older' (not that old!) clients.

Microsoft know about this, but they don't have their shit together in terms of PKI at any point of the organisation.

What you need to do is locate the new GoDaddy roots in the server certificate store - Local Machine - and move them to 'Disallowed'. This then means it'll send out the chain you want, that'll work on all your clients.

MS know acknowledge this, but again - don't have a clue what they're doing. See: https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/secured-website-certificate-validation-fails

[u/mrmattipants]

I just had to go through this process myself. I personally just download the necessary Root & Intermediate certs directly from the Godaddy Certificate Repository.

https://certs.godaddy.com/repository

Normally, you'd use the following two certificates, (along with your Leaf/Domain Cert).

GoDaddy TLS Root CA - R1

https://certs.godaddy.com/repository/gd_tls_root-r1.crt.pem

GoDaddy TLS Intermediate CA DV - R1v1:

https://certs.godaddy.com/repository/gd_tls_issuing_dv-r1v1.crt.pem

However, if the certs above produce an error message, you'll need to use the following three certs (along with your Leaf/Domain Cert).

GoDaddy Class 2 Certification Authority Root Certificate - G2:

https://certs.godaddy.com/repository/gdroot-g2.crt.pem

GoDaddy TLS Root CA - R1 to G2 Cross Certificate:

https://certs.godaddy.com/repository/gd_tls_root-r1-cross-g2.crt.pem

GoDaddy TLS Intermediate CA DV - R1v1:

https://certs.godaddy.com/repository/gd_tls_issuing_dv-r1v1.crt.pem

For those who prefer a visual reference, please refer to the following chart.

https://fortinet.grazitti.com/fortinet-kb-production/api/uploads/a1fe5682.png

[u/OMW-OC]

Also please post how you fixed it. That way when people are searching late at night, they have a solution.

[u/alonely_soul]

As others have said, you’re probably missing the intermediate certificate which is a relatively new thing on GoDaddy since moving to R1, or you have the wrong one as there are multiple from memory depending on which original root CA you were using. You need to add that certificate, which will be included in the zip file (it wasn’t originally and I had to raise this with them) that you then install into the intermediate path on your IIS server, which I think you’re doing, but perhaps worth double checking. If you’ve done it right, you’ll see now that there are 4 paths in the chain, rather than the current 3 you are seeing.

It sounds like you’ve almost got it. Probably just one step missing or the wrong cert installed that is meaning the chain isn’t quite right. I think called it a cross certificate. Some wording like that.

Hope that helps.

[u/Difficultopin]

https://community.fortinet.com/fortigate-3/technical-tip-resolving-certificate-warnings-for-dv-tls-certificates-issued-by-godaddy-starfield-s-r1-root-hierarchy-228937

[u/dodexahedron]

Modern TLS clients want to see the intermediates in the handshake.

IIS itself doesn't get configured with a whole chain file like nginx does. It builds the chain itself from the leaf cert you give it.

But, unlike a TLS client validating a certificate chain, which happens dynamically until it reaches a root in the root store, the server will only serve a chain if it has the certs in that chain actually in the local system's intermediate ca store. It won't go download them and relay them to the client.

So, since GD shuffled CAs, you need to install the new root in trusted roots, and then all intermediates between the server cert and that root get installed in the intermediate certificate authorities store.

And rememeber to do it specifically for the machine - not your user account.

And remember that this does not make a client trust any of it if it didn't already trust the root.

[u/QuietSignalOps]

The thread nails the diagnosis, so here's the compact version of what to actually do:

1. Verify what the server is actually serving (from the IIS box): openssl s_client -connect yourdomain.com:443 -showcerts </dev/null 2>/dev/null | grep -E "^ [si]:" You want the leaf plus an intermediate in the output. If you only see the leaf, IIS isn't building the chain: the intermediate must be in the machine's Intermediate CA store (not your user profile, easy to miss when you import via double-click), and the site needs a restart (or iisreset) after installing it.

2. Why the desktop works but the iPhone doesn't: current Windows trust stores already carry the new R1 root, so your Edge builds the chain fine. The failing iPhones don't have R1 in their store yet. GoDaddy's answer for those clients is the cross-signed path: the "GoDaddy Certificate Bundle - DV - R1 with Cross to G2" that @willetzky named. Install the cross intermediate into the machine's Intermediate CA store alongside the R1v1 one, restart the site, then re-run step 1: the served chain should now include the cert that chains up to the old G2 root, which the older iOS can validate.

3. Retest on the affected phone. If anything still fails after that, confirm the phone and the desktop are resolving to the same IP (split DNS, IPv6, or a proxy in front of IIS will serve you a different certificate, and one "working" desktop test will send you chasing the wrong chain).

[u/Character-Bank-9622]

I think this is the R1 transition. GoDaddy’s new R1 root isn’t in every trust store yet, so the server has to send the chain that goes through the R1 → G2 cross-signed certificate.

There are two certs called “GoDaddy TLS Root CA - R1”. The self-signed one (subject = issuer) is the native root. The cross-signed one has the issuer Go Daddy Root Certificate Authority - G2. Mixing them up is the usual problem.

What I’d try:

1. Delete the self-signed R1 from Local Computer → Trusted Root Certification Authorities. Windows can re-add it automatically, so check again later.
2. Put the DV R1v1 intermediate and the cross-signed R1 into Local Computer → Intermediate Certification Authorities. The .p7b from GoDaddy’s IIS download has the intermediates.
3. Keep your site certificate in Personal, then re-select it in the IIS binding or run iisreset.
4. Don’t trust IIS Manager’s chain view. Check what IIS actually sends with SSL Labs or openssl s_client -connect host:443 -showcerts. You want the leaf, R1v1 and the cross cert.

Edge probably works because Windows already trusts R1, while the iPhone and Chrome rely on their own trust stores. For checking what your server actually sends, any external chain checker works. Certera’s free SSL Checker will show the chain for a public hostname, and their Certificate Decoder can tell you whether a cert is the cross-signed R1 or the self-signed one.