Public Sector TLS Trends, Addendum to Issue 0: Apex vs www, Two Cert Programs on One Domain

Published as an addendum to Public Sector TLS Trends, Issue 0. The inaugural snapshot surfaced one civilian agency serving an expired TLS certificate at its bare-domain apex while the www subdomain on the same agency was healthy. That finding led to a methodology question: how common is it for an agency to run two cert programs on a single domain? Common enough that it deserves its own measurement.

This addendum reports on a full sweep of the inventory (109 hosts) on 2026-05-11, probing both the apex (host) and the www subdomain (www.host) of every entity and classifying the relationship between the two certs presented.

The classification

For every domain in the dataset, we asked six questions:

1. Does the apex resolve and serve HTTPS?
2. Does the www subdomain resolve and serve HTTPS?
3. Are both certs from the same CA?
4. Do both certs have approximately the same expiry?
5. Is either certificate expired?
6. Where does the apex's HTTP redirect point?

The answers fall into six buckets:

Headline result

Twenty-eight of 109 entities (26 percent) have a meaningful split between apex and www, defined as either a cross-CA difference, a within-CA renewal gap of more than two weeks, or an expired-on-one-side asymmetry.

Where the split lives

The split pattern is concentrated in the civilian sector and is essentially absent from the defense industrial base and commercial vendor cohorts.

The civilian breakdown is striking. Half of civilian agencies in the dataset run a coherent single-cert posture across apex and www. The other half have two cert programs. Of those, thirteen civilian agencies run different CAs entirely on apex versus www.

The defense industrial base is the cleanest of the sectors: 16 of 18 DIB primes (89 percent) serve identical or near-identical certs across apex and www. The DIB practice and the civilian-agency practice diverge here, and the divergence is the kind that suggests single-owner web programs in private industry versus distributed ownership in federal agencies.

What "cross-CA" looks like in practice

The thirteen civilian cross-CA cases (plus one GSE) show four recurring shapes:

• Agency-managed apex on a long-validity OV cert; CDN-managed www on a short-validity DV cert. The apex identifies the organization in the certificate subject (Department of X). The www endpoint is a short-cycle automated cert with no organizational identity. The two certs are renewed by different teams on different cadences.
• Legacy apex on a CA that is being phased out of major root programs; CDN-managed www on a modern CA. Several agencies still serve their apex from a CA whose roots are scheduled for distrust in Mozilla and Chrome. The www endpoint, served behind a major CDN, rotated to a modern CA on the CDN's standard cadence years ago. The apex stayed where it was.
• Both endpoints on short-validity CAs but different ones. Several agencies have apex on Let's Encrypt and www on Amazon, or apex on Google Trust Services and www on Amazon. These look like two automated cert programs run by two different vendors against the same domain.
• Sectigo DV on the apex; DigiCert on www. Several agencies inherit a Sectigo DV profile (no CRL distribution point in the leaf, the same finding the OCSP deep-dive flagged) on their apex while www sits on a longer-validity DigiCert OV behind a CDN.

Tailwind Assessment: A federal agency that runs two cert programs on its public web property has accumulated two separate operational liabilities. Each one needs its own renewal alerting, its own CA monitoring, and its own response to CA-level industry events (root distrust, OCSP shutdown, validity changes). If one liability is unwatched, the apex-vs-www case in the inaugural capture is the failure mode. The most common path to coherence is not adding more monitoring to both programs; it is collapsing to one program and pointing the bare-domain HTTP redirect at the www endpoint so the apex never has to serve TLS at all.

The www-only convention in .mil

Twenty-one of 29 reachable .mil sites have no DNS A record at the apex. The www subdomain is the only addressable HTTPS endpoint. Six additional .mil sites refuse connections at the apex and at www. Only six .mil sites in the dataset present a working HTTPS apex, and of those, two are cross-CA splits.

This is a posture choice worth highlighting. The .mil convention removes the apex/www split problem by removing the apex from the public DNS surface entirely. A user typing the bare domain into a browser gets a DNS error rather than an expired cert; the agency operates a single HTTPS endpoint and a single cert program. Whether or not this is the right posture for civilian agencies is a separate question, but it eliminates the failure mode this addendum was written to describe.

The asymmetric case

One entity in the dataset matches the failure mode that motivated this addendum: apex cert expired several days before the capture, www cert healthy, and the apex's HTTP layer redirecting users into the expired TLS surface rather than to the healthy www endpoint. This is what breaks things in practice.

A user typing the bare domain in a browser:

1. The browser sends an HTTPS request to the apex (modern defaults).
2. The TLS handshake completes with an expired certificate; the browser rejects the connection.
3. The HTTP-on-apex redirect is never visited because the user never got that far.

If the same agency's apex HTTP redirect pointed at the www endpoint instead of at its own HTTPS surface, the failure mode would not exist. The HTTPS apex could remain in any state, including not listening at all, and users would still reach the working www service.

Following our research, the affected agency was notified of the expired apex certificate and the apex-redirect-to-self failure mode, and was able to resolve the issue prior to this addendum's publication. A re-probe on 2026-05-13 returned a new leaf from the same CA, with a ~180-day validity that fits within the SC-081v3 200-day cap that took effect on 2026-03-15. Organizational identity is preserved in the certificate subject; OCSP and CRL endpoints are both present in the leaf.

The user-facing failure mode described above is no longer reachable as of this writing. The apex's HTTP redirect still points at the apex's own HTTPS surface rather than at the www endpoint, so the architectural recommendation in this addendum remains live for any future apex-cert lapse.

Recommendations

Three operational recommendations, ranked by leverage.

1. For an agency running two cert programs on one domain: consolidate to one. The agency-managed apex tier and the CDN-managed www tier accumulate divergent operational liabilities over time. Choose the tier you trust, point the other one at it, stop running two cert programs.
2. For any agency that cannot consolidate: at minimum, point the apex HTTP redirect at the www endpoint, not at the apex's own HTTPS surface. This is a single line of configuration and it removes the user-facing failure mode entirely, even if the apex cert expires.
3. For agencies aligned with the .mil convention: consider removing the apex from DNS entirely. The bare-domain endpoint becomes unreachable, the renewal program drops to one cert, and the surface for the unwatched-apex failure goes to zero. This is the most aggressive option and not always appropriate for citizen-facing services, especially that domain was previously used for marketing or official government documents.

What changes in the methodology

Apex-vs-www classification is now a first-class column in the enriched and published datasets, captured on every weekly refresh alongside the cert inventory. Subsequent weekly trackers will report changes in the classification (an agency moving from split to aligned, or vice versa) the same way they report cert rotations today. A monthly deep-dive on the cross-CA split pattern is planned once a second capture confirms which of the splits are stable versus in-flight.