Skip to content

Release 1.4.1: stop forcing TLS 1.0 when connecting with a client certificate - #54

Merged
ademar merged 1 commit into
masterfrom
fix/tls-default
Sep 24, 2026
Merged

ademar merged 1 commit into
masterfrom
fix/tls-default

Conversation

@ademar

@ademar ademar commented Sep 24, 2026

Copy link
Copy Markdown
Member

Summary

  • Service.Connect() and ITransport.Connect() defaulted to SslProtocols.Tls (TLS 1.0). TcpTransport passes that value to AuthenticateAsClient whenever a client certificate is configured, which is the path most registries require. Servers that only accept TLS 1.2+ reset the connection.
  • The default is now SslProtocols.None, so the OS negotiates the best version. This also clears the SYSLIB0039 obsolete-TLS build warning.
  • The version is bumped to 1.4.1, with release notes.

Callers that pass a protocol explicitly are unaffected. C# compiles default parameter values into the call site, so consumers need to recompile against 1.4.1 to pick up the new default.

Testing

  • Unit tests: 55 passed, 23 skipped.
  • TcpTransport with a self-signed client certificate against www.nuget.org:443, which only accepts TLS 1.2+:
    • new default: handshake OK
    • explicit SslProtocols.Tls (old default): connection reset by peer

🤖 Generated with Claude Code

… 1.0

Service.Connect and ITransport.Connect defaulted to SslProtocols.Tls,
which TcpTransport passes to AuthenticateAsClient whenever a client
certificate is set, the path most registries require. Servers that
only accept TLS 1.2+ reset the connection. Default to SslProtocols.None
so the OS negotiates the best version; bump to 1.4.1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ademar
ademar merged commit 4cb1343 into master Sep 24, 2026
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant