In my environment, for example, CA logs are forwarded to a centralized system where advanced reporting, correlation, and analytics are performed. Unfortunately, this brings limited value if the logs do not contain the key attributes that define a certificate’s actual identity. Today, the security‑relevant identity of a certificate is defined in the Subject Alternative Name (SAN), not in the display name or Subject.
Consider the following example:
Subject: host1.contoso.com
SAN: UPN=email address removed for privacy reasons
In this case, the subject suggests that the certificate represents a computer account, while the identity actually validated and trusted by applications is a highly privileged user account defined in the SAN. If CA logs only record the display name and omit the SAN, this discrepancy is completely invisible in logs and monitoring systems.
This creates a serious blind spot. A certificate that can be used for privileged authentication may appear in logs as a harmless host certificate. Such a certificate could be abused for impersonation or other attacks, while remaining difficult to detect through standard CA event analysis.