IBM i GoDaddy certificate not trusted in Chrome: the DCM fix

If you renewed a GoDaddy certificate on IBM i since June and Chrome now calls the site untrusted, the certificate is probably fine. The chain your server sends is not. An IBM i GoDaddy certificate not trusted in Chrome is a known problem with a published fix, IBM support document 7290213, but that document tells you what to click without telling you how to find out you’re affected, which applications you’re about to break while you fix it, or why it can happen again at your next renewal. This covers all three.

What breaks, and who sees it

The symptom from IBM’s document: after implementing a new GoDaddy certificate, Chrome reports the website as untrusted. The certificate is issued by GoDaddy TLS Intermediate CA DV - R1v1 and assigned to the IBM HTTP Server application definition. Run OpenSSL against the server and you get “self-signed certificate in certificate chain” with verify return code 19.

The part that makes this a long morning: the *SYSTEM store already holds everything it needs. IBM lists the enabled G2 root, the R1v1 intermediate, the self-signed R1 root, and the enabled R1-to-G2 cross certificate. The server still presents a chain that ends at the self-signed R1 root.

Who hits it depends on the client. Reports from Windows and FortiGate admins describe the same pattern: one browser works, another fails, and users on older or locked-down machines fail first. That inconsistency sends people chasing the browser or the network when the server is the problem.

IBM’s document lists IBM i 7.3, 7.4, 7.5 and 7.6. IBM’s fix involves no PTF. It is store configuration.

Why IBM i serves the wrong chain

GoDaddy changed issuing roots this year. From June 15, 2026, publicly trusted server certificates can no longer carry the Client Authentication EKU under a Chrome Root Program policy. GoDaddy’s G2 issuing intermediates list no EKU at all, so GoDaddy stopped issuing from them and moved DV certificates to a new hierarchy: GoDaddy TLS Root CA - R1, with GoDaddy TLS Intermediate CA DV - R1v1 doing the issuing.

R1 is new. GoDaddy’s own help page says it “is still in the process of being broadly trusted/distributed in browser and OS trust stores,” and Fortinet’s write-up notes that new roots can take a year or more to be widely trusted. To cover the gap, GoDaddy publishes a cross certificate. It carries the same subject name as the R1 root but is signed by the old Go Daddy Root Certificate Authority - G2, which clients have trusted for years. Send the cross certificate and clients build a path to G2. Send the self-signed R1 root and clients without R1 have nothing to anchor to.

So there are two certificates named “GoDaddy TLS Root CA - R1” in your store, one self-signed and one cross-signed. IBM’s explanation is short: the system serves the self-signed one. Fortinet warns its customers about the same mechanism and tells them not to import the R1 root onto the FortiGate, because it can make the device serve the non-working chain. On Windows, Schannel picks the shortest chain it can build, and a locally trusted R1 root is one hop. Different products, same trap.

Check your IBM i GoDaddy certificate chain in 60 seconds

Don’t wait for a help desk ticket. From any machine with OpenSSL, including PASE on the IBM i itself:

openssl s_client -connect www.example.com:443 \
  -servername www.example.com -showcerts </dev/null

Read the certificate list from the top. A broken chain ends with an entry whose subject and issuer are both GoDaddy TLS Root CA - R1, and the output reports Verify return code: 19 (self-signed certificate in certificate chain). A good chain shows GoDaddy TLS Root CA - R1 issued by Go Daddy Root Certificate Authority - G2.

Run it against every TLS port that uses a GoDaddy certificate, not just 443. Telnet on 992 and the host servers that ACS talks to are the usual candidates. Don’t use a packet capture for this: Fortinet points out that TLS 1.3 encrypts the certificate message, so the chain isn’t visible on the wire.

If your certificate came from Starfield, GoDaddy’s other brand, the names change to Starfield TLS Intermediate CA DV - R1v1 and Starfield TLS Root CA - R1, and everything else here still applies.

Find every application that uses the certificate first

IBM’s fix has you un-assign the certificate from your applications, change the store, then reassign it to “the same application definitions as before.” That instruction is the riskiest line in the document. In many shops the GoDaddy certificate isn’t only on the HTTP Server. It’s on Telnet, the host servers, FTP, sometimes SMTP. Miss one when you reassign and that service comes back with no certificate.

Get the list before you touch DCM. On releases that have it, the QSYS2.CERTIFICATE_USAGE_INFO view returns every registered application and the certificate labels assigned to it. It needs Option 34 and a profile with *ALLOBJ and *SECADM:

SELECT APPLICATION_ID,
       APPLICATION_TYPE,
       CERTIFICATE_STORE,
       CERTIFICATE_LABELS
  FROM QSYS2.CERTIFICATE_USAGE_INFO
 WHERE CERTIFICATE_LABEL_COUNT > 0
 ORDER BY APPLICATION_ID;

CERTIFICATE_LABELS comes back as a JSON array. Filter on your GoDaddy label, save the result, and treat it as your reassignment checklist. If the view isn’t on your system, DCM’s Manage applications page shows the same assignments one application at a time. Screenshot it. Either way, write the list down before step 3.

IBM’s fix, with the order that matters

These are IBM’s eight steps from document 7290213, with notes on where shops trip.

1. Download two files from the GoDaddy repository (certs.godaddy.com/repository): the R1 to G2 cross certificate (gd_tls_root-r1-cross-g2.crt) and the R1v1 intermediate (gd_tls_issuing_dv-r1v1.crt). Starfield users take the Starfield equivalents.
2. Export your GoDaddy server certificate to a .pfx file. This is your rollback. Store it somewhere other than the IFS directory you’re working in.
3. Record and un-assign the certificate from every application. In DCM: Manage certificates, expand your certificate, Assign, check the application definitions, Remove. Your list from the previous section is the record.
4. Delete the self-signed R1 root from the *SYSTEM store. Make sure you delete the self-signed one, not the cross certificate. They share a name. Check the issuer before you click.
5. Import the CA certificates in this order: G2 Root CA, then R1 to G2 Cross, then R1 DV intermediate. IBM specifies the order. Follow it.
6. Check the hierarchy (View, Certificate Hierarchy). It should read Personal Cert, then R1 DV Int, then R1 to G2 Cross, then G2 Root. If R1 appears as a root, stop and go back to step 4.
7. Reassign the certificate to the same application definitions. This time choose Replace, not Remove.
8. Restart the HTTP Server instance so it picks up the new chain: ENDTCPSVR SERVER(*HTTP) HTTPSVR(name) then STRTCPSVR SERVER(*HTTP) HTTPSVR(name).

IBM’s document only mentions restarting the HTTP Server. If you reassigned the certificate to Telnet or the host servers in step 7, restart those too, or they keep serving whatever they loaded at startup. That’s our advice, not IBM’s text, but a server that reads its certificate at start won’t notice a store change until it restarts.

Steps 3 through 8 leave production services without a certificate for as long as they take. On a well-rehearsed system that’s minutes. Don’t do it at 10 a.m. on a Monday. Book a short window, the same way you would for the August security PTFs that broke things.

Verify it, then put it in the renewal runbook

Run the OpenSSL check again on every port from your list. You want the cross certificate in the chain and a verify return code of 0. Then open the site in Chrome from a machine that has never visited it, because some clients cache intermediate certificates, and a machine that has seen the good chain once can hide a bad one.

Then write it down, because this may not be a one-time fix. GoDaddy’s repository publishes the self-signed R1 root right next to the cross certificate, and its download bundles carry root certificates as well as intermediates. One Windows admin’s write-up reports that the self-signed root lands back in the trusted store on the next renewal and breaks the chain again, even with the cross certificate present. IBM has not documented that for DCM, but the mechanism IBM describes is the same one. Add two lines to the certificate renewal runbook: run the OpenSSL check after every renewal, and check the *SYSTEM store for a self-signed R1 root before you reassign.

While you’re in there, the ACS security update coverage is a reminder that the PCs connecting to IBM i carry their own truststores, and those can be stale too.

Two problems this fix does not solve

Mutual TLS from IBM i. R1-issued certificates no longer carry the Client Authentication EKU. If any IBM i job uses the same GoDaddy certificate to authenticate itself to a partner, through a DCM client application definition, a bank file transfer, or an HTTPS API that wants a client certificate, that connection breaks for a different reason after renewal, and the cross certificate won’t help. GoDaddy’s guidance is to move client authentication to a private CA or a certificate issued for client use. The APPLICATION_TYPE = 'CLIENT' rows from the query above are where to look.

The bridge has an end date. GoDaddy says its G2 chain “is planned to be expired/ended with Google in April 2027.” The cross certificate is the bridge while R1 trust spreads, and GoDaddy’s plan depends on that finishing first. If it hasn’t reached the clients your users run, the chain you serve may need to change again. Put a reminder on the calendar for the first quarter of 2027 to re-run the check, and read GoDaddy’s repository notes before your next renewal after that.

If your shop tracks this kind of recurring operational chore across releases and staff changes, the IBM i AI Field Guide has prompts for turning a one-off fix like this into a runbook entry someone else can follow.

Bottom line

If you put a GoDaddy or Starfield DV certificate on IBM i after June 15, 2026, run the OpenSSL check today. It takes a minute and tells you whether Chrome users are seeing a warning you haven’t heard about yet. If the chain ends at a self-signed R1 root, pull the application list with CERTIFICATE_USAGE_INFO first, then follow IBM’s eight steps in a short maintenance window, restarting every server you reassign, not just HTTP.

Don’t push the R1 root out to client PCs as a workaround. It fixes the machines you manage and none of the ones you don’t, like customer browsers and phones. Fix the chain on the server once, then make the check part of every renewal until R1 is trusted everywhere.

Frequently Asked Questions

Why does my GoDaddy certificate work in Edge but not Chrome on IBM i?

Since June 15, 2026, GoDaddy issues DV certificates under its new TLS Root CA - R1, which is not yet in every browser’s trust store. Chrome builds its own trust decision and does not trust R1 yet, so if IBM i sends a chain ending in the self-signed R1 root, Chrome rejects it. Browsers or clients that already trust R1 accept the same chain, which is why the failure looks random.

Do I need a PTF to fix the GoDaddy R1 chain problem on IBM i?

No. IBM’s support document 7290213 treats it as a certificate store configuration problem on 7.3 through 7.6. The fix is to remove the self-signed R1 root from the *SYSTEM store, import the G2 root, the R1-to-G2 cross certificate and the R1v1 intermediate in that order, reassign the certificate and restart the server.

Are Starfield certificates affected too?

Yes. Starfield is GoDaddy’s other certificate brand and moved to the same R1 hierarchy, with a Starfield TLS Root CA - R1 and its own R1-to-G2 cross certificate. The same check and the same fix apply, using the Starfield files from the repository.

Is the R1-to-G2 cross certificate a permanent fix?

No, it is a bridge. GoDaddy says the cross-sign keeps R1 certificates working in browsers while R1 trust spreads, and that its G2 chain is planned to end with Google in April 2027. Check your chain again at every renewal and before that date.