Executive summary
AWS Private CA now emits IssueCertificateDetails, described as
“a new AWS CloudTrail service event that records the complete certificate content, issuing CA
information, requester identity, and signing status for every issuance.”
Every Region where Private CA is offered, no opt-in, no cost beyond standard CloudTrail pricing.
The field list is the announcement. What makes it worth a post is the sentence describing what came
before:
“Previously, the CloudTrail management event for the
IssueCertificate API confirmed that the API call succeeded by providing a
certificate ARN but did not capture the certificate content, information about the CA
that signed it, or issuances that failed before signing.”
A private CA enforces several of its own rules by rejecting the call — #71 covered two of them three days ago, where a child CA's validity must be strictly shorter than its parent's and a path length strictly less than its issuer's. Rejections were the one outcome the trail did not record at all.
What changed
| Before | Now | |
|---|---|---|
| Event | IssueCertificate API event |
Plus IssueCertificateDetails service event |
| Certificate content | None — it “confirmed that the API call succeeded by providing a certificate ARN” | The full TBS certificate, “all X.509 fields and extensions” |
| Which CA signed it | Not captured | Issuer, among the convenience fields |
| Issuances that failed before signing | Not captured | A record “with a failure explanation” — AWS's example is name constraints violations |
| Who asked | CloudTrail's userIdentity for the call |
Plus “the account and IAM principal for direct API callers, or the service principal” for integrated services |
| Setup | — | “no configuration or opt-in required”; cross-account, it goes to the CA owner account |
The convenience fields are the ones a query will actually use: “subject, issuer, serial number, validity period, template, and signing algorithm” — so you do not have to parse a DER blob to ask the questions below.
Architecture
What a rejection looked like in a log, until today
AWS's own example of the newly-recorded case is a specific one: “Events are emitted for both successful and failed issuance, so pre-signing failures such as name constraints violations now produce a record with a failure explanation.”
Note the wording: pre-signing failures, with name constraints as the named instance. That is narrower than "failed issuances", and worth reading as written rather than as the general promise it is easy to hear.
Which raises a fair question about the two rules #71 documented, both of which are also rejections:
“Attempting to use the IssueCertificate API to issue a CA
certificate with a validity period greater than or equal to the parent's CA fails.”
“The IssueCertificate API will return an error if you attempt to
create a CA with a path length greater than or equal to the path length of its issuing CA
certificate.”
Both happen before anything is signed, so they look like the category AWS describes. I am not going to
state that as fact, because AWS names name constraints and not these — the honest position is that
this is the first release in which a rejected IssueCertificate call can appear
in a trail at all, and confirming exactly which rejections emit an event is a ten-minute experiment in
your own account rather than something to take on trust.
What is certain either way is the shape of the old gap. A module that set a subordinate's validity from the same variable as its parent's would fail every time it ran, and the trail would contain nothing. The error reached the caller and whatever captured the caller's output — a pipeline log, rather than the trail a security team queries.
Four questions the event newly answers
Which issuances failed before signing, and why. The headline change. Previously not captured; now they “produce a record with a failure explanation”.
Which certificates exceed a validity policy. The validity
period convenience field makes this a query rather than a certificate-inspection exercise. #71's
point was that validity nesting is fixed at issuance; this makes a violation of your own policy —
as opposed to AWS's rule — detectable when it happens.
Which template was used. template is a convenience field, and
Private CA's templates encode the path-length decision —
SubordinateCACertificate_PathLen0/V1 through
PathLen3/V1, plus
EndEntityCertificate/V1. A subordinate issued from a more permissive template
than intended is now visible at issuance rather than at the next audit.
Who asked, and in what capacity. The event is specific: “Each event identifies the requester: the account and IAM principal for direct API callers, or the service principal for certificates issued through AWS Private CA connectors or integrated AWS services.” That second half is the useful one — it distinguishes a certificate your pipeline asked for from one an integrated service asked for on your behalf.
Business value
The value is auditability of a resource whose decisions are close to permanent. #71's argument was that almost everything about a private CA is settled by the call that creates it or the call that issues from it, and that changing any of it means replacing the CA. An issuance log does not make those decisions reversible, but it makes them reviewable while the certificates are still short-lived enough to reissue.
The failure half has a second, more mundane value: it turns a class of deployment error into something a platform team can see without being told. A module that cannot issue a subordinate CA currently fails in somebody's pipeline output. Now it fails in the trail everybody already queries.
Security considerations
Failed issuance attempts are a signal, and this is the first time they exist. A sequence
of rejected IssueCertificate calls from an unexpected principal is exactly
the shape of somebody probing what a CA will sign. Previously unobservable; now an EventBridge pattern.
And the certificate content now lands wherever CloudTrail lands. A to-be-signed certificate contains no private key, so this is not key exposure. It does contain the subject and the subject alternative names, and in a private PKI those routinely carry internal host names, workload identifiers and SPIFFE URIs — #70 was about exactly those fields being used as authorisation inputs.
That is a consideration rather than a defect: the data is already in certificates that your workloads
hold. What changes is that a reasonably complete map of internal naming becomes queryable by anyone with
read access to the trail, which is usually a wider group than the people who can call
IssueCertificate. Worth a look at who reads the trail, on the same reasoning
that #72 applied to grant constraints appearing in
CloudTrail in plaintext.
Cost considerations
“no additional cost beyond standard AWS CloudTrail pricing”, and the relevant part of that pricing is the management-event tier: “CloudTrail logs management events across AWS services by default and is available for no charge… You can deliver one copy of your ongoing management events to your Amazon Simple Storage Service (S3) bucket for free by creating trails.” Beyond that, “$2.00 per 100,000 management events delivered (after first free copy)”.
So the only exposure is organisations running more than one trail copy, and it is worth doing the arithmetic before worrying about it. #71 established that short-lived certificate mode caps validity at seven days, so a workload on that mode reissues roughly weekly. Ten thousand such workloads is about 520,000 issuances a year, which on a second copy is about $10.
That is not a cost consideration, and saying so is more useful than implying there is one. The volume conversation only becomes real at a scale where issuance is itself a major line item.
Operational considerations
It arrives whether you want it or not. The event is “delivered automatically as a CloudTrail management event, with no configuration or opt-in required” — so existing trails, organisation trails included, start carrying it without a change on your side. Anything doing exact-match assertions on management event names will see new ones.
And in a shared-CA setup it lands somewhere you may not be looking. “In cross-account configurations, the event is delivered to the CA owner account.” So where a platform team owns the CA and application accounts request certificates from it, the issuance record — including the failure record — sits in the platform account's trail rather than the requester's. The team that caused the failure is not the team that can see it.
Two consumption paths, both named. “Because it flows through CloudTrail, you can act on it in real time with Amazon EventBridge or query it in batch with Amazon Athena for certificate auditing, inventory, tracking, and monitoring.” The failure signal belongs on the first; the conformance queries on the second.
It does not replace the audit report. #71's audit instrument was the per-CA report — “You can generate an audit report for all of the certificates issued from the CA to confirm that all of the certificates issued have expired” — which answers a retention question about a CA you are retiring. This answers a different question, per issuance, including failures, in time to act on. Keep both.
Tradeoffs
| Choice | You get | You accept |
|---|---|---|
| Do nothing | The events exist and are queryable later | No alerting; the failure signal sits unread in a trail |
| EventBridge rule on failures | The one genuinely new security signal, in real time | Tuning, because a failing deployment pipeline will generate them in bursts |
| Athena queries on validity and template | Policy conformance on a resource whose settings are otherwise fixed at issuance | Query cost, and a policy you have to write down first |
| Broad read access to the trail | Easier investigation | Subject and SAN values are a map of internal naming |
Implementation guidance
Start with the failures, because they are the part that did not exist. An EventBridge
rule on IssueCertificateDetails where the status is a failure gives you a
signal with no prior baseline to compare against, which also means no prior noise to migrate.
Then write the two queries #71 implies. Certificates whose
validity period exceeds your policy, and subordinate CAs whose
template is more permissive than
PathLen0 where you intended an issuing CA. Both are convenience fields, so
neither needs certificate parsing.
Check who reads the trail before you widen anything. The subject and SAN content is new to the trail even though it is old to your PKI.
And leave the audit report in the runbook. It answers the retirement question that this event does not.
Best practices
Treat a run of issuance failures from one principal as a probe until proven otherwise. The benign explanation — a broken module — is also worth knowing about, so the alert is useful either way.
Alert on template, not only on validity. Validity violations are a policy matter; template violations change what a certificate can go on to sign, which is the thing #71 said could not be relaxed afterwards.
Record the requester classification in whatever you build. It is what makes a shared CA auditable without inferring the caller's nature from an identity block.
Do not build a cost control for this. The arithmetic above puts it in single-digit dollars for a large fleet; the effort is better spent on the failure rule.
Who should adopt this
Anyone operating a private CA gets the events without acting, so the question is only whether to consume them. The failure rule is a small piece of work with no equivalent before today.
Anyone who has a CA shared across teams should wire up requester-identity attribution, because that is the gap the certificate ARN alone left.
Anyone whose CA hierarchy was built by a module should look for historical failures the moment there are enough events to look at — a module that has been failing one of the two issuance rules has been doing so silently.
Key takeaways
The field list is the announcement; the admission is the news. An issuance log that recorded only successes meant the two rules Private CA enforces by rejecting calls — validity nesting and path length — generated errors that reached a pipeline and nothing else.
That is the same shape as today's #74, from the other direction. There, a detection capability is quietly reduced by a configuration change nobody sees on a dashboard. Here, a detection capability quietly did not exist, and its absence was equally invisible — because an absent log entry looks exactly like an event that did not happen.
Worth doing today, for the same reason: the new signal has no history, so there is nothing to migrate and nothing to tune against. One EventBridge rule on failures, and two Athena queries on fields that are already parsed for you.
Official AWS references
- AWS Private CA now provides detailed certificate issuance logs — the event contents, what the previous event omitted, availability and cost
- AWS CloudTrail pricing — the free management-event tier and the per-100,000 rate for additional copies
- Manage the private CA lifecycle — the validity nesting rule enforced at issuance, and the per-CA audit report
- Design a CA hierarchy — the path-length rule enforced at issuance, and the certificate templates
- CreateCertificateAuthority — short-lived certificate mode and its seven-day validity cap
Comments