Go 1.25.5 repairs wildcard exclusions and hostname diagnostics
December's certificate fixes address two different consequences of names supplied by a peer. Wildcards must respect excluded subdomains, and failed verification must produce a bounded diagnostic.
A wildcard certificate name describes more than the literal characters stored in its subject alternative name. An exclusion for test.example.com must account for a leaf claiming *.example.com, because that wildcard can authorize the excluded host. Go's December security release repairs the relationship between those two interpretations.
Go 1.25.5, released on December 2, includes two crypto/x509 security fixes alongside maintenance changes in mime and os. Go 1.24.11 carries corresponding security patches. The announcement also describes excessive resource consumption while formatting hostname verification errors, so both accepted and rejected certificate names require attention.
I value having certificate policy in a standard implementation because its rules compose in ways that ordinary callers should not have to reproduce. A correct hostname comparison is only one part of that policy. The constraints imposed by the chain must also limit what the leaf can claim, including through patterns.
A wildcard can include an excluded name
CVE-2025-61727 concerns excluded subdomain constraints and wildcard SANs. The announcement's example is an exclusion for test.example.com with a leaf SAN of *.example.com. Before the fix, the exclusion did not restrict that wildcard claim. Comparing the literal SAN against the constraint failed to capture the overlap in names the wildcard represented.
The tagged verifier passes an explicit excluded argument into domain-constraint matching. That allows the matcher to distinguish the interpretation needed for an exclusion from the ordinary permitted-domain case. A negative constraint must detect prohibited coverage even when the presented name is a pattern.
The implementation splits domains into reversed labels and recognizes a leading wildcard. For the relevant excluded wildcard comparison, it adjusts the label sequences before comparing them. The example consequently compares the shared domain portion instead of requiring the wildcard's literal asterisk to equal the excluded host's concrete label.
This is a specific correction to name-constraint processing. It does not make every wildcard valid or add a general-purpose wildcard language to certificates. The verifier's hostname rules still restrict wildcard matching to the complete leftmost label of an otherwise valid pattern. An exclusion has to work with that existing meaning.
The same verifier documents that hostname verification ignores the legacy Common Name field. DNS names and IP addresses use their respective SAN collections, which preserves the distinction between the identities carried by the certificate. The order of these operations matters. A leaf can match the requested hostname while its chain remains unacceptable under an issuer's constraint. Treating the successful hostname match as the whole authentication decision would omit the issuer's limitation on delegated naming authority.
Failure formatting can consume resources
CVE-2025-61729 affects HostnameError.Error. A peer certificate can contain many names that do not match the requested host. The previous diagnostic attempted to list them without a count limit and built the output through repeated string concatenation. Constructing the message could therefore require quadratic work.
The verification decision had already failed in that path. The additional cost arose when a caller asked for the explanation, which makes it easy to overlook in a review focused only on successful validation. Logging or returning a descriptive error can still process attacker-supplied data.
The patched implementation uses a threshold of 100 names. At or above that threshold, it returns a summary with the count instead of enumerating the alternatives. Smaller DNS-name lists use a join operation, while IP name formatting uses a builder. The changes address both how much detail the diagnostic includes and how it constructs that detail.
That threshold does not impose a new maximum of 99 names on every certificate. It limits this error message's enumeration. A large certificate can still reach whatever parsing and validation paths apply to it. Conflating a diagnostic limit with a certificate acceptance rule would misdescribe the fix.
Error values retain structured information
HostnameError contains a certificate pointer and the requested host. Its string form is a diagnostic representation of those values. Applications that need structured reasoning about an error should not treat a particular English sentence as a stable protocol carrying all certificate data.
The Go 1.13 error guidance explains how errors.As can inspect an error type through wrapping. That is a more direct way to determine whether a failure is a hostname mismatch than searching a formatted message for a phrase. The December formatting change makes the distinction between structured error and presentation especially concrete.
The same principle applies to diagnostic storage. An error string need not reproduce every peer-supplied alternative name to explain that none matched. A count can communicate the relevant fact while avoiding a potentially enormous enumeration. Detailed certificate inspection can remain a separate operation with its own handling of size and provenance.
I prefer that separation because the ordinary failure path should remain usable under hostile input. A rejected certificate should not force the service to spend disproportionate resources explaining its rejection. The patch retains useful context for small cases and supplies a bounded form for large collections.
Constraints and diagnostics protect different decisions
The wildcard correction changes whether a constrained chain can authorize a name. The diagnostic correction changes the work performed after a mismatch. Their shared input is certificate naming data, but they act at different points and require different evidence of correctness.
For wildcard exclusions, the meaningful question is whether the leaf's pattern covers a name the issuer excluded. Comparing only textual labels can miss that relationship. For diagnostic construction, the meaningful question is how output size and copying work grow with the number of names. A cryptographically invalid or unauthorized peer can still reach that code.
December's release places both checks inside the standard verifier. Excluded domains constrain wildcard coverage, while mismatch messages stop enumerating at a defined count. Applications retain the usual certificate APIs and error types, with corrected handling of the name relationships and resource costs those APIs already expose.