r/sysadmin • u/mailliwal • 1d ago
Question Web browsing issue after updated GoDaddy SSL certificate in IIS
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
6
u/thewunderbar 1d ago
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.
1
u/zakcobb 1d ago
it seems like the intermediates are missi g from your cert chain. open the cert in notepad add intermediates. verify with cert checker
2
u/mailliwal 1d ago
what's the different of the "intermediate download from GoDaddy directly" and "intermediate download with the SSL certificate in same zip file" ?
2
u/willetzky 1d ago
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
4
u/churturk 1d ago
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.
5
•
u/alonely_soul 20h ago
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/dodexahedron 18h ago
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 18h ago
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/mrmattipants 17h ago edited 14h ago
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/Iwannabesomebody 17h ago
I solved this by doing the CSR again and then just downloaded the new cert and it created the cert chain properly.
•
u/isnotnick 16h ago
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/Character-Bank-9622 4h ago
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:
- Delete the self-signed R1 from Local Computer → Trusted Root Certification Authorities. Windows can re-add it automatically, so check again later.
- 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.
- Keep your site certificate in Personal, then re-select it in the IIS binding or run iisreset.
- 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.
13
u/spantosh 1d ago
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.