certs: give the benchmark certificate a subjectAltName - #1274
Open
MDA2AV wants to merge 1 commit into
Open
Conversation
The committed certificate carried CN=localhost and no subjectAltName. RFC
9525 removed CN fallback entirely, so it is not a valid server certificate
to anything current -- and some server libraries parse the extension while
loading the pair and fail outright rather than at verification time.
sanic is one: handing it the cert/key pair raises
for t, name in cert["subjectAltName"]
KeyError: 'subjectAltName'
and the process dies before it serves anything. Every entry that loads the
pair without inspecting it was unaffected, so the gap stayed invisible.
Regenerated over the existing private key, so only the certificate changes:
SANs for localhost, *.localhost and the loopback addresses (the harness
connects to localhost on every TLS profile), plus the keyUsage and
extendedKeyUsage a server certificate should carry. Added generate.sh, since
there was no record of how the pair had been produced.
No regression: actix 71/0 and aspnet-minimal 84/0, which between them cover
json-tls, static-tls, baseline-h2, static-h2 and the h3 profiles.
This does not by itself unblock sanic -- see the note in that entry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
certs/server.crtcarriedCN=localhostand nosubjectAltName.RFC 9525 removed CN fallback entirely, so it is not a valid server certificate to anything current. More practically: some server libraries parse the extension while loading the pair and fail outright rather than at verification time.
sanicis one of those. Handing it the cert/key pair gives:and the process dies before serving anything. Every entry that loads the pair without inspecting it was unaffected, which is why the gap stayed invisible.
What changed
Regenerated over the existing private key, so only the certificate changes:
localhost,*.localhost,127.0.0.1,0.0.0.0,::1— the harness connects tolocalhoston every TLS profilekeyUsage/extendedKeyUsage=serverAuthcerts/generate.sh, since there was no record of how the pair had been producedNo regression
Between them those cover json-tls, static-tls, baseline-h2, static-h2 and the h3 profiles.
Note
This does not by itself unblock
sanic. With the SAN in place sanic gets past the crash, but its TLS listener still never completes a handshake under its worker manager — at any worker count. It works only withsingle_process=True, which would pin the entry to one core. That looks like an upstream bug in sanic 25.3.0, so sanic stays unsubscribed from json-tls.🤖 Generated with Claude Code