Summary
SPP 9.0 enables TLS 1.3. SafeguardJava hard-pins TLS to TLSv1.2 (RestClient.java, TLS_PROTOCOL = "TLSv1.2"). It authenticates successfully against 9.0 today via TLS 1.2 renegotiation.
Important constraint: Java''s JSSE does not perform TLS 1.3 post-handshake client certificate authentication (verified on JDK 11 and 21). On the Standard binding, cert-auth relies on a post-handshake certificate request, so it only works at TLS 1.2. The 1.2 pin is therefore currently what keeps cert-auth working -- simply removing it would break cert-auth by letting the server negotiate 1.3 with no way to present the client cert.
The only route to TLS 1.3 cert-auth for this stack is the Cert SNI hostname, where the server requests the certificate in-handshake (no PHA required).
Changes
1. Make the TLS version configurable (keep 1.2 default)
Replace the hard TLSv1.2 constant with a configurable min/max (default remains 1.2) so existing cert-auth against the Standard binding keeps working unchanged.
2. TLS 1.3 support paired with Cert SNI
Allow callers to enable TLS 1.3 and target the Cert SNI hostname. Document clearly that for this SDK, TLS 1.3 cert-auth requires connecting to the cert-auth hostname (in-handshake cert request), because JSSE cannot present a client cert post-handshake. Password/token auth (no client cert) can use TLS 1.3 on the Standard binding without issue.
3. HTTP/1.1
Keep the Apache HttpClient classic (HTTP/1.1) transport; do not enable HTTP/2 (HTTP/2 disallows the post-handshake certificate request).
4. Documentation
Document 9.0 TLS behavior, the 1.2 default, and the Cert SNI requirement for 1.3 cert-auth.
Acceptance criteria
- Default connect + cert-auth (incl. A2A) succeeds against a 9.0 appliance at TLS 1.2 with no extra config.
- Password/token auth can negotiate TLS 1.3 on the Standard binding.
- With TLS 1.3 + Cert SNI configured, cert-auth succeeds at TLS 1.3.
- Requests use HTTP/1.1.
- Existing deployments are unchanged.
Testing
Validate against a live 9.0 appliance: TLS 1.2 cert-auth on the Standard binding, and TLS 1.3 cert-auth via the Cert SNI hostname.
Summary
SPP 9.0 enables TLS 1.3. SafeguardJava hard-pins TLS to
TLSv1.2(RestClient.java,TLS_PROTOCOL = "TLSv1.2"). It authenticates successfully against 9.0 today via TLS 1.2 renegotiation.Important constraint: Java''s JSSE does not perform TLS 1.3 post-handshake client certificate authentication (verified on JDK 11 and 21). On the Standard binding, cert-auth relies on a post-handshake certificate request, so it only works at TLS 1.2. The 1.2 pin is therefore currently what keeps cert-auth working -- simply removing it would break cert-auth by letting the server negotiate 1.3 with no way to present the client cert.
The only route to TLS 1.3 cert-auth for this stack is the Cert SNI hostname, where the server requests the certificate in-handshake (no PHA required).
Changes
1. Make the TLS version configurable (keep 1.2 default)
Replace the hard
TLSv1.2constant with a configurable min/max (default remains 1.2) so existing cert-auth against the Standard binding keeps working unchanged.2. TLS 1.3 support paired with Cert SNI
Allow callers to enable TLS 1.3 and target the Cert SNI hostname. Document clearly that for this SDK, TLS 1.3 cert-auth requires connecting to the cert-auth hostname (in-handshake cert request), because JSSE cannot present a client cert post-handshake. Password/token auth (no client cert) can use TLS 1.3 on the Standard binding without issue.
3. HTTP/1.1
Keep the Apache HttpClient classic (HTTP/1.1) transport; do not enable HTTP/2 (HTTP/2 disallows the post-handshake certificate request).
4. Documentation
Document 9.0 TLS behavior, the 1.2 default, and the Cert SNI requirement for 1.3 cert-auth.
Acceptance criteria
Testing
Validate against a live 9.0 appliance: TLS 1.2 cert-auth on the Standard binding, and TLS 1.3 cert-auth via the Cert SNI hostname.