Issuer Diversity

This check is informational and does not affect your score (weight 0). It pulls every certificate issued for your domain in the last 12 months from public Certificate Transparency logs and counts how many distinct Certificate Authority organizations appear. Many distinct CAs usually means fragmented certificate procurement across teams or services; consolidation simplifies renewal management, lifecycle tracking, and CAA policy enforcement.

The check is intentionally not scored because context matters: a single issuer like Let's Encrypt can be operationally clean, and multiple issuers can be legitimate (Let's Encrypt for web, AWS ACM for AWS-issued, internal CA for some services). The check reports the observation without penalizing you.

How the check works

Per scan, RedScore queries Certificate Transparency log aggregators (crt.sh and equivalents) for every cert issued for the domain in the last 12 months, then groups by issuer organization name. The result tier maps to bands (informational, not scored):

• 0 entries: nothing logged in the window. Tier shown as healthy/no-data.
• 1-2 distinct CAs: consolidated. Reported as observed pass.
• 3 distinct CAs: moderate fragmentation. Reason: moderate_issuer_diversity.
• 4-5 distinct CAs: high fragmentation. Reason: high_issuer_diversity.
• 6+ distinct CAs: excessive fragmentation. Reason: excessive_issuer_diversity.

Verdict on the row is always unknown / severity info. The evidence includes an observed_verdict field that shows what the verdict WOULD have been if scored, plus the issuer breakdown (CA name, count, percentage).

How the verdict maps to evidence

• Always unknown / info. The score field is calculated but not applied. Score does not move based on this check.

Evidence shows certificates_in_window (total certs over 12 months), distinct_issuer_organizations (the number of distinct CAs), issuer_breakdown (per-CA count and percentage), and a sample of CT entries with the cert details.

How to interpret each tier

1-2 distinct CAs (consolidated)

Common patterns: Let's Encrypt only (typical for self-managed sites and small SaaS); Let's Encrypt + AWS ACM (web on a self-managed proxy, ACM for AWS-issued certs on CloudFront/ALB); Cloudflare + AWS ACM (Cloudflare for proxied hosts, ACM for direct-to-AWS hosts). Healthy and easy to manage.

3 distinct CAs (moderate)

Often the result of inheriting a setup that included a commercial CA from before the team standardized on automated issuance. Audit the issuer_breakdown: if one CA accounts for the bulk and the others are vestigial, retire the vestigial ones during their next renewal window. If three distinct CAs are each handling specific use cases (web, internal, EV), that may be intentional; document the policy.

4-5 distinct CAs (high)

Strong signal of fragmented procurement. Different teams, regions, or product lines each pick their own CA, leading to inconsistent renewal cycles, duplicated negotiation overhead, and uneven security posture. The fix is policy and tooling: pick 1-2 CAs as the org standard and migrate everyone over.

6+ distinct CAs (excessive)

Almost always means there is no central certificate policy. Beyond the operational pain, this complicates incident response (one CA gets deprecated by browsers, you need to find every cert from that CA across your org). Establish a centralized cert policy and migrate.

Consolidation paths

• Pick 1-2 preferred CAs based on use case. Most orgs land on Let's Encrypt (free, ACME automation everywhere) plus one platform-specific CA (AWS ACM for AWS-issued certs, Google Trust Services for GCP, Microsoft for Azure-managed).
• Document the policy. Internal cert policy doc that says: "all public-facing certs come from CA X; AWS-internal certs from ACM; no other CAs without security team approval."
• Pair with CAA records. Publish CAA records (see CAA Record Presence) listing only your approved CAs. Any CA outside that list will refuse to issue.
• Migrate during renewal windows, not by force. Wait for each existing cert to approach expiry; reissue from the approved CA at that point. Avoids forced rollovers.
• Track via CT log monitoring. Tools like crt.sh, Cert Spotter, and Hardenize watch CT logs for new certs on your domain. Alerts on certs from non-approved CAs catch policy drift in real-time.

Verify

• Search crt.sh manually: https://crt.sh/?q=yourdomain.tld. Sort by issuer to see your spread.
• Compare against your published CAA records (dig CAA yourdomain). Every CA in CT history should also be in CAA, or be retired.
• Re-run the RedScore lookup. The DNS row reflects the latest CT data; remember it does not affect score either way.

Common pitfalls

• Counting subdomain-specific CAs as fragmentation. CDN providers (Cloudflare, Fastly) issue certs for proxied hostnames under their own organization name, even when the domain is yours. Those count as one CA each. Decide whether the CDN is part of your standard set.
• Treating informational as no-action-needed. Excessive fragmentation does not affect this check's score, but it does affect the CAA vs CT Issuance check (where unauthorized CAs in CT history can lower the score). Consolidating helps both.
• Removing a CA without auditing what it issues. Some CAs issue both your web cert and internal certs that are not visible to the CT-based check. Audit all certs from a CA before retiring it.
• Confusing distinct CAs with distinct certs. The check counts distinct issuer organizations, not certs. Five Let's Encrypt certs on five different subdomains count as 1 distinct CA, not 5.
• Multi-region replicas of the same CA. AWS ACM in us-east-1 and AWS ACM in eu-west-1 are the same CA organization. The check counts them as one.
• Old wildcard cert from a former vendor still in CT. CT logs are append-only; old certs persist for the validity period. The check rolls them off after 12 months from issuance, but recently-expired certs from a former vendor still show up.