Background:
As part of GoDaddy’s recent change, effective June 15, 2026, newly issued DV TLS certificates intended for server use are now signed using a new certificate chain.
This change is due to a Chrome Root Program policy update, which requires newly issued publicly trusted server certificates to include only the Server Authentication extended key usage (EKU: serverAuth) and no additional EKUs, such as the previously included Client Authentication (EKU: clientAuth).
GoDaddy's existing G2 signing/issuing intermediate CAs do not specify any EKU at all, meaning a new Intermediate CA was required to meet the new requirement. GoDaddy is moving Domain Validated (DV) issuance to its new R1 hierarchy to meet the Chrome Root Program policy constraints going forward.
Affected certificate chains:
<Server certificate>
--GoDaddy TLS Intermediate CA DV - R1v1
----GoDaddy TLS Root CA - R1
<Server Certificate>
--Starfield TLS Intermediate CA DV - R1v1
----Starfield TLS Root CA - R1
Certificate trust issue:
After a GoDaddy or Starfield server certificate update, users may see a certificate warning in the browser, or FortiClient/SSL VPN reports that the server certificate cannot be verified:
Original Chain Observed in Browser:
After the fix, the following chain can be seen in the browser:
Root cause:
On affected deployments, the client (browser/FortiClient) will fetch the original DV - R1v1 Chain from AIA/OSCP repositories as follows:
GoDaddy TLS Root CA - R1 is not yet trusted globally across browsers and OS trust stores. It can take a year or more for new root CA certificates to be widely trusted.
Resolution:
Import the following alternate chains either on all clients or on the server side (recommended). If the certificate is a FortiGate local certificate, FortiGate is the server.
The certificate files are publicly available from the GoDaddy or Starfield repository.
Chain 1: Starfield.
Certificate | Serial Number | sha256 Thumbprint | Starfield TLS Intermediate CA DV - R1v1 | 00:C5:E2:25:A1:0D:F6:78:04:EC:53:05:DC:F3:8E:52:34 | 06 89 1C 34 A2 E4 68 7C 63 0B 29 85 0C C9 F6 D4 5D ED 39 49 1C F8 77 C7 24 6B 6E C6 33 58 7A 2C | Starfield TLS Root CA - R1 to G2 Cross Certificate | 46:67:02:AA:31:94:1F:A2:C1:96:EF:E6:D0:9B:AF:6C | 26 A9 3D 60 03 90 77 65 4C 0D DA 1F B6 34 AF 5F F5 C1 14 C7 AC 1F D0 44 9B 1C 9D 21 78 B0 28 FF |
Chain 2: GoDaddy.
Certificate | Serial Number | sha256 Thumbprint | GoDaddy TLS Intermediate CA DV - R1v1 | 00:8A:AA:80:51:5C:0B:C6:88:C7:95:5D:70:F2:77:58:AC | 7A 43 BC 77 47 D0 63 3F BD 90 FF 90 0C 92 42 41 7C 02 7D BD CA 05 AF 72 DA 9A 70 E3 51 8D BE 2E | GoDaddy TLS Root CA - R1 to G2 Cross Certificate | 00:90:DE:6C:7F:B3:B5:0B:3C:06:17:72:4F:C1:34:02:AD | 7B CB 0F 2F 2D 10 31 A6 AF 8D 61 BA A8 35 D2 83 5A 3B 8B CC 26 D9 4A 3B 04 8B 16 55 FB 81 29 8C |
Note: Certificate serial numbers and thumbprints are published by GoDaddy and are subject to change or rotation. Confirm the current values against the GoDaddy repository before deploying in production.
Option 1. Import for all clients.
On Windows, for example: Download the certificates above from the GoDaddy/Starfield repository links. Import both certificates into the Intermediate Certification Authorities store for both the Local Machine and Current User locations. Confirm the certificates appear under both certmgr.msc ('Manage user certificates') and the local machine snap-in ('Manage computer certificates'), under Intermediate Certification Authorities.
Option 2. Importing on FortiGate (recommended).
Import each CA certificate in Chain 1 or each CA certificate in Chain 2, as appropriate, as a CA Certificate on the FortiGate. See the following documents:
Technical Tip: How to import public CA certificate bundle in FortiGate Import a certificate Note: Do not import the 'Starfield TLS Root CA - R1' certificate (serial FCE28F249CBB8089B5B384EC8FC33A1E) or the 'GoDaddy TLS Root CA - R1' certificate (serial DA62FF9E2619B1257A4809368EE8E3F7) to the FortiGate as a remote certificate. Uploading Root CA - R1 may cause the FortiGate to serve the non-working certificate chain, leading to a certificate warning on client devices.
FortiGate services that consume the certificate store cache CA information may not automatically reload the updated CA certificates after import.
Therefore, after importing the certificates mentioned above, restart affected services to force them to reload the CA store. Note that restarting some of these services may cause temporary service disruption or, in the case of GUI/SSL VPN, disconnect existing GUI/SSL VPN users.
fnsysctl killall fnbamd
fnsysctl killall sslvpnd
diagnose test application ipsmonitor 99
diagnose test application wad 99
If the certificate is in use by HTTPS for GUI access:
diagnose nodejs process restart
fnsysctl killall http_authd
fnsysctl killall authd
See Troubleshooting Tip: Restarting sslvpnd process after installing root CA certificate and/or intermediate CA certificate.
Why the resolution works:
When the full chain is present on the server side, the server presents that full chain in the TLS Server Hello. If an intermediate certificate in the trust chain is missing on the server side, the server only presents its leaf certificate, and it becomes the client's responsibility to fetch the missing intermediate(s) from the CA's repository via the AIA/OCSP links in the certificate.
If the cross-signed path is not available to the validating device, which is the normal state for any client until the alternate chain is imported on the server or client side, then the certificate is validated against the original chain via Root CA - GoDaddy TLS Root CA - R1, which the browser/device does not yet trust, and the connection is flagged as untrusted.
GoDaddy TLS Root CA - R1 to G2 Cross Certificate is an Intermediate CA certificate with the same common name as GoDaddy TLS Root CA – R1.
R1 to G2 Cross Certificate is not a Root Certificate anymore (i.e. not self-signed with CA:True). Instead, the Cross Certificate is issued by GoDaddy's already widely trusted Root CA, GoDaddy Class 2 Certification Authority Root Certificate - G2.
After the complete cross-signed certificate chain is available to the client (because the client has the certificates in its existing trust store or the server presented the intended chain to the client), and the chain terminates in a Root CA trusted by the client, the server certificate is now trusted.
Additional steps after importing required certificates:
On FortiClient: Clear the cache and cookies on FortiClient. Fully close FortiClient, then restart the FortiClient service from services.msc (rather than just reopening the UI). If the warning is still cached, restart the endpoint.
On browsers:
Close all active tabs, then clear the browser's cache, history, and cookies. Close and reopen the browser, then reload the site.
Verification:
Validating that FortiGate is sending the full chain using Wireshark packet capture on the endpoint:
If TLS v1.3 is in use, the certificate chain cannot be viewed from packet capture, as the TLS Server Hello is encrypted. If using SSL VPN, temporarily set the maximum TLS version to 1.2 so the certificate chain is visible in the handshake (TLS 1.3 encrypts the certificate message, which hides the chain from a passive capture):
config vpn ssl settings
set ssl-max-proto-ver tls1-2
end
Revert this setting once validation is complete - do not leave SSL VPN pinned to TLS 1.2 long-term.
Take a packet capture on the client PC while connecting, then inspect the ServerHello/Certificate message:
Non-working: Only the leaf/server certificate is sent.
Working: The full chain is sent, including the R1 to G2 cross-certificate.
Related documents:
| 
